Already possible using existing per-entity permissions, no? If not, please elaborate what you want
Submitter is the database access level, and this is not what I meant. I did mean Contributor, the space access level.
I guess I just didnāt look too deeply into this. Contributor is described as āCan edit only Entities assigned to them and create new onesā. I interpreted this as not including āview allā. I didnāt test this. Kind of embarrassingā¦ Thanks for correcting me!
Still, there will need to be a way to emulate this on the database level if space level permissions are going away. It doesnāt seem like the current database access levels have this same effect.
I created a clients group and set permissions using access templates accordingly so that I could offer a customer portal. Making sure you get the right space level and database level permissions and then extend the right permissions in the access template can be a bit to wrap your head around, but once you do it works pretty well. My only frustration is that itās entity-level vs field-level (e.g., I might want the client to be able to see their profile but not the internal notes field or certain settings). The workaround for that frustration is to create linked databases - one with only fields that customer can see, the other with the internal field, but that gets a bit messy.
Perfectly true, also for Notion, and yet this has been the top feature request for a long time in the āNotion Championsā workspace.
The problem is that per-entity permissions need to be managed per entity.
Iād like to be able to define permissions based on classes of entities, as defined by e.g. a view ā or by any other mechanism, Iād be delighted if Fibery has a better way.
Hereās some cases from that feature request (not mine, but bold is mine):
My engineering team has built a nice documentation system in notion, using related tables of subject-matter-experts, teams who are responsible for systems, the last time someone edited the doc, and whether that person was a subject-matter-expert. [ā¦]
- weād like to lock down some documents to be readable only by specific teams. There is IP tied up in some of our systems that as a business, we want to restrict even internal access to. Ideally we would set up columns/automations that would allow us to enable this restriction by checking a box in a āOnly Viewable by Responsible Teamsā property. This would allow us to update the view permissions with a single click & confidently keep permissions synced with the list of teams responsible for the documented systems.
we have a database where we want to grant permissions to a wider group of users going forward but we want historical items to have more limited permissions
This implies pages inheriting permissions from a view. Pages already inherit permissions via containment. Inheriting permissions via view would unlock very powerful contextual permissions.
The permissions hierarchy implied by this would be:
parent ā
view (overrides parent) ā
page (overrides view)
In a case like this:
So when visited directly, people get view permission, but when edited via the appropriate view, they can edit.
This could also be more granular:
Iām a trainer and I use databases to create āClassroomsā for my newbies - Iāve got a table in my own leadership page that I use to track the progress of all Classes, and a template in that table that creates a new Classroom automatically. Then, on the trainee side of things, they can see a limited view of my Classrooms. I can ālockā the view, but they can unlock it and see much more information than is necessary for them.
TLDR granular lock permissions would let me adjust who can lock and unlock a database.
Cool! This definitely solves a bunch of use cases.
These are exactly the reasons why Fibery has automatic entity sharing with groups as well as access templates for custom inherited permissions.
In your example, you would link your Document database to your user Groups database (the relation field on the Document db would be called Responsible Group) and you enable auto-sharing.
In that way, any members of the linked Responsible Group automatically get granted view access to the Document entity.
Instead of thinking about views as a way of controlling access, consider what properties/relation field values should determine who has access. It will almost always be possible to set up auto-sharing to make it work that way.
If you want to hop on a call some time to set things up (e.g. with screen sharing) reach out in chat.
4 Likes
Random thought on your Conditional Default Entity View:
It might be nice to have the current default view auto pin. Meaning that you could have some view that always stay pinned, but other views only pin when they are the default view.
Regarding the expected improvement in Files, wouldnāt it make sense to make each file a āfirst class citizenā and have it as a special entity, such as users, so metadata can be associated, or at least create a easy way to restrict the number o files in a field to 1 so we can create file-dedicated entities and have the integrity of only 1 file enforced, so thereās a 1:1 association between metadata and the given file?
Donāt you take any time off during summer?!! It all looks fantastic 
One thing I donāt see, though, is the possibility to hide/disable Buttons using filters.
It would really improve UX for some Entity views, for actions that can only be done once, or based on the state of the entity, or based on the user permission.
Is it on your radar?
Thanks for all the 
magic!
4 Likes
That is the reason why we will be happy if 2/3 of it will be done 
1 Like
In general I like this idea, it is similar to Comment as a first class citizen. We will think.
2 Likes
Please! This would make file management amazing! And is really in line with the Fibery way.
With the ability to set to-one or to-many relation for a file field as well.
And maybe a bit unrealistic, but what would be awesome if we could integrate/bring in/import our own file storage bucket/google drive/dropbox, where we we could make a relation to āfiles/dropboxā then anything uploaded there goes the dropbox integration. Or related to āfiles/google driveā and then things uploaded go into google drive. But just a bulk file import would already be awesome. You might need to start enfourcing storage limits then, but if you do, please add a way to expand storage as add on, or have unlimited storage in the enterprise.
8 Likes
This would be incredibly useful
1 Like
+1 for the Google Drive integration. I need to have files both in Google Drive, so users can easily handle them using Drive for Desktop, and also in Fibery where they can carry metadata and relations to other entities
1 Like
+1 for G Drive / G Workspace
1 Like
Google drive gang - put your votes where your mouth is 
: Google Drive integration
3 Likes
Buttons (and in general fields) hidden based on a formula would be very useful for proper user interactions. Conditional fields in apps
3 Likes
I totally agree with you! First of all, I honestly donāt want to duplicate storage for my files. At the moment, I keep all my important documents in Google Drive because itās just super convenient for sharing with people outside my company. On top of that, Google Photos is essential for managing all my images and videos, since I can organize everything by album there, and itās so much faster and more reliable for media management than any built-in solution.
What Fibery really needs isnāt just āyet another folderā for files, but a way to link and integrate with existing storage services. Ideally, Iād love to simply mention or attach files from Google Drive or even Google Photos directly in Fibery, without having to upload a second copy. That would make file management much more efficient and flexibleāplus, it avoids all the headaches of storage limits and duplicate files.
If you can make it so we can reference attachments already in Google Drive or Google Photos, it would be a massive step forward for real, scalable document and media management in Fibery!
2 Likes
Google Photos support is likely not practical. See here for recent API changes:
The best Fibery could do moving forward would be to provide you a way to āpickā specific images from your Google Photos library, and they would then be duplicated into Fibery and managed separately there. Changes in Google Photos would not be automatically reflected, etc. It is not much different from just downloading photos from GPhotos locally then re-uploading to Fibery. And even this may not be fully possible, with normal API access now an app can only access photos that were uploaded via that app, apparently.
Long story short I would not rely on Google Photos if you want a system for photo management that can be flexibly used in integration with other tools of any kind. It might be time to find an alternative if you have business use cases.
2 Likes
