Databases on top level.
@Chr1sG nailed it, we have two reasons
Anyway, this feature does not demand any serious resources, it is just a side-effect of permissions changes.
I don’t get it, could you clarify?
I see thanks for explaining.
I think it would be helpful to have ability to set an existing space to a top level space. I currently create a “Home” space that acts in this way.
As well as the ability to turn the top level space into a normal space as things grow.
Why you need Home space? Why not just move things into top?
I can see an “Upcoming” widget being helpful that shows things especially relevant for the next week or so. Though I guess this would only be relevant for entities with date fields.
An embed for report views also might be handy for supervisors/team leads.
I’m afraid the most reasonable content for a relation field in CSV is a list of IDs. Not the most human-readable, but I think useful (practical, not fragile).
Currently for things like a documents database, general tasks, and a user’s view.
The future these things can be in the Default Space. But I’ll need a way to migrate it.
In Notion I have teamspace called “DataSpace” with global tables in it. E.g. all Vendors. Vendors relate to ROPA tables for GDPR reporting (Security & Compliance), but also to a Components table to document which of our internal components depend on which vendors (Engineering).
However permissions are defined at teamspace level, meaning that the permissions on global tables are way too broad. My feeling is that the right level at which to define permissions for such tables would be the View level: if you have access to a view, you have the configured permissions on the pages that match the view filter. (Sadly Notion does not work like that 
)
How would Fibery think about this?
In Fibery we will never set permissions via Views, only via Databases and relations. Let’s take an example with global Document database in top space. Here you have several options
Maybe we will come up with other strategies (like if a document linked to feature database, you see it, if not, you don’t), but it will be never about views, since views are very unreliable and dynamic. For example, when you change some filter, access can be changed from 10 to 10000 entities, and this is not something we would like to handle.
I don’t remember if this has been said before, but:
Will we be able to easily set permissions on the database level so that users can view all entities, create new ones, but not edit all entities? Currently we accomplish by giving contributor access in the space and viewer access in the database. There is currently no default database access level that accomplishes this.
I don’t actually think it can be avoided. E.g. if you change access on a database with 10000 entities you still need to handle that.
Notion handles this scale of access updates already; e.g. if I move a database to a different teamspace, or simply into a page with different permissions, then all contained pages will inherit permissions for all permissions not overridden at the page or database level.
I guess access in Notion may be determined via containment; i.e. it doesn’t need to update 10000 entities, but it needs to traverse a chain of containers, computing access along the way. I know this is how Zope (and thus Plone) works.
In my thinking, a View should be a container, as far as access is concerned.
So the issue isn’t really about the scale of updates, as I think that needs to be solved.
It’s really about the ease of updating the groups with access to sets of documents.
That sounds promising, it sounds like it would be equivalent to a view with filter “relation contains feature”. All that’s missing is to define who “you” is here. If we can say e.g. “EngineeringGroup can see any VendorDocument linked to ActiveStatus” we’re basically there.
View is a very fragile thing. Any admin can change a filter and boom, you suddenly gave access to many entities.
We will not do it and handle permissions via databases and relations only. To be honest, this is rare request and in most cases what we have is sufficient. We have large accounts with 1K users, and they don’t need that. Why do you need it?
Why would you need to grant viewer access in the database? Contributor at the space level means that they can view all entities anyway
If you make Status a database, and use user groups, you can link the Engineering group to the Active status entity, and use auto-sharing with an access template to allow all User members of the Engineering group to be able to see any Vendor Document entities linked to the Active status entity.
E.g. depending on the context,
I’d like to allow everyone to see and reference currently in use vendors, but not retired or deprecated vendors.
I’d like to allow engineers to reference any of the tasks in the current sprint, without cluttering the relation with all tasks ever.
I’d like to allow sales staff to reference contacts of current customers from meeting notes, without cluttering the relation with all contacts ever.
I think Michael meant submitter access, not sure. But I have the same need. I think I brought it up before.
Situations not possible on space/database permissions:
It was chatted about here: Feature Request: Share Space but restrict entity views - #41 by Edan
I still think the granular selector (present in access templates) is much more powerful and even more intuitive than a single select dropdown.
I think you mix-up access and usability.
Do you want to completely hide not-current-sprint tasks and not-active customers from users? I mean remove access and make it look like these tasks and customers do not exist?
These sound like things that might be solvable in some cases with relation filters.
Perhaps you don’t actually need to restrict access formally?
That depends on the case, e.g.
Yes, that did occur to me for those cases (and I wish Notion had relation filters).
Cases where I’d want to restrict access formally would be e.g. these.