More granular rights or adjusted rights

[njyo]

Hi, so having groups-based rights is great and while I’m overall happy with the groups, but would like to suggest some adjustments if we want to keep a simple one-dimensional list:

1. Creator: Can configure the databases → IMHO this should be called Admins as they are the space admin and can configure the space
2. Editor: Create and edit entities → IMHO, this should be split into Creator, who can create new entities and Editor, who can only edit existing entities
3. Contributor: Create entities and edit ones assigned to them → IMHO, these should not be able to create entities, and only edit the ones assigned to them
4. Viewer: View but not edit → IMHO, this should be split into Commenter, who can always participate with inline or discussion comments and Viewer, who can only read and not add comments.
5. No access

The more granular approach, instead, could be a two-dimensional list (no access, view, comment, edit vs. no creation, create new, configure space)… the key differentiator for me is really that some people I want to disallow to create new entities, as I want to have a tightly controlled space structure, but then allow users to contribute contents.

Also, not all entities have assignees, just like documents, whiteboards and so forth seem to live on a different spectrum than entities (and views)

Thanks!

[antoniokov]

Yep, this is close to what we have in mind for Database-level access — hopefully, coming later this year.

Quoting our conversation with Yvette:

@antoniokov

The current Space access levels are a confusing mix of permissions on three levels:

• Space: who can share Space and create Views.
• Database: who can read and edit all the data inside the Space.
• Entity: who can edit specific Entities they are assigned to.

We are looking to untangle this knot to both make it obvious who gets access to what and unlock new use cases by combining DB and Entity access independently.

[njyo]

Thanks, @antoniokov, great to hear!