We have a space (w/ several databases) to track new business opportunities. We have brought in some consultants that we want to contribute to this space, but we only want them to see opportunities they create. I can restrict views, but those consultants will still be able to see everything in their āMy Spaceā.
The new entity permission functionality seems to be only accessible at each entity, rather than being able to create some wide-sweeping rules from the database level and then fine tune those rules at specific entities when necessary.
My Space only ever contains documents/views that a user has created themself, and what the views can show is limited by permissions - it doesnāt affect access in any way.
You can use the standard space/database rules and then use entity sharing to increase access where necessary. So for example, you could not grant the consultants access to any spaces/databases at all, but then grant them access to specific opportunities (and thereby to any items directly linked to these opportunities).
Does this not come close to satisfying your needs?
No unfortunately it doesnāt. We want the consultant to create opportunities.
If I give the consultant anything above āNo Accessā in the database permissions, then theyāll be able to create a view in My Space to see every single opportunity in that database. Thatās not an option.
But if instead we give them āNo Accessā to prevent this, then there is no way for them to create new opportunities.
Maybe through a form? But they might create 5-10 per day. So then I would have to check every day for new entities and share them with him manually. And then thereās a lag where they canāt see their new entities because they are waiting until someone remembers to check and share it.
Unless - maybe I could create a new database for user companies. Then have an automatic relationship on opportunities that looks up that new database based on the creator. Then even if I have the consultant as āNo Accessā on the database permission, I could give the consultant permissions to that automatic linked company and extend it to opportunities. I will try this. (Update: this does not work. Because if the consultant has āNo Accessā to opportunities then he canāt use the form)
This is, obviously, a completely valid scenario that weāve kept in mind while designing the new permissions model.
The permission to create an Entity lies at the Database level, not at the Entity level (since thereās no Entity yet), so our latest entity permissions are not enough. Weāll have to wait for Database access ā planned for 2024.
Also, we are looking to replace the current Contributor Space-level access with something more generic. The goal is to avoid manually providing access to each consultant, but rather configure things once and forget about them.
I had a little bit of time to try out the access templates with a guest user. The goal was to simulate what it could look like if we would invite a client.
This is the access template. There are many more relations from each database but this is what we want the client to see and have access to.
Within a Project, the guest user can see Tasks and Meetings (the way it was setup) and none of the other entities within Occupancies, Time Logs or Teams. This is fine.
What I did expect (or want to happen) is that the user interface groups would be hidden in the user interface. The reason being that we could have relation names that we donāt want to have exposed. It would also create an overall less cluttered experience.
Overall it looks and feels promising! I like the granular control that you get and that you can easily add related databases to manage everything from one template. I was reminded again that it would be nice to use Roles to give access to many users at the same time, e.g. all users with the role of Employee should be able to see this Management-team meeting och a specific Issue that the Management team wants input on (viewing and commenting).
Iām going to try other use cases whenever I get the time again!
As it stands, and for the likely foreseeable future, we do not implement access control for the structure of a workspace. That is to say, the fact that db X has a relationship to db Y is not considered protected information.
Of course, there is the possibility that we would implement UI functionality that limits which relations are visible to any given user, but it would not be a strict access control mechanism (it would not stop a user querying the schema via API for example).
I suspect your use case is more covered by this
and the topic linked in that discussion.
I expect that will be delivered in Jan or Feb next year
Simply hiding the UI relations, which a user should not have access to based on the access templates, would get us probably 95% of the way and would be acceptable. Iām not asking for full per user, per field access control.
I think youāve misunderstood what I meant. This capability is not in plans for access templates. It is a completely different use case/feature.
Youāre welcome to vote for the linked topic (and the one it mentions) but there is no expectation/guarantee that we will work on it next year.
Iām simply trying to let you know, that when you set access templates to only include certain relations, it comes with the expectation that only those relations are visible. Does that make sense?
I think missing this key thing will make entity permissions/access templates be used much less than it would be otherwise. Iām sure weāre not the only ones with this request. It would be fine if itās just hidden in the UI since no actual entities are seen.
For us, simplifying the UI for people with less access comes as a natural next step after introducing granular access. For example, the left menu is now basically useless for users without Space access, and weāre gonna address this as well as the cluttered Entity View and anything else that hinders adoption.
A slight correction of expectations for Groups support in entity permissions: letās make it Feb-Apr 2024
We have brought in some consultants that we want to contribute to this space, but we only want them to see opportunities they create.
antoniokov wrote:
Weāll have to wait for Database access ā planned for 2024
Any news on when? I canāt see it on the roadmap.
I see automatic entity permissions based on fields on the entity as an absolutely critical use-case. Without it you basically need a space admin to go around assigning permissions to everyone, which clearly isnāt at all reasonable for things like doing performance reviews, etc.
My concrete use-cases all involve having a non-space-permissioned user create an entity (fine with doing that in another Space from a Form), and have that entity automatically be editable by its creator, and also viewable/editable by whichever user(s) are specified in any of several 1:1 or 1:many fields.
A self-appraisal, or performance review (editable by creator, viewable by manager/direct report)
A more complex set-up for the above:
Performance review for an employee (e.g. Q4 2023 for āAliceā) containing linked 1:1 entities:
Self-appraisal (candidate edit only)
Manager feedback (manager edit only)
Goals (joint edit, maybe a 1:many list of items)
Confidential meeting minutes (editable by all attendees)
Candidate tracking (GDPR, baby!) - candidate editable by hiring manager and viewable (maybe editable) by assigned interviewers, with the ability for them to create linked interview feedback entities editable by themselves, viewable by other interviewers
Is there a way to set entity permissions via automation?
FWIW the schema details (including field names) are not permission controlled, i.e. any user can theoretically query the schema.
We do plan to improve the UI to allow finer control over whether/where fields are shown, but itās worth being aware that it wouldnāt stop someone from querying the schema if the wanted to.
Out of interest, can you give an example of where the name of the field is something you donāt want certain users knowing?
But mostly that we may have internal business logic relations that we donāt want to expose. And if we would add relations in the future (it happens although seldom) we donāt want to have to worry whether clients are going to see stuff that they should not. It will detract us from using Fibery freely/to its fullest.
It just makes the most sense (for us) to only display relations that a user has been explicitly given access to. I canāt imagine we are the only business thinking about this
Thank you, thatās a rough estimate (which is fine )
I can say that entity view is being actively worked on, so < 6 months is possibly not too badly wrong