# Nov 16, 2023 / šŸ”’ Entity permissions (experimental) **URL:** \ **Category:** Changelog\ **Created:** [November 16, 2023, 4:37pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414 "2023-11-16T16:37:19Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![ccollins](https://avatars.discourse-cdn.com/v4/letter/c/bbe5ce/32.png) [@ccollins](https://community.fibery.io/u/ccollins)\ **Post date:** [December 1, 2023, 5:44pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/21 "2023-12-01T17:44:31Z")
A use case Iā€™m trying to figure out right now: 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. ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [December 1, 2023, 9:39pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/22 "2023-12-01T21:39:47Z")
> [@ccollins](#): > > I can restrict views, but those consultants will still be able to see everything in their ā€˜My Spaceā€™. 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. > [@ccollins](#): > > 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. 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? ---
**Author:** ![ccollins](https://avatars.discourse-cdn.com/v4/letter/c/bbe5ce/32.png) [@ccollins](https://community.fibery.io/u/ccollins)\ **Post date:** [December 1, 2023, 11:17pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/23 "2023-12-01T23:17:22Z")
No unfortunately it doesnā€™t. We want the consultant to _create_ opportunities. > [@Chr1sG](#): > > You can use the standard space/database rules and then use entity sharing to increase access where necessary 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) ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [December 1, 2023, 11:53pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/24 "2023-12-01T23:53:46Z")
> [@ccollins](#): > > We want the consultant to _create_ opportunities. Thanks for the clarification. There will be some features released in the new year that will support your use case. ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [December 4, 2023, 2:52pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/25 "2023-12-04T14:52:01Z")
> [@ccollins](#): > > 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. 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. ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [December 8, 2023, 3:57pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/26 "2023-12-08T15:57:49Z")
![custom-access-template-create](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/1/14f65e9a1f9d93f0efb0bd6e9db2e7d7262f06c0.gif) From now on, you can specify how exactly access should be extended by using [custom access templates](https://the.fibery.io/@public/User_Guide/Guide/Custom-Access-Templates-240): > [@Dec 7, 2023 / christmas\_tree Find References in text using AI, Custom access templates, Add many entities to Whiteboard](https://community.fibery.io/t/dec-7-2023-find-references-in-text-using-ai-custom-access-templates-add-many-entities-to-whiteboard/5500): > > Fibery team is in [Slow December mode](https://community.fibery.io/t/were-in-slow-december-mode-till-january-1st/5485), but we still have something to release. unicorn Find References in text using AI (experimental) Fibery can analyze some text and [find references in it automatically using AI](https://the.fibery.io/@public/Public_Roadmap/Roadmap-Board-5974#User_Guide/Guide/Find-References-in-text-using-AI-239), so you can create References and process information better. What are use cases? Interviews processing. You may analyze interviews and tag relevant paragraphs. Product feedback processing. For example, you have feedback from Intercom or Discourse and want to link itā€¦ Itā€™s an experimental feature, so the feedback is more than welcome! ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [December 9, 2023, 1:50pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/27 "2023-12-09T13:50:05Z")
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. ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/b/b6df072e71a2693640ea7cd6a4497f651282d5c2.png) * * * 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. ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/5/5040797e05c914eab71dd560725097fd16752d12.png) * * * 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! ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [December 9, 2023, 4:13pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/28 "2023-12-09T16:13:27Z")
> [@aoe](#): > > The reason being that we could have relation names that we donā€™t want to have exposed. 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 > [@Customizable Entity View. Shown Fields per User](https://community.fibery.io/t/customizable-entity-view-shown-fields-per-user/5422): > > 1 sentence request: Show/hide fields state in an entity view (for a specific database) per user (I say specific database because I expect the hidden fields settings to apply to all entities in the same database just like it is now, no craziness about unique settings per unique entity) I created a draft of a solution for a company in my free plan. I have a Contracts database that links to Operations orders and Invoices (just an example, in the future could link to many other databases). The prā€¦ and the topic linked in that discussion. > [@aoe](#): > > I was reminded again that it would be nice to use Roles to give access to many users at the same time I expect that will be delivered in Jan or Feb next year šŸ¤ž ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [December 10, 2023, 7:13am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/29 "2023-12-10T07:13:57Z")
> [@Chr1sG](#): > > 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). 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. Waiting for Q1 then šŸ™‚ ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [December 10, 2023, 8:34am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/30 "2023-12-10T08:34:13Z")
> [@aoe](#): > > 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ā€¦ > Waiting for Q1 then 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. ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [December 10, 2023, 8:40am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/31 "2023-12-10T08:40:12Z")
I understood what you meant. 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. ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [December 11, 2023, 8:03am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/32 "2023-12-11T08:03:14Z")
> [@aoe](#): > > 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? It does! 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. > [@Chr1sG](#): > > I expect that will be delivered in Jan or Feb next year šŸ¤ž A slight correction of expectations for Groups support in entity permissions: letā€™s make it Feb-Apr 2024 šŸ™‚ ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [December 11, 2023, 8:59am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/33 "2023-12-11T08:59:35Z")
Thank you @antoniokov, that sounds encouraging! ---
**Author:** ![HereBeBeasties](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/herebebeasties/32/5429_2.png) [@HereBeBeasties](https://community.fibery.io/u/HereBeBeasties)\ **Post date:** [January 23, 2024, 8:25pm UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/34 "2024-01-23T20:25:39Z")
ccollins wrote: > 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? ---
**Author:** ![antoniokov](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/antoniokov/32/201_2.png) [@antoniokov](https://community.fibery.io/u/antoniokov)\ **Post date:** [January 24, 2024, 10:05am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/35 "2024-01-24T10:05:44Z")
> [@HereBeBeasties](#): > > Any news on when? I canā€™t see it on the roadmap. No news so far. Most likely itā€™s gonna be Q2-Q3 2024, we are still committed. Thanks for the detailed use cases! They should all be possible with the combination of: 1. Automatically providing access to Assignees and other linked users. 2. Specifying who can create Entities of a particular Database (part of DB access). > [@HereBeBeasties](#): > > Is there a way to set entity permissions via automation? Not yet, no definite plans for now ā€” weā€™ll start from #1 above and it might turn out to be related. ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [March 7, 2024, 8:03am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/36 "2024-03-07T08:03:20Z")
> [@antoniokov](#): > > > [@aoe](#): > > > > 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? > > It does! > > 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. Hi @antoniokov! Any news on this one? Itā€™s mostly this part which is holding us back from inviting clients šŸ™‚ > [@aoe](#): > > _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. > ![image](https://us1.discourse-cdn.com/flex020/uploads/fibery/original/2X/5/5040797e05c914eab71dd560725097fd16752d12.png) And also this [issue](https://community.fibery.io/t/a-guest-user-can-see-invite-all-existing-users-in-a-workspace/5948) (bug?) ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 7, 2024, 8:16am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/37 "2024-03-07T08:16:24Z")
> [@aoe](#): > > 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. 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? ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [March 7, 2024, 8:24am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/38 "2024-03-07T08:24:46Z")
> [@Chr1sG](#): > > FWIW the schema details (including field names) are not permission controlled, i.e. any user can theoretically query the schema. Yes querying the API is fine, Iā€™m looking for a UI solution which would handle \>95% of cases (guessing here) * * * > [@Chr1sG](#): > > Out of interest, can you give an example of where the name of the field is something you donā€™t want certain users knowing? * * * Yes, the second image here. Occupancies / Time Logs / Teams + any other relation Iā€™ve not given explicit access to. > [@Nov 16, 2023 / lock Entity permissions (experimental)](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/27): > > 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ā€¦ * * * > [@Chr1sG](#): > > We do plan to improve the UI to allow finer control over whether/where fields are shown Any rough estimate on this? ---
**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\ **Post date:** [March 7, 2024, 8:38am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/39 "2024-03-07T08:38:18Z")
> [@aoe](#): > > Occupancies / Time Logs / Teams + any other relation Iā€™ve not given explicit access to. Can you explain why it is a problem for some users to see that there are relations with these names (apart from the clutter)? > [@aoe](#): > > Any rough estimate on this? Iā€™m sure any estimate I gave would be wrong šŸ˜‰ I can say that entity view is being actively worked on, so \< 6 months is possibly not too badly wrong ---
**Author:** ![aoe](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/aoe/32/6018_2.png) [@aoe](https://community.fibery.io/u/aoe)\ **Post date:** [March 7, 2024, 8:49am UTC](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414/40 "2024-03-07T08:49:02Z")
> [@Chr1sG](#): > > Can you explain why it is a problem for some users to see that there are relations with these names (apart from the clutter)? Clutter is definitely one part of it. 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 šŸ™‚ > [@Chr1sG](#): > > Iā€™m sure any estimate I gave would be wrong šŸ˜‰ I can say that entity view is being actively worked on, so \< 6 months is possibly not too badly wrong Thank you, thatā€™s a rough estimate (which is fine šŸ˜‰) [Previous page](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414.md?page=1) [Next page](https://community.fibery.io/t/nov-16-2023-entity-permissions-experimental/5414.md?page=3)