Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Library permissions management #80

Open
elv-serban opened this issue Feb 4, 2023 · 1 comment
Open

Library permissions management #80

elv-serban opened this issue Feb 4, 2023 · 1 comment
Labels
type: enhancement New feature or request

Comments

@elv-serban
Copy link

elv-serban commented Feb 4, 2023

OBJECTIVE

Create a fabric browser group permissions flow that works correctly for library operations.

BACKGROUD

There are two sets of access controls for libraries:

  1. Library specific permissions controlling what can be done with content inside the library
  • accessor - can list contents in the library
  • contributor - can create new content in the library
  • reviewer - this enables a custom review flow that we don't want at all exposed
  1. Regular object permissions
  • see - can view the public areas of the library object (metadata)
  • access - can view entire library object (private and public metadata, encrypted parts, etc)
  • edit - can modify the library object
    • this is also required in order to delete other people's objects in the library! (little known fact ...)

CURRENT SITUATION

We expose the 3 permissions that are library specific.

  • we really don't want to expose 'review' - this functionality should be removed (and at a minimum hidden)

We don't expose the regular object permissions see/access/edit - these can only be accessed through the contract methods directly.

PROPOSAL

Theoretically we have 6 permissions to configure:

  • library level 'accessor'
  • library level 'contributor'
  • library level 'reviewer'
  • object level see
  • object level access
  • object level edit

But only some of them are useful:

  • library level 'accessor' - this is useful and we should keep it
  • library level 'contributor' - this is useful and we should keep it. It implies accessor so we shouldn't have both contributor and accessor
  • library level 'reviewer' - this is bad and we want to hide it
  • object level see - this is not useful - it is implied by library 'accessor'
  • object level access - this is not useful - it is implied by library 'accessor'
  • object level edit - this is useful and we should keep it

So my proposal is to expose the following:

PROPOSAL

Instead of the current:

image

Selector of one of the following 3 options (radio buttons or picker, something like that)

  1. "View"
  • this provides library-level 'access'
    • same as we do in libraries "Manage Group Permissions" and select "Access"
  • description "List content objects in the library. View library metadata'
  1. "Contribute"
  • this provides library-level 'contributor'
    • same as we do in libraries "Manage Group Permissions" and select "Contribute"
  • description "List and create new content objects in the library. View library metadata"
  1. "Manage"
  • this provides the object level 'edit'
    • same as we do in a regular content object "Manage Group Permissions" and select "Manage"
  • description "List, create and delete content objects in the library. Edit library metadata"
@elv-arun
Copy link

elv-arun commented Nov 8, 2023

Discussion with Marc and Zenia.

Marc's analysis based on reviewing the code:
Pre V3: Only the owner of an object can delete it.
V3: The owner cannot delete the object unless he is also a library manager of that library, a non owner manager can also delete the object.

Demo is on V3
Prod is on V2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

9 participants