Sharing by group membership - Allow a user to modify different events in the WebUI or API

[tendstofortytwo]

Hello!

I have a situation where I have two collections, say public and private. I would like the web UI for multiple users to be able to modify these two collections, instead of modifying collections inside their own directory. These users all belong to an LDAP group and may change over time, so I don't want to do something like "symlink the collection into their folder" since that'll be hard to maintain.

It seems like this isn't currently possible---the backend is hardcoded to return /<username>/ as the principal URL, and the frontend is hardcoded to query the principal URL for collections. Could we make it possible to change a user's principal URL to allow this to work?

[pbiering]

To support such, the new sharing mechanism (https://github.com/Kozea/Radicale/blob/master/SHARING.md) would require an extension, instead of having a static user binding, extension is required to match e.g. a group membership instead. Needs to be analyzed how easy such is implementable.

[pbiering]

BTW: WebUI is only supporting collection management, not any collection content manipulation beside upload complete one.

[tendstofortytwo]

yeah, that's okay. I meant management only - like changing the name and color of the collection. we're able to do the rest via calendar apps

[pbiering]

While working on a prototype in early phase there will be for sure some boundaries:

• user cannot hide or disable the incoming share
• user cannot overwrite any property to a custom value

Reason: there will be only one entry in the database where PathOrToken contains a placeholder for the particular user and the User contains then the matching group or domain of the user (in case of realm/e-mail is used).

Is such expected?

[tendstofortytwo]

that would be alright, yes.

thank you for working on it so quickly!

[pbiering]

Update from the R&D "flightdeck": prototype looks like working, sharing by group will support by membership

• based on "realm" (aka domain of user login, if used in this way)
• based on returned LDAP groups or new introduced support of a htgroup file (initially, required for proper testing)

[pbiering]

@tendstofortytwo - candidate for initial backend implementation can be found here https://github.com/pbiering/Radicale/tree/sharing-by-group

It was only tested against new implemented local static htgroup file, please check whether it works also with groups retrieved via LDAP.

To test, add a share via API where user starts with : (which indicates the group reference) and the user path starts with /{user} placeholder.

For others: also support of realm is now existing, means in case of e-mail addresses are used for login and different domains are in use, one can create now a share for all @domain1.example users, which is not exposed to @domain2.example users.

[tendstofortytwo]

hi! I'm able to create a share and have the shared collection show up in the web UI, but not share the edited collection? here's what the share looks like:

% curl -u radicale:$PW -H "Accept: application/json" -d "" https://<calendar-url>/.sharing/v1/all/list | jq .                                         
{
  "ApiVersion": 1,
  "Lines": 1,
  "Status": "success",
  "Content": [
    {
      "ShareType": "map",
      "PathOrToken": "/{user}/members/",
      "PathMapped": "/radicale/members/",
      "Owner": "radicale",
      "User": ":calendar-editors",
      "Permissions": "RrWwDO",
      "EnabledByOwner": true,
      "EnabledByUser": true,
      "HiddenByOwner": false,
      "HiddenByUser": false,
      "TimestampCreated": 1784411716,
      "TimestampUpdated": 1784412348,
      "Properties": {},
      "Conversion": "none",
      "Actions": {
        "config": {
          "conversion_bday_summary_template": "#DEL#",
          "conversion_bday_description_template": "#DEL#",
          "conversion_bday_alarm_trigger_template": "#DEL#",
          "conversion_bday_categories": "#DEL#",
          "conversion_bday_age_max": "#DEL#"
        }
      }
    }
  ]
}

and the following section in the rights file:

[home-write]
groups: calendar-editors
collection: .*
permissions: RrWwDO

any idea what could be up?

[tendstofortytwo]

okay, this is weird... now the shared collection has stopped showing up in the web UI even though the group share still exists according to /list... I'm not quite sure what changed here

EDIT: fixed, see below