Right now, people can only edit views if they are an architect of the space the view is in. It would be nice if this can be arranged more easily, linking it either to database access, or making it an “editable by” thing.
Agreed! A solution I use is to create a “Playground” space with no databases and making everyone architects. Then they can freely make end configure views without risking them deleting fields or databases.
Ideally spaces would split database access and view access (coming soon I believe).
But in the way that it has been described, it would have to setting the users to “Arcitects” and then toggling “Do not extend to databases” then setting the database access per database.
I’ve mentioned a few times on the here that I think this is not ideal, and that splitting access you be better. But I know how it was received by the team.
I see actually made a post about this: Separate the view config access and data config access
I think this is a duplicate of that, no? I’ll clean that one up to make more sense though
We already have plans to make it possible for someone’s access to the views in a space being separated from their access to the data in the databases in the space.
However, the plan is that the rights to configure/see a view will still be covered under the umbrella-level of the space access. In other words, you will be able to make someone an architect in a space, and not extend that to making them owners for all the data in that space. But you won’t be able to control access on a view by view basis - it will be all or nothing for the views in a space.
We have no plans to make the ability to configure a view dependent on a person’s access to the database used in the view.
Question: If you do not extend to databases, does the architect have the ability to create new databases?
I will make thing clearer here with some examples.
Old: Space Architect with Database extended
New: Data Architect and View Architect
Old: Space Architect with database not extended
New: View Architect and No Access to Data
This new model allows for much more flexibility, while being even more intuitive to understand.
Spaces contains views and databases. But space access currently puts these together in very confusing ways. You are adding the technology to separate them (lovely) but not doing it in the most intuitive way imo.
Indeed it is “more complex” because there are two toggles instead of one, but its more true to reality as the single dropdown gives access to two things, so overall it makes things easier to understand.
I can clarify more if needed!
My main issue is that I dont always want people to edit every setting in a space, but do want them to have access to view changes.
It kind of makes sense that this is on a space-level, but for me it would make more sense if View Editing (not deleting, just editing) would be an owner-level access rather than an architect. I see why it is setup this way but I personally dont agree.
@RonMakesSystems, your setup is a nice workaround, but it should be simpler and in the actual space where you want the view to be (especially if its related to databases in a specific space).
That is the plan, yes.
I realise now that the upcoming feature may not deliver on this request.
Here’s a mockup of (which uses the outdated Creator terminology, but) which is indicative of where we’re probably heading.
When making someone an space `Architect’, you can choose whether to extend this to all of the data in the databases in the space.
An (unextended) Architect will be able to create/configure views and databases in the Space, but not see/manipulate any data (unless specifically granted access by some other means).
There is no such thing as a view Owner. Entities have Owner(s).
An Owner at the Space level is merely someone who is Owner for every entity in every Database in that Space.
See here.
When you say
what do you mean?
Given a view can display content from any database in the whole workspace, there is no reason to enforce that views live in the space where the data lives.
Overall, if you absolutely want someone to be able to create/edit views but not have any database configuration capabilities, then these views should live in different space to the dbs.
Or you can encourage users to make Private views in their Personal sidebar, and then
