github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-06 03:27:53 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #534] API docs: distinction between GET and PUT (and POST) entity types #6227

New Issue
Open
opened 2026-04-20 16:49:09 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-20 16:49:09 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/534

Original issue by WofWca on 2023-03-15T13:47:40.000Z

Consider the "create task" endpoint:

066c26f83e/pkg/models/tasks.go (L909)

Currently the docs say that you can pass attachments, created_by, index, labels (with all the fields, like created_by, description), but it looks like they're actually ignored and overridden.

I think there needs to be a separate struct (called something like TaskInitDict) that lists all the fields that are actually supported by the endpoint.

This should also allow to document things like the fact that if you pass position: 0 for a task, the backend will actually set it to a default one, and state which fields are required and stuff.

I may not be seeing the bigger picture and possible caveats, but it's my superficial impression.

Original issue on Gitea

@kolaente commented on 2023-03-15T15:23:05.000Z:

That would probably be a reasonable idea. We do need to make sure the "new" structs would be properly maintained and not forgotten when making changes to the other structs.

Do you want to send a PR?

dpschen commented on 2023-03-15T15:52:23.000Z:

I think this could also be good for the zod based types in the frontend.
See https://kolaente.dev/vikunja/frontend/pulls/2225

WofWca commented on 2023-03-15T16:42:52.000Z:

make sure the "new" structs would be properly maintained and not forgotten

I thought it'd be possible to actually integrate them in the code base in a DRY fashion and not purely for the purpose of generating docs.

Do you want to send a PR?

Go is not my first language. So probably not soon if at all.

@kolaente commented on 2023-03-16T09:00:52.000Z:

I thought it'd be possible to actually integrate them in the code base in a DRY fashion and not purely for the purpose of generating docs.

That's not that easy, given how the current architecture is structured. Right now all crud routes use the same structs for one entity.

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/534 _Original issue by WofWca on 2023-03-15T13:47:40.000Z_ Consider the "create task" endpoint: https://kolaente.dev/vikunja/api/src/commit/066c26f83e1e066bdc9d80b4642db1df0d6a77eb/pkg/models/tasks.go#L909 Currently the docs say that you can pass `attachments`, `created_by`, `index`, `labels` (with all the fields, like `created_by`, `description`), but it looks like they're actually ignored and overridden. I think there needs to be a separate struct (called something like `TaskInitDict`) that lists all the fields that are actually supported by the endpoint. This should also allow to document things like the fact that if you pass `position: 0` for a task, [the backend will actually set it to a default one](https://kolaente.dev/vikunja/api/src/commit/066c26f83e1e066bdc9d80b4642db1df0d6a77eb/pkg/models/tasks.go#L951-L953), and state which fields are required and stuff. I may not be seeing the bigger picture and possible caveats, but it's my superficial impression. [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1432) --- _**@kolaente** commented on 2023-03-15T15:23:05.000Z_: That would probably be a reasonable idea. We do need to make sure the "new" structs would be properly maintained and not forgotten when making changes to the other structs. Do you want to send a PR? --- _**dpschen** commented on 2023-03-15T15:52:23.000Z_: I think this could also be good for the zod based types in the frontend. See https://kolaente.dev/vikunja/frontend/pulls/2225 --- _**WofWca** commented on 2023-03-15T16:42:52.000Z_: > make sure the "new" structs would be properly maintained and not forgotten I thought it'd be possible to actually integrate them in the code base in a DRY fashion and not purely for the purpose of generating docs. > Do you want to send a PR? Go is not my first language. So probably not soon if at all. --- _**@kolaente** commented on 2023-03-16T09:00:52.000Z_: > I thought it'd be possible to actually integrate them in the code base in a DRY fashion and not purely for the purpose of generating docs. That's not that easy, given how the current architecture is structured. Right now all crud routes use the same structs for one entity.
GiteaMirror added the area/api label 2026-04-20 16:49:09 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label area/api
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6227
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?