Way to Forms 5

[Chartman123]

This is a collection of tasks needed for preparation/release of Forms v5.

4.3 release:

• Deprecation of legacyLink access #2071
• Refactor lastUpdated handling #2072
• Reorganize API endpoints and deprecate current endpoints #2079
• fix: Adjust app to be compatible with Nextcloud 30 #2278
• feat: Allow to reorder options for "multiple" question type in backend #2333

See sub-issues for 5.0 related tasks

[susnux]

How about unifying our API? Currently there is not really a pattern in the API routes - especially logical nesting.

For example for forms:

What	Current	New
Get forms	GET /forms	GET /forms
New form	POST /form	POST /forms ❗
Get form	GET /form/:id:	GET /forms/:id:
Clone form	POST /form/clone/:id:	POST /forms/:id:/clone
Update form	PATCH /form/update	PATCH /forms/:id:
Transfer ownership	POST /form/transfer	- (just use the patch)
Delete form	DELETE /form/:id:	DELETE /forms/:id:

This is just an example, but I think it would make the API more logical

[Chartman123]

Yes I think this would definitely make sense... This was always something illogical to me

[susnux]

I do not see any use case for the hash other than the legacy link, probably we can also remove that with v5?

[Chartman123]

Should we add the newly organized endpoints already in 4.3 so that users of the API can already adapt to the new structure?

And regarding the hash: If we remove it, our internal links/URLs would only have the id, right? I think we should at least have a look at the APIs so that we don't mix it there (sometimes hash is needed, sometimes the id).

[susnux]

And regarding the hash: If we remove it, our internal links/URLs would only have the id, right? I think we should at least have a look at the APIs so that we don't mix it there (sometimes hash is needed, sometimes the id).

Yes I would just use the form id, like for files. if you use the internal share link it is just the file id.