Managing Space memberships

[exalate-issue-sync]

• change the SDK to include the storage ID to add shares -> web team
  As a manager of a Space I want to add users to the Space so that they can collaborate.

As a manager of a Space I want to control what Space members are allowed to do.

As a manager of a Space I want to remove users from the Space so that they can not access the Space anymore.

!Spaces.png!

Concept

A space is a share with additional properties, eg. quota.

Graph and OCS API implement the ownCloud business layer:

• eg. the last manager cannot leave a space. See acceptance criteria below.
• Drawback: when using the CS3 api the owncloud business layer can be circumvented ()

Questions

• Given a space has a .space folder
• And Alice has the role editor
• When Alice tries to edit the space property description
• Then she should not be able to

The reason is that only managers should be able to manage space properties. We can implement this restriction in the graph api, but editors could just overwrite the file using webdav. This would be solved by the negative permissions CERN is planning.

This loophole is currently accepted. It needs to be resolved before GA. One option would be to move the .spaces folder outside of the space and not expose them via webdav, which has the drawback that managers cannot edit the .spaces folder via webav when syncing it to the local disk.

Related services

• graph:
  • list spaces on the /me/drives endpoint
  • root item is always the resourceid of the space
• ocs:
  • add members to spaces
    • set grants on resources
    • add aliases to the share manager
  • properties of spaces can be changed by using the resourceid to update shares
  • we could use the storageid property for the spaceID
• share manager:
  • captures user intent
  • manage space aliases, including personal spaces
  • persists alias, expiry, sharing roles, password
• base changes on the branch https://github.com/butonic/reva/tree/sharestorageprovider-oc10-sm

AC

• All Managers of a Space can add users to the Space via regular sharing mechanisms
• Managers can give other users the roles "Viewer", "Editor" and "Manager"
• All Space "members" (Viewer, Editor, Manager) can list the Space and access it according to their role
• Added users do not have to accept the Space invite
• Managers, Editors and Viewer can't change their own role
• Managers can remove users from the Space
• Editors and Viewers can't leave a Space
• Removed users can't list nor access the Space anymore
• acceptance tests cover the implemented functionality

[exalate-issue-sync]

Jörn Friedrich Dreyer commented: In oc10 the storage property of a share is only used for internal joins to check if a path is accessible. The share2.0 api implementation actually has no storage or storageid property.

[exalate-issue-sync]

David Christofas commented: https://github.com/C0rby/reva/tree/space-membership
Adding members through the OCS sharing API works. We are not using the share manager, instead we directly add a grant to the space.
The roles are limitted to manager, editor, viewer.

Removing users from a space isn't implemented yet. There is no API endpoint in the OCS sharing API which fits. It is now.

[exalate-issue-sync]

David Christofas commented: cs3org/reva#2250