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.