Subpage ID not deleted when page is deleted

[philiprenich]

Describe the bug
In the API, if I have a page that has a subpage, for the parent page, subpageOrder contains that child page's ID. When deleting (permanently) the subpage, it's ID still shows in subpageOrder on the parent.

To Reproduce
Steps to reproduce the behavior:

1. Create a page
2. Create a subpage of the first
3. Verify its ID shows up in the API under subpageOrder
4. delete the subpage
5. go to trash and permanently delete it
6. Check API and see the ID still there.

Expected behavior
subpageOrder should be cleaned up when pages are deleted

Screenshots
If applicable, add screenshots to help explain your problem.

Server details:

• Collectives app version: 4.4.2
• Nextcloud version: 33.0.5
• PHP Version: managed by AIO
• Database: managed by AIO

[max-nextcloud]

Hi @philiprenich

Thanks for your report. My understanding is that we are only using the subpage order to sort the subpages. The page tree is build based on the parent id of the subpages. The siblings are then sorted accordingly. So dangling page ids in the subpage order should have no effect.

What are you trying to use the subpage order for?

[philiprenich]

I’m using it for a similar reason: building the page tree in reverse, top down. It meant I got the sort for free from that array.

[max-nextcloud]

I'd like to hear @mejo- on this. But at least historical the authority for the tree structure is the file hierarchy. For example in my mind it's perfectly valid for a page to have an empty or undefined subpage order if the user has not sorted the subpages for a custom order yet.

I see two options here:

1. Make it explicit that we make no guarantees about completeness and exhaustiveness of the subpage order.
2. Implement syncing between folder structure and subpage order with file system hooks and commit to the guarantees.

[philiprenich]

But at least historical the authority for the tree structure is the file hierarchy
I had originally played with grabbing the file list/hierarchy with webdav rather than the Collectives API, but the API is just nicer to work with :)

It would be nice for subpage ordering to be reliable, but honestly, #2 sounds like unnecessary extra work 😅 So clarity around subpage is fine. I think I'll use the proper setup and build the tree from the parent IDs.

Thanks for working through it with me.

---

If I can self-hijack my thread for a quick moment, can you tell me if I'm misunderstanding how the API/Swagger is set up? I'm using the ocs_api_viewer app to view the APIs in NC. The schema listed for a collective's pages (/ocs/v2.php/apps/collectives/api/v{apiVersion}/collectives/{collectiveId}/pages) does not include some of the properties that the response includes. Using that endpoint as an example, ocs.data.pages[].slug is in the response, but not the schema. This is true for a handful of other endpoints I've looked at. Is that a bug in the generated Swagger data, or expected to be missing? I was using the listed schema to create types for response objects, but then finding the responses slightly different.

[max-nextcloud]

@philiprenich I'd look at openapi.json. I'm not familiar with the ocs_api_viewer.

In the json there are kind of type definitions - called schemas. Maybe the response definition is reffering back to those?

[mejo-]

@max-nextcloud the ocs_api_viewer app reads openapi.json, so it should be a good test environment.

It seems like you're right @philiprenich and our API definitions miss some properties in lib/ResponseDefinitions.php. I opened #2599 to fix this.