[IN DEV] Entity-level permissions

Have you considered view level permissions as well? For instance if i share only a specific view with someone who has no access to the parent app, could only have view or edit rights to the entities visible on that shared view and this method could also limit the available fields (to view or edit) that are visible on the shared view.

Also for entity level permissions it would be great if someone could automatically get permissions for an entity that is related to his/her user entity. This way everybody could edit their but only their time log entries for instance. So there is a Type that everybody can create new instances of, but can only see and edit their own entities

This can be the next step, entity-level permissions should work to do it. Technically View will be a container so it might be possible to define what entities it contains. Note that this is quite challenging anyway, since you can change Filters and all entities visible on a View can change dramatically. However, it’s seems possible to implement in future.

Field level permissions will never be implemented though.

This will work out of the box.

1 Like

Entity-level permissions is not in the Public Roadmap?

1 Like

An important feature for enterprise use is the ability to configure the permissions on a Database so that certain groups can create entities, but not see other users’ entities, even if they are in that group that allows them creation permissions. A user should usually also be able to see any entities that they created like this, leave comments on them, and optionally also edit them (maybe you want to let them amend the description, maybe not).

Use case: Acme.com are using Fibery as an issue tracker. They want to allow a Alice to raise an issue about payroll with HR, without the rest of the company being able to see it, and without Alice being able to see all the other HR tickets that are none of her business. Alice should automatically be able to see tickets that she has created without HR having to add permissions for her manually, and comment and possibly edit them too.

More generally, I strongly recommend you validate your permissions model against JIRA’s and ensure you can model such behaviour with yours, where feasible. Theirs isn’t perfect, but it does cover a lot of genuine use cases people have: Managing project permissions | Administering Jira applications Data Center and Server 8.22 | Atlassian Documentation

1 Like

I believe this will be possible, but it probably won’t be one of the default access levels.

If you wanted, you could define an access level which has create capability but no view capability. It sounds weird and contradictory, but it would work in parallel with inheritance of view (and maybe edit) capabilities from the user database. In that way, only items for which you are creator (or maybe assignee) will be visible.

At least, I think this is how the permissions model may be intended to work :slightly_smiling_face:

3 Likes

I understand that things can get deprioritized sometimes, but 2 weeks is something else then 5 months. And it’s still not on the public roadmap. Are you really planning to do this one?

3 Likes

I know how it sounds, but we have only one developers who is capable to do it. Now he is finally ready. But I will no make new promises :slight_smile:

8 Likes

Super excited for this! I can’t wait to build a better Buildertrend/CoConstruct :man_construction_worker: in Fibery :hammer_and_wrench:

1 Like

Just want to emphasize this.

On the public roadmap board the visible metric is “recent requests”, giving the impression that highly requested core features like entity level permissions or entity views that might be harder to implement are either silently deprioritized or completely taken out of the roadmap.

But happy to hear that this is not the case. Entity or even entity+field level permissions (view, edit) would add another level of viability to Fibery.

May I get an update or rough ETA on this?

We have many administrative pain points currently that I can imagine could be fixed by using Fibery institute-wide (~130 employees). However, without entity-level permissions, I cannot even remotely make a case and don’t want to spend time evaluating this without knowing it’s on the horizon.

We are working on technical details, implementation still not started. Here is today’s update.

3 Likes

Thanks Michael!
Would you suspect it might take longer than 6 months? I’m not gonna take your word on it but just to have a rough feeling whether we talk about months or years.

1 Like

I gave up estimating this. We will have some ideas when implementation starts. But 6 months look too optimistic right now. We’ll see

6 Likes

Some progress report

Feb 22

Feb 23

6 Likes

Some progress report

11 Likes

I am looking forward to this! It really opens up so many possibilities! :blush:

Thanks for your good work, keep it up! :muscle:

2 Likes

Some update

7 Likes

Can’t wait for this. Sick of people who shouldn’t have permission accidentally updating things.

Does this also include Database level permissions, e.g. being able to limit who can create new entities in certain dbs?

1 Like

That is intended to be supported, yes.

4 Likes

this would be fantastic.

is there any news or speculations on when we can try this? or is there a workaround that can be used at the moment.

my example usecase would be: as i am currently trying out going back to the “daily note” system i started using with obsidian two years ago and lost while switching over to clickup, i am wondering if i could use my “company daily note” also as my “private” one. and just mark linked entities that I create (meetings, logs) as private so they dont show up on other peoples lists.

this would also be something to add: I read about blocks in documents. as this would be amazing to link, share, embed blocks (and also move blocks around) the addition of permissions for blocks would make this even more exciting.

It also would be great if a space is set to “public” (or shared via full access/read only…) - that i can mark a single entry as “PRIVATE” like in the image example “log” … this way i dont have to mark every single one as shared, but can set a property field to do that.

How are you keeping private and public information separate but “together” when viewed as yourself? or are you not doing that?

Also what happens at the moment with entities that are in a not-shared space when they are linked to other shared spaces? f.e. when I have an entity linked in a document … currently these are then “no found” … in other discussions people would like to have this name information turn into text.but with private notes this is maybe not the best way to handle it?