Edit space member with no permissions returns 500

[jesmrec]

Describe the bug

The bug was discovered during Android client testing. Space manager is downgraded to editor just before submitting a permission and expiration date change on other member. Request is sent to the server but the user is not manager, so the expected result is 403 Forbidden. But the server returns a 500

Steps to reproduce

1. In a mobile client, Alice, who is a manager clicks on Bob who is also a manager to edit his permissions and expiration date
2. Alice clicks Bob's permission to turn him into editor and add an expiration date without submitting
3. Charles, who is also a manager, changes Alice's permission from manager to editor
4. Alice submits changes in 2.

Expected behavior

Alice is no longer manager, so, she is not allowed to edit Bob. Therefore, backend should return a 403 Forbidden

Actual behavior

Backend returns 500

Try the following curl where the user who triggers should not be a manager.

curl -H 'X-Request-ID: 85294fbf-3fa9-4457-80a8-84e20854103c' -H 'User-Agent: Mozilla/5.0 (Android) ownCloud-android/4.7.0' -H 'Accept-Language: en' --compressed -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json; charset=utf-8' -H 'Connection: Keep-Alive' -X PATCH 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/<drive-id>/u:<Bob-id>' -d '{"expirationDateTime":"2026-02-28T22:59:59.999Z","roles":["<editor-role-id>"]}'

[2403905]

@jesmrec Why does a client uses /graph/v1beta1/drives/<drive-id>/u:<Bob-id>' to change the permission?
It should be /v1beta1/drives/{drive-id}/root/permissions/{perm-id}

[jesmrec]

@jesmrec Why does a client uses /graph/v1beta1/drives/<drive-id>/u:<Bob-id>' to change the permission? It should be /v1beta1/drives/{drive-id}/root/permissions/{perm-id}

i don't know whether there are several options to implement the same operation. With your suggestion /v1beta1/drives/{drive-id}/root/permissions/{perm-id}, where do you tell the endpoint the user to become a member?

Anyway, the endpoint /graph/v1beta1/drives/<drive-id>/u:<Bob-id>' works fine for inviting new members and it's used among the platform. It's a valid option, regardless other options to be available. But, the described defect is there.

[2403905]

@jesmrec

i don't know whether there are several options to implement the same operation. With your suggestion /v1beta1/drives/{drive-id}/root/permissions/{perm-id}, where do you tell the endpoint the user to become a member?

Some endponts could be used in several ways. But it will be better to follow API specification, for The Spaces membership we mostly use https://owncloud.dev/libre-graph-api/#/drives.root
For the sharing https://owncloud.dev/libre-graph-api/#/drives.permissions
If something is not clear from the API Swagger, you could take a look at what the requests the Web uses.

Anyway, the endpoint /graph/v1beta1/drives//u:' works fine for inviting new members and it's used among the platform. It's a valid option, regardless other options to be available. But, the described defect is there.

This call looks totaly wrong. I'm getting 404. Could @jesmrec you confirm that you get 2xx for such request?

curl -H 'X-Request-ID: 85294fbf-3fa9-4457-80a8-84e20854103c' -H 'User-Agent: Mozilla/5.0 (Android) ownCloud-android/4.7.0' -H 'Accept-Language: en' --compressed -H 'Authorization: Bearer xxx' -H 'Content-Type: application/json; charset=utf-8' -H 'Connection: Keep-Alive' -X PATCH 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/<drive-id>/u:<Bob-id>' -d '{"expirationDateTime":"2026-02-28T22:59:59.999Z","roles":["<editor-role-id>"]}'

[jesmrec]

the following curl command:

curl -H 'X-Request-ID: 63f24872-48f7-4d65-aa56-55a354da4573' \
-H 'User-Agent: Mozilla/5.0 (Android) ownCloud-android/4.7.0' \
-H 'Accept-Language: en' \
-H 'Authorization: Bearer xxx' \ 
-H 'Content-Type: application/json; charset=utf-8' \
-H 'Host: xx.xx.xx.xx:9200' \
-H 'Connection: Keep-Alive' 
-X PATCH 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/<drive-id>/root/permissions/u:<user-id>' \ 
-d '{"expirationDateTime":"2026-02-23T22:59:59.999Z","roles":["<role-id>"]}'

returns 200 OK

This is exactly the same request that the Web client uses:

[2403905]

Ok, I was confused by the wrong request example from the start post -X PATCH 'https://xx.xx.xx.xx:9200/graph/v1beta1/drives/<drive-id>/u:<Bob-id>' -d '{"expirationDateTime":"2026-02-28T22:59:59.999Z","roles":["<editor-role-id>"]}'

[2403905]

#12051

[paul43210]

This should be resolved by PR #12051 (reva bump), which was merged on Feb 24. @jesmrec can you confirm the fix on your end? If so, this issue can be closed.

[jesmrec]

give me an instance with the fix to check it with mobile devices, and i will review it.