Basic Best Practices Usage Permissions & One Table vs. Multiple Tables

Get Help
1

Hi brainiacs. :brain:

I’d love your feedback on the following concept I’m still struggling to grasp:

Lets say I have 4 spaces:

  • Rob is a personal space for me.
  • Airpa is a project space/new business that some members have access to.
  • Managers is for managers and me.
  • SA is for everyone.

I am (1) using this as a personal & business communication/knowledge tool and (2) rather slowly migrating multiple people of multiples companies over. I’m not worried about multiple Workspaces for now.

Let’s ignore for a moment the many databases that can be important for a business: CRM, project tracking, scrum, etc.

For right now, I seem to have arrived 3 main types of entities::

  • Task Database: Action > Task > Sub-Task
  • Item Database (often resources, importantly they are non-tasks).
    • Type Column: Agenda, Library, Meeting, etc. (things we categorize).
  • Guide Database

This results in the following 12 databases due largely to managing permissions (most certainly incorrectly):

  • Rob Space
    • Task
    • Item
    • Guide
  • Airpa Space
    • Task
    • Item
    • Guide
  • Managers Space
    • Task
    • Item
    • Guide
  • SA Space
    • Task
    • Item
    • Guide

I believe this is overkill and unnecessary, right? Because it’s duplicating the same ‘thing’ (databases) in multiple places (spaces)? Do you concur?

Why did I set it up this way?

  • We built a custom browser extension that improves on the existing Fibery extension by offering faster usability, keyboard shortcuts, more options, and more specificity of fields than the current Fibery extension and I can quickly put, say, a task in any of those spaces and retain the appropriate permissions.
  • I previously tried a setup that had a database called Item and a Type field (things like Task, Agenda, Meeting, etc.). Quick entry of items was more difficult because I had to choose the database and the Type selection for that field – and that did not come out-of-the-box in the Fibery extension or in normal Fibery usage without creating an automation/button (e.g. you’re in a rich-text description field of an entity – write a phrase of text – create a new entity out of it – and you don’t have the immediate option to add “Type” [I know how you can as a second step]). Also, at the time it was easier when using iPaas applications like n8n, pipedream, and make.

It should be noted that I have the highest-level account type of Fibery and have not started using team permissions.

So two questions pop out:

If I leverage the team permissions, can/should I do this instead:

  • Global Space
    • Task
    • Item
    • Guide
  • Rob Space
    • Team permissions Database
  • Airpa Space
    • Team permissions Database
  • Managers Space
    • Team permissions Database
  • SA Space
    • Team permissions Database

Or perhaps a Global and a Rob to keep my personal separated from business? Now that I’ve though this through I’m not even sure it works anyway.

How does one set things up if one didn’t have that team permission functionality?

At any rate, thank you and Happy Thanksgiving to my gringo compadres and Happy Day to the rest of the world who doesn’t celebrate good old ‘merica’s wiping out an entire indigenous peoples while eating mashed potatoes and gravy. :-1: :face_vomiting: :crazy_face:

2

Here are a few comments, which may or may not go some way to answering your questions:

In general, you should typically only ever need one database per type of ‘thing’.
One db for Tasks
One db for Meetings
One db for Employees
etc.

However, this assumes that the entities in each of these databases are basically similar in nature, e.g. all Tasks have a Due date, an Owner, and a set of Assignees

If you find that there is a lot of variation in the characteristics of the entities, then this might indicate that you should make them into separate types of things, i.e. separate databases.
An example might be that the SW team have ‘tasks’ and the marketing team have ‘tasks’, but in reality the tasks are markedly different:
The marketing team need to link a Task to a Campaign, they need to have a Budget field, and they have Start and End dates.
Meanwhile, the developers need to link a Task to a Bug, connect a Task to a GitHub Issue, and link to a Release.
In such a situation, you would probably want two different dbs.

There is always the question of when two types of thing are the same and when they are different.
Say the development team have Meetings, and they want to record the Date of the meeting, the Attendees, and have a list of related Tasks. Meanwhile the marketers also want to record the Date, the Attendees, but don’t ever bother linking Tasks (lazy devils don’t have any tasks :wink: ) then a single db is probably appropriate, and the marketing team will just have to put up with seeing an empty Task field in every Meeting entity.

I note that you mention ‘Items’ which can be Agenda, Library, Meeting, etc.
I would wonder myself if this was really a single category of things, or whether it is actually multiple…?

Anyway, these are the rules of thumb for how to set up your structure.

After that, it is a case of figuring out who is allowed to do/see what.
Up until recently, it was not possible to grant access at a more granular level than database, so if you could see a single Task, you could see all Tasks.
However, the latest changes have improved on this, and more improvements are to come, so ultimately, decisions about access are secondary to those about structure.

With regards to ‘team’ permissions (aka groups) this is largely a convenience issue. For example, if you have colleagues Alice, Bob and Charles, you can grant them permissions as individuals however you see fit. But when you have 25 colleagues to deal with, you might get tired of granting permissions one at a time, which is when groups/teams come in handy.
And with groups, you can assign users to be members of multiple groups and the permission combinations will be calculated accordingly.

There’s lots of useful info on permissions here:
https://the.fibery.io/@public/User_Guide/Guide/Sharing-Permissions-46
https://the.fibery.io/@public/User_Guide/Guide/Groups-47

For your use case, some of the upcoming features are likely to be rather beneficial.
image

1 Like
3

Chris, thank you. Super helpful reply and thanks for your patience. Keep in mind, I go through the forums, I search, but my brain doesn’t grasp things like it once did. And that you explain things like you are I AM a 5-year old is super helpful to me. The chief reason I came to Fibery was for ME - and as team members start migrating and using more they will have an inherent understanding of things and so it should not be so hard.

Okay, so your first explanation clears up a lot of things.

  • Task
  • Item
  • Guide

They function exactly the same - Task has the same columns in all spaces, Item has the same columns in all spaces, Guide has the same columns in all spaces. Ultimately, the brain challenges mean I’m focusing a ton on ease-of-use for me, which is all-encompassing: searching for things, organizing things, collaborating with different people in different departments on things, and communicating - and it’s very hard for me to do this.

Let’s say I were to have only one Task database, one Item database, and only one Guide database, and the only difference is whether they are (1) for me and my managers, (2) me and one team, (3) me and the company, or (4) just me. Is there a better way to do it than that 4 spaces x 3 databases? Because I don’t understand how. Or is my 4 x 3 the right way considering the product will evolve (as I’ve been watching before my very eyes).

Thank you.

4

The best solution is a single Task db, and then each Task in that database will be accessible to different people according to the permissions you (or any Admin) grant.

By the looks of it, you are Admin, so you will always be able to see/edit all Tasks. So far, so good.

At the moment, your permissions requirements could be solved as follows:
For Tasks that are of type (1) to be shared with managers, you would manually share each Task of this type to the people who you consider to be ‘managers’ (with whatever level is suitable - Owner, Editor, Commenter, Viewer).
For Tasks that are of type (2) to be shared with a specific team, you would manually share each Task of this type to the people who you consider to be members of that team (again with whatever level works best).
For Tasks that are of type (3) to be shared with everyone in the company, you would manually share each Task of this type to every user (ditto).
For Tasks that are of type (4) you don’t need to do anything.

Remember, the Tasks themselves all live in the same database.

Unfortunately, as you can see, this could be laborious.

There are however some things that might make life easier though.
If, for example, you create a database of Teams (with say Development, Marketing, Finance as the entities in that team) and you have a relation that links Tasks to a Team, you can bulk grant access to multiple Tasks by utilising the ‘extend’ capability for entity sharing.
image
That is to say, you actually grant access to the Development team entity for the relevant people, and you ‘extend’ the access. This implies that they get to see/edit the Development team, but also any Tasks linked to that team.

However, this means you can grant for a set of Tasks (instead of one at a time) but it still requires configuring it for each user, one-at-a-time :frowning:
Shortly, we will roll out changes that will make it possible to simplify even further, so that any user who is a member of a given group can be granted access.
And as we make more progress, sharing will become even more flexible, whereby access can depend not only on membership of a group, inheritance via extending, but also upon whether or not you are currently assigned to an entity, etc.

But I won’t go into more details just yet :wink:

2 Likes
5

Thus our never-ending requests for some form of polymorphism :grinning:

1 Like
6

Did you base it on the existing, open source one? Either way, can you share it? :grin: