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.
I may not be seeing the bigger picture and possible caveats, but it's my superficial impression.
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.
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?
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?
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.
> 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.
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.
> 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.
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, likecreated_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.
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?
I think this could also be good for the zod based types in the frontend.
See vikunja/frontend#2225
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.
Go is not my first language. So probably not soon if at all.
That's not that easy, given how the current architecture is structured. Right now all crud routes use the same structs for one entity.