Webdav API for groups management

[PVince81]

• custom groups
  • list groups PROPFIND http://localhost/owncloud/remote.php/dav/customgroups/groups/
    • property oc:display-name: group display name
    • child node MembershipNode, name is the custom group URI
  • rename custom group: PROPPATCH oc:display-name on http://localhost/owncloud/remote.php/dav/customgroups/groups/$customGroupUri
    • only group admin can rename
  • delete group: DELETE http://localhost/owncloud/remote.php/dav/customgroups/groups/$customGroupUri
    • only group admin can delete
  • create group: MKCOL http://localhost/owncloud/remote.php/dav/customgroups/groups/$customGroupUri
    • throws MethodNotAllowed if already exists
    • creator automatically becomes group admin and member
• memberships:
  • list members PROPFIND http://localhost/owncloud/remote.php/dav/customgroups/groups/$numericGroupId/
    • child node "MembershipNode" name is user id
    • property oc:role (int) whether this member is also a group admin
    • only members can list members, others get 403 when listing collection contents
  • add member: PUT http://localhost/owncloud/remote.php/dav/customgroups/groups/$numericGroupId/$userId
    • only group admin can add members
  • remove member: DELETE http://localhost/owncloud/remote.php/dav/customgroups/groups/$customGroupUri/$userId
    • only group admin can remove members
    • group admin cannot remove self if no other admin exists in the group
    • a group member can remove themselves with the same API call to leave the group
  • change admin role of a member: PROPPATCH http://localhost/owncloud/remote.php/dav/customgroups/groups/$customGroupUri/$userId of the oc:role property
• list group memberships of a given user: PROPFIND http://localhost/owncloud/remote.php/dav/customgroups/users/$userId/$membership
  • child node is MembershipNode where name is group id
  • membership node has "oc:role" attribute
• regular admins can do the same as group admins
• provider REPORT in addition to PROPFIND for pagination

[PVince81]

• REQUIRES: support for apps to register sabre plugins: Provide API to let apps register their own Sabre plugins core#26195

[DeepDiver1975]

I'd prefer to not work on the numeric ids on the dav api layer.
the numeric id is something we should keep internal.
let there be a uri name which will handle this.

see like caldav and carddav implement this.

This way you can also use the standard PUT for creation:
PUT http://localhost/owncloud/remote.php/dav/customgroups/awesome-group

[PVince81]

@DeepDiver1975 so what happens on renaming, does the URL change ?
Do we need an additional column in the DB "webdav_id" ?

[DeepDiver1975]

Do we need an additional column in the DB "webdav_id" ?

its named 'uri' in caldav and carddav.

[DeepDiver1975]

@DeepDiver1975 so what happens on renaming, does the URL change ?

in caldav and carddav renaming is only possible on the displayname - the uri is static

[PVince81]

Hmm, indeed... I have this old calendar from OC 4 which I first called "test" then renamed to "Main". The DB still contains "test" as name, confused me a lot when setting up Webdav sync back then.

Ok, then:

• adjust spec to use "uri" (generated static group name)
• adjust PR Implement group backend #1 to provide the "uri" column and generate that name

[DeepDiver1975]

generate that name

generate? in the server?
it's part of the url in PUT

[PVince81]

ok, so the client nees to generate it then at creation time and pass a if-match header to avoid overwriting an existing group, in which case 409 Precondition failed comes back and the client mzst then add '(2)' ti the uri until a non-existing name is found. (similar to the file upload logic)

[PVince81]

@DeepDiver1975 ok, I think I'll also use this "uri" on the group backend interface. So core will receive the group id as "customgroups_$uri" instead of "customgroups_$numericId".

[PVince81]

@DeepDiver1975 should we then get rid of the numeric id ? As per my last comment it doesn't make sense any more...

We could then have the DB's primary key on the uri field.

[PVince81]

and hopefully no issues with too long indices and emojis in uri names ? 😉

Since these are URIs I think emojis or unicode chars are URL-encoded anyway, but that would make them longer.