This is an invitation to brainstorm about handling user-level permissions in Fibery.
Challenge: user-level permissions is currently not supported. Only if each user has their own space this theoretically would be possible but practically unmanageable and resource intensive.
Workarounds for now could be:
Secure Document Integration: Use services with built-in access control for document linking or embedding (e.g. embed Google doc).
Encryption & Decryption Service: Implement an external service for encrypting data before it enters Fibery and decrypting upon authorized access.
Automated Access Scripting: Deploy scripts for access control based on credentials, utilizing Fibery’s API for dynamic permissions management.
Custom User Authentication Extension: Create a browser extension for enhanced user identification and data access control directly within the user’s interface.
I’m not sure what you mean by ‘user-level permissions’.
Fibery permissions (both space- and entity-level) are applied on a per-user basis.
And since it is possible to have databases where access to individual entities is controlled per user, there is no requirement to have a space per user.
It is true that Admins have access to all spaces in a workspace (except for things stored in ‘My Space’) so individual users are not able to create completely ‘private’ databases.
But it’s also worth noting that Fibery is intended to be a collaborative tool for teams/businesses, so if you need to store data that is for your eyes only, then Fibery is possibly not the tool for you.
Perhaps you have a concrete example of something that you think is not currently possible in Fibery, but which ought to be (within the scope of a tool that acts as a ‘work and knowledge hub’).
Sorry for the unclear use of terminolgy. What refer to is actually ‘visibility access’ and your answer is on Fibery’s entity-level action control. Fibery can manage what a user can do to an entity, but not entirely whether they can see it .
In this post I focused mainly on the individual ‘private data’ but I realize that this will soon already be possible when the next level of ‘entity level permisisons’ is rolled out in Q1/Q2 this year. See AntonioKovs comment here
This is likely the most wanted feature in Fibery as far as I can see. Because of:
HR Information: Employee records, performance reviews, salary data, health information. Limiting visibility ensures only authorized HR personnel have access.
Financial Data: Detailed financial reports, budgets, and internal projections should be restricted to relevant teams and executives.
Intellectual Property: Safeguarding trade secrets, patents, and development plans often necessitates strict visibility controls.
Whether visibility access is enough
If Fibery implements visibility access as expected, users will be able to manage data privacy more effectively; they could restrict who can see specific entities. Still:
Admins might still have overarching access.
Visibility control isn’t the same as encryption. For extremely sensitive data, additional security measures may be needed.
I will close this topic because at least visibility access is already on the roadmap, and that may shed light on further features regarding sensitive data.
Actually, Fibery’s entity-level permissions do allow you to control both what a user can do and what a user can see.
The functionality in the thread you linked to has mostly already been rolled out.
In particular, custom access templates are incredibly flexible, and as far as I can tell, all of the use cases you mentioned (HR, finance, client data, IP) are already possible.
In terms of information security, I suggest that you read Fibery’s security policy for how encryption is implemented.
That would be awesome! However, I dont see anything in the guide text directly stating that granular, entity-level visibility restrictions are currently implemented. The guide centers on controlling what a user can do (view, comment, edit, etc.) with entities they already have some level of access to.
The only hint given, is the text under heading ‘Groups’ :
“simplify access management in larger workspaces: share Spaces (and later Entities) with entire Teams, Roles, or Tribes.”
I think that is what AntonioKov referred to in his post?
However, maybe I’m not yet understanding what you mean. Can you help me with the following example?
The Scenario:
Databases:
Projects: Contains entities representing each team’s individual project work.
Financial Data: Contains entities holding detailed financial records.
Project Entity Fields:
Team: (single-select relation) Links each project to the relevant team.
Financials: (many-to-many relation) Connects a project to specific financial entries in the “Financial Data” database.
Role & Team Restrictions:
Team A’s CFO should see a “Financials” section within their project entity populated with related records in the “Financial Data” Database with permissions limiting access to only Team A entries.
Team B’s CFO: Same visibility requirements, but exclusively scoped to Team B’s financial records.
Other Project Members: See the project entity structure, but the “Financials” section itself is either non-existent in their view or accessible to only those records essential for their task-related financial awareness.
As far as I understand, Fibery’s current limitations are in this case:
One Database, One Permission Set: The “Financial Data” database likely has consistent entity-level permissions across all its entities. Teams A and B need different visibility rules without breaking financials into separate databases (bad for consistency)
Context Views Help, But…: Contextual Views would improve scalability on the Projects side. However, complexity could still arise if financial visibility rules themselves get highly nuanced (e.g., role-based restrictions within a single team)
Spaces Too Broad: Separate projects into Team Spaces for security, but prevents company-wide reporting or easily sharing resources without complex syncing strategies.
Access to users
The user guide mentions upcoming ‘Access to Users’ feature, this sounds intriguing. Does it include the ability to set visibility rules across parent-child entity relationships as currently, permissions seem largely action-based?
I’m not sure I understand.
If a user does not have any access to a database, he/she can be granted access to a specific entity (and its related entities) at whatever level you want, including view-only. Isn’t this ‘visibility restrictions’?
Entity-level access does already exist.
The detail you quoted to refers to being able to grant in batch to a group of users (as opposed to granting to a single-user at-a-time basis). See later in this comment.
Wrt your proposed scenario, here’s what I imagine the databases/entities might look like, and what you would want to do with permissions (as currently possible):
Relations:
Team → Projects
Projects ↔ Financials
Team entities:
Team A
Team B
Project entities:
Project X (Team A)
Project Y (Team A)
Project Z (Team B)
Financial entities:
Financial 1 (Project X)
Financial 2 (Project Y)
Financial 3 (Project X and Project Y)
Financial 4 (Project X and Project Z)
For an admin, this would look like this in a table view:
The space(s) where these databases are stored should be configured with no access for any users.
Now, you would need to define two custom access templates:
Now you need to grant access accordingly, using the Share button on each Team entity. So if Freddie is CFO for Team A, and Mary is only a team member, this is what that would look like:
When this is all done, this is what Freddie sees when he signs in and looks at Team A:
(he is able to see Team A and the related Projects, and can edit the related Financials)
Meanwhile, this is what Mary sees:
(she is able to see Team A, edit the related Projects, but has no insight into the Financials)
If it helps, you can create a space (with no databases) where you can add useful views, e.g.
I believe this gets what you want. What do you think?
And this functionality can be scaled to achieve almost any role-based access permissions you might want.
Future
There are still some nice-to-haves which are not yet possible, but should be possible soon:
granting access automatically based on relations, e.g. you don’t have to configure entity-sharing every time a new person joins the company, you just link them to the entity:
(this would also include automatically granting access to the user who is the ‘Created By’ user)
entity-sharing based on membership of group, e.g. you don’t grant ‘Finance officer’ access to just Freddie, but rather to a set of users who are part of a role group
more configurable database-level permissions, e.g. allowing users to create new entities, see just the ones they have created, but not allowing them to edit entities (including ones they have created).
This could be useful for example for bug reporting, so a user can post a bug report and follow it’s progress, but nothing more.
If you think there is something missing, let us know.
Thank you @Chr1sG for your detailed case example explanation. Greatly appreciated! I have experimented with different setups and it indeed works as you say. Your answer would be great to include in the user manual.
About the future features you mentioned:
Granting access automatically based on relations: this would be indeed simplify the workflow for membership onboarding of a particular entity (organization, team, project or document membership)
Entity-sharing based on membership of group: Yes! and this is particularly useful for dynamic teams where members frequently change, and access to particular documents can be done by creating access groups for such documents.
Team membership and permissions transparency
Playing around with similar setups and access templates, I see that the insight in permissions can be very opaque or absent for users working with other users in Teams, Projects and content.
For example:
If Jack has received access to Project X and its content only, then Jack will not be able to see who has access to the project’s parent entity Team A.
If Jack clicks on the ‘Share’ button in Projext X, he will only see project members of Project X, and will not see that Freddy the Finance Officer has access to Project X, nor that Freddy is seeing everything that Jack shares in Project X.
I see three topics to address here:
Trust: Transparency within teams is crucial for building trust. If team members are unaware of who has access to their shared information, it could erode trust and impact team dynamics negatively.
Privacy: Team members might have expectations of privacy or confidentiality regarding the information they share, especially if it pertains to personal or sensitive business matters. Violating these expectations without clear justification can be ethically questionable.
Policy: The organization’s policies and culture around information sharing and privacy play a significant role. Although Fibery is more like Lego, some guidance to create a privacy/transparency policy when constructing fibery spaces may be important.
Access Template Instances as entities
The team probably already thought about this: A practical approach for enhancing permission transparency in Fibery could involve displaying access instances as entities. This would allow to show a list within each project, team, or document entity that shows all users who have access to it. This could be implemented using the existing entity and relationship functionalities in Fibery.
There are use cases where an admin will not want every user to know about every other user and their access. Imagine I have a project with a number of freelancers working on it. I do not necessarily want one freelancer to know who the other freelancers are.
Eventually, the User database will also support entity-level permissions, so that the admin can choose who gets to see other users, and the choice of transparency vs privacy is in the hands of the workspace owner.
We are thinking about optimal ways to manage/visualise permissions in Fibery. The capabilities are highly flexible, but it is true that this can make it hard for users to understand who can do what (orthogonal to the question of whether a user should be allowed to see other users).
For completeness, less recap what we have and what we are missing:
Clarification of Current Permissions Setup
Confirmed Use Case: We’ve established that a financial officer can view and edit financial records of their own team, while not accessing the financial records of other teams. However, the financial officer cannot create new financial records
Limitations in Entity Creation Permissions
Crucial Requirement Missing: The ability for team roles to create entities within their own teams is not addressed. This capability is essential, especially in organizations where team-specific data generation is frequent.
Real-World Implications: Without the option to assign creation rights within specific permissions templates, Fibery requires users to adopt a less efficient setup. This limitation complicates deployment in larger settings where dynamic data handling is necessary.
Current Workaround and Its Challenges
Separate Spaces for Each Team:
To manage permissions effectively under the current system, organizations must create isolated spaces for each team.
Duplication of Databases:
Each team space requires its own set of duplicated databases.
This includes duplicating project, task, and financial data databases individually for each team.
Impact:
It’s not just an issue for larger projects but also for small teams, especially when a basic function like creating team-sensitive content is hindered.
Also, this limitation affects even single-team setups, where a finance officer should perform essential tasks without being able to view ALL content in the space (thus not be space member).
With other words, Fibery currently requires an organization to have this setup:
Space A
Team (Shared database)
A-Project (Unique database)
A-Task (Unique database)
A-FinancialData (Unique database)
Space B
Team (Shared database)
B-Project (Unique database)
B-Task (Unique database)
B-FinancialData (Unique database)
We already have plans to improve database-level permissions, including adding the ability to create entities without necessarily seeing other entities.
