As we’ve hinted before, we are looking to deprecate Contributor Space access. Now that we have proper Database access and automatic sharing for assigned people and groups, there’s no need for the access level that tries to imitate both.
We’d like to make the transition as smooth as possible, and we need your help. If you’re currently using the Contributor access or have just transitioned from it, please answer a few questions about the desired access for each Database.
Here is an example. Dev Group has Contributor access to Project Management Space with three Databases: Objectives, Projects, and Tasks:
| What should they be able to do? |
Answer |
| See and comment all Objectives |
Yes |
| Edit Objectives they are assigned to |
No |
| Create Objectives |
No |
| ——— |
|
| See and comment all Projects |
Yes |
| Edit Projects they are assigned to |
Yes |
| Edit Projects they are assigned to even if they lose Space access |
Yes |
| Create Projects |
No |
| ——— |
|
| See and comment all Tasks |
Yes |
| Edit Tasks they are assigned to |
Yes |
| Edit Tasks they are assigned to even if they lose Space access |
Yes |
| Create Tasks |
Yes |
| Edit Tasks they create |
Yes |
| Edit Tasks they’ve created even if they lose Space access |
Yes |
Please pick the most critical Contributor use case in your workspace, copy-paste the table into your reply, and replace the Databases with yours.
Thank you!
Hey @antoniokov
I’ll dodge a bit your request but still try to address the same topic.
Here’s an example of a scenario we have:
A space with 20+ databases and a few user groups.
I want the user groups to be able to do, for potentially all the DBs in the space, exactly what it says on the label: crete new entities or edit ones assigned to them.
Let’s say I would want to do that without the Contributor access.
I have an example of a custom Role we call Partner, which is meant to provide access to our business Partners per Engagement (we have multiple ongoing engagements).
Here is how the role looks.
If I want to implement something like “this role should be able to create entities in any of these databases”, how am I supposed to do that?
The only way I can see this afaik is by pressing the “+” button. That would mean I would need to add 3 groups per 20+ databases. It’s not just horrible user experience, but it’s extremely prone to human error.
The fact that I can’t tell at a glance “can they or can they not create entities” only exacerbates this problem. The “plus” button tells me nothing, it’s just a blackbox and I would need to open 20 of them to get an overview of what this role can do.
So right now the Contributor role solves a real problem, at least in our case.
1 Like
If I understand you correctly, you describe two distinct use cases: one involving internal teams and the other involving an external partner.
The internal one is decomposed into three actions:
- Change
Contributor to Viewer for Teams on the Space level.
- Grant
Submitter access to those Databases that Teams need to create Entities of. I presume, not all of the 20+ Databases are involved here.
- Enable automatic access for assigned people or even groups on relevant DBs.
Less convenient than Contributor in your scenario, but more precise.
As for the partner case, + should ideally be a part of the custom access template, not a button that redirects to the DB access settings. We’ll explore the feasibility of this idea later this summer.
1 Like
