Nov 16, 2023 / 🔒 Entity permissions (experimental)

[Chr1sG]

@aoe

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

Thanks. I understand that you need to be sure that data is not exposed, and I get that there is no point showing a relation if there is no content, but I was also trying to understand the possible situations where revealing the mere existence of a relation is concerning.
I mean, I can’t imagine a client would be upset to learn that there is a relationship to ‘Team’ or ‘Meetings’, and even knowing that you maintain ‘Time logs’ seems unlikely to be a great revelation(!)
I’m not sure what ‘Occupancies’ means, and so I don’t know the ways in which this might de worrying for a client to see. Anyway, overall, it helps to assess the wiseness of the decision to make the schema ‘open’. Would be really interesting to hear examples from other community members as well.

@aoe

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

And yeah, most users won’t query the schema via API anyway

[YvetteLans]

@antoniokov

Automatically providing access to Assignees and other linked users.

We’re really waiting on this one!

We are restructuring our spaces because we have so much more possibilities since access templates have been released

Will the ‘auto provide access to assignees’ be a standard feature or a setting on space level?

And will it also be an option in the access template? Or will that not be needed because of the auto access then?

[antoniokov]

@aoe

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

We are getting there, still in plans.

@aoe

And also this issue (bug?)

The root cause seems to be limiting access to Users: e.g. a client shouldn’t know about other clients. This is part of the planned DB-level access. Otherwise, I’m with @Chr1sG on this:

I think it is reasonable to allow users to share things they know with people they know (in the workspace).

Even if it didn’t behave like that, there would be nothing to stop someone with view access from taking screenshots or copy-pasting content, and I don’t know many tools that effectively prevent that 100%.

---

@YvetteLans

Will the ‘auto provide access to assignees’ be a standard feature or a setting on space level?

On the Field level: if you have a relation to User DB somewhere (e.g. Assignees, Owner, DRI), you can turn on automatic access via any access template, either a default or a custom one. At least, that’s the current plan

[YvetteLans]

@antoniokov

On the Field level

That’s even better Is there a rough ETA?

[antoniokov]

@YvetteLans

That’s even better Is there a rough ETA?

Unless we face unexpected obstacles, automatic access should be out before the nights start to get longer in the Northern Hemisphere

[YvetteLans]

@antoniokov

Unless we face unexpected obstacles, automatic access should be out before the nights start to get longer in the Northern Hemisphere

So before June 21st That’s awesome

[YvetteLans]

@antoniokov we are still struggling with the best set-up. And these decisions have a heavy impact on the workspace that we sell to customers so we want to avoid rework where possible.

• Previously we had many spaces (25), since access could only be provided on space level
• When access templates came, we went back to fewer spaces (7) with the idea that the access could be managed via the access template.
• After that we found out that currently a team member can’t create new items (like a task) via the access template, unless they have access to the full space where that database is in.

So now we are facing GDPR issues again Because if we give them full access, they can see every item in that space.

It would be really helpful to have a bit more information about the ‘automatic access feature’ that is coming.

• We know that access per database will take a while; so we don’t want to postpone our go-live for that. But how does the automatic access work? You said that the current plan was: “you can turn on automatic access via any access template, either a default or a customer one”. But will that also be an option on space level?

So that you have the option “Can view and edit only entities assigned to them and create new ones”

If so, then we can leave our set-up as it is now. Since a team member can’t see other ones stuff and can create new items.

If that’s not the plan, then it would be helpful to have a bit more information so we can decide what’s best.

Thanks!

[antoniokov]

Unfortunately, specifying who can create Entities of a certain Database requires Database access, so this is unlikely to happen before Q3 or even Q4 this year. We’ll make it right but it will take some time

Automatic access will only work on the Entity level.

Using Forms is the only current workaround for opening up Entity creation to someone outside of a Space that I can think of, I’m afraid.

[YvetteLans]

@antoniokov

Unfortunately, specifying who can create Entities of a certain Database requires Database access, so this is unlikely to happen before Q3 or even Q4 this year. We’ll make it right but it will take some time

Yes we understand. It’s awesome that it’s coming, but can imagine that it’s technically challenging

@antoniokov

Automatic access will only work on the Entity level.

That’s good to know.

Does that also mean that an option "Can view and edit only entities assigned to them and create new ones” for a whole space will not happen?

So the ‘contributor’ role that we currently have on space level, but then view rights added.

[antoniokov]

@YvetteLans

Does that also mean that an option "Can view and edit only entities assigned to them and create new ones” for a whole space will not happen?

So the ‘contributor’ role that we currently have on space level, but then view rights added.

Not only will this new option not happen, but we will likely deprecate the Contributor role once we have both DB access and automatic access for assignees.

The current Space access levels are a confusing mix of permissions on three levels:

• Space: who can share Space and create Views.
• Database: who can read and edit all the data inside the Space.
• Entity: who can edit specific Entities they are assigned to.

We are looking to untangle this knot to both make it obvious who gets access to what and unlock new use cases by combining DB and Entity access independently.

[YvetteLans]

@antoniokov

Not only will this new option not happen, but we will likely deprecate the Contributor role once we have both DB access and automatic access for assignees.

The current Space access levels are a confusing mix of permissions

I agree, great that you guys are looking into this

It’s still a bit blur what our set-up should be given the fact that automatic access on entity level is coming. We want to achieve that a user should be able to view and edit items they are assigned to.

Let’s say we want this for the SOP database.

The SOP database is currently part of the operations space which has multiple databases. A basic team member can only have access to the SOP database.

Will the user have auto access (when that’s set on entity level) to all SOP’s they are assigned to, even when they don’t have access to the whole space?

• If so, I don’t need to create multiple spaces
• If they need both space access and automatic entity level access, I need to create multiple spaces

Thanks again!

[antoniokov]

@YvetteLans

Will the user have auto access (when that’s set on entity level) to all SOP’s they are assigned to, even when they don’t have access to the whole space?

Yes, they will.

[YvetteLans]

Awesome, thanks!

[YvetteLans]

@antoniokov will the auto access functionality be included in the Standard $10 version or only in Pro $17 version?

[Illusory]

@antoniokov

We are looking to untangle this knot to both make it obvious who gets access to what and unlock new use cases by combining DB and Entity access independently.

Very much looking forward to the ability to do this.

Would also like to see bulk shared access updates on single entities so that we don’t need to update them 1 by 1 when we add a new team member or change processes.

Lastly, when a user has 1 or more entities shared, I’d still like them to have access to it in the sidebar. e.g. We have a company wiki but want to hide a collection of docs for devs only and collection of docs for operations only. I’d still like them to have the ability to use the space and created views, just not be able to see entities not shared with them.

[antoniokov]

@YvetteLans

will the auto access functionality be included in the Standard $10 version or only in Pro $17 version?

We haven’t decided yet — so far it’s 50-50, I’d say.

P.S. We’ve forgotten to lock custom access templates for non-Pro workspaces after they left beta, so you can tell we are not thinking about monetization before we are sure the value is there. Consider the last few months a grace period

[antoniokov]

@Illusory

Would also like to see bulk shared access updates on single entities so that we don’t need to update them 1 by 1 when we add a new team member or change processes.

Makes sense.
Do you use Groups to manage Space access?

@Illusory

I’d still like them to have the ability to use the space and created views, just not be able to see entities not shared with them.

Now Space access includes both Views and data. Once we have DB-level access this knot should be untied

[YvetteLans]

@antoniokov

We haven’t decided yet — so far it’s 50-50, I’d say.

Although I really think Fibery is worth every penny, I also think that it can give you guys a real big competitive advantage. Just my two cents

@antoniokov

P.S. We’ve forgotten to lock custom access templates for non-Pro workspaces after they left beta

It’s a sign of the universe

[antoniokov]

@YvetteLans

Our databases are quite large and especially for note + task database we want to set permissions based on assignee and linked users. Currently it’s a big PITA that a user can find entities via search and linked entities.

@HereBeBeasties

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.

Here we go: June 13, 2024 / Automatic access for assignees, return to expanded panel

Here is the user guide. Please let me know if you have any questions

[HereBeBeasties]

I have no questions, only expressions of love and gratitude to the Fibery team for making things awesome-r. Love the assignee entity perms stuff - unlocks a bunch of HR-type use-cases. Thanks.