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