Nov 16, 2023 / 🔒 Entity permissions (experimental)

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.

2 Likes

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?

1 Like

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)

2 Likes

Thanks for the clarification. There will be some features released in the new year that will support your use case.

4 Likes

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.

5 Likes

custom-access-template-create

From now on, you can specify how exactly access should be extended by using custom access templates:

It’s an experimental feature, so the feedback is more than welcome!

3 Likes

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.
image


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 :crossed_fingers:

1 Like

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 :slight_smile:

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 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.

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.

A slight correction of expectations for Groups support in entity permissions: let’s make it Feb-Apr 2024 :slight_smile:

4 Likes

Thank you @antoniokov, that sounds encouraging!

1 Like

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?

2 Likes

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).

Not yet, no definite plans for now — we’ll start from #1 above and it might turn out to be related.

4 Likes

Hi @antoniokov!

Any news on this one? It’s mostly this part which is holding us back from inviting clients :slight_smile:

And also this issue (bug?)

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?

Yes querying the API is fine, I’m looking for a UI solution which would handle >95% of cases (guessing here)



Yes, the second image here.

Occupancies / Time Logs / Teams + any other relation I’ve not given explicit access to.


Any rough estimate on this?

Can you explain why it is a problem for some users to see that there are relations with these names (apart from the clutter)?

I’m sure any estimate I gave would be wrong :wink: I can say that entity view is being actively worked on, so < 6 months is possibly not too badly wrong

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 :slight_smile:

Thank you, that’s a rough estimate (which is fine :wink:)