feat(Context): add share logic for contexts

[blizzz]

contributes to #311 and #897

• createShare endpoints where extended with the optional parameter displayMode, which is only effective for contexts. The permissions flags on the other hand are not effective for contexts at the moment.
• updateShareDisplayMode (Routes: api1#updateShareDisplayMode and share#updateDisplayMode) endpoint was added, as the only updatable endpoint was against purely against permissions.
• business logic was adjusted to supply contexts specific needs.

[blizzz]

@blizzz I guess you need to add sharing to the create and update functions at ContextController.php?

The existing share endpoints were extended instead.

[enjeck]

@blizzz I guess you need to add sharing to the create and update functions at ContextController.php?

The existing share endpoints were extended instead.

Sorry, I don't understand how it works. The way I understand it, I can use the existing endpoint by making a POST request to generateUrl('/apps/tables/share') and sending data of a format similar to this:

{
  nodeType: 'context',
  nodeId: <context id>,
  receiver: <user id>,
  receiverType: 'user',
  permissionRead: true,
  permissionCreate: true,
  permissionUpdate: true,
  permissionDelete: false,
  permissionManage: false,
}

But I can't see how the above approach would fit a context share.

I took this screenshot from https://github.com/nextcloud/tables/issues/311:

As shown image above, I expect a context share to support multiple receivers, and can have different permissions for each resource. So I expect receiver in the object above to be an array or similar. And to somehow have each resource mapped to separate permissions.

Am I thinking about this incorrectly?

[blizzz]

The permissions are (at least for now) irrelevant, so leave the at false, or do not specify them at all – they are optional. Additionally you can set the default displayMode to 0 (default), 1 (navigation entry for recipients) or 2 (navigation entry for all, i.e. recipients and owner). For example:

{
  nodeType: 'context',
  nodeId: <context id>,
  receiver: <user id>,
  receiverType: 'user',
  displayMode: 2
}

The permissions from the draft are node-specific and unrelated to the shares! So "My open request" and "Approved" are tables or views and their permissions are set when you are creating the Context (or updating it). You remember the payload from the create Context API

{
  "name": "Enchanting Pancake",
  "iconName": "airline_seat_recline_extra",
  "description": "comparison of pancake receipes, ingredients, cafés and cooks.",
  "nodes": [
    {
      "id": 4,
      "type": 0,
      "permissions": 7
    },
    {
      "id": 2,
      "type": 1,
      "permissions": 4
    }
  ]
}

The permissions in the node specification are the bitmask with the values from these constants: https://github.com/nextcloud/tables/blob/main/lib/AppInfo/Application.php#L38-L43

So far the interpretation of the concept is that all nodes are shared with the same permissions to all recipients. To quote @juliushaertl

There is a set of default permissions that are applied to all share recipients for now source