Private database - my space

Hey,

This is a feature I’m missing, coming from Notion.

I’d like to create a database with content only visible to myself, to handle my personal task management (TODO list / GFD style).

Unfortunately, at the moment I can only create a database in a space, which means all workspace admins have access to it.

Only workaround I’ve found is to use my personal fibery/google account to hold this, but this a pain to use because fibery does not support 2 connections in the same browser.

This is not suitable ?

I think what is meant is the ability to have your own database in the “My Space”-space. At least that’s how I interpret it.

Ah I see. Got it. Agree it would be interesting.

I think what is meant is the ability to have your own database in the “My Space”-space. At least that’s how I interpret it.

exactly ! sorry if this was not clear in the initial post

Out of interest, do you envisage that a database in My Space would be able to connect to other (non-private) databases?

Yes, that would be helpful. Ideally on the other end (on the shared database) the values would be hidden for other users. Is this how the relations between databases in different spaces would behave ?

Eg

  • only user1 has access to space S1 with database db1
  • space S2 with database db2 (public), db2.f1 links to db1.f2

user2 with no access to S1 would not get information about db1 from db2, right ?

I see 2 UC for this feature request

  • admin user working in a private sandbox to test fibery features or a new setup
  • any user creating his own private process (todo list, personal objectives …), linking the data to shared entities

Thanks for the details.
For the first use case, I would see this as solvable with the current setup (I’m assuming that there’s no reason why all admins shouldn’t be able to see sandbox experimentation).
For the second use case, I see the issue.
I don’t know whether we will tackle it any time soon though - we’re primarily focussing on features that help with collaborative work and knowledge management, so allowing users to create databases that only one person can access doesn’t seem to be in alignment with that.

However, I do wonder if the new permissions model we are planning might accommodate something useful, e.g. if there was an access level that allowed creator-level capabilities for database configuration but didn’t allow any access to database content.
It would be similar to the use case where an admin needs to be able to design a database for sensitive financial/HR info without being able to actually see data in the database…
:thinking:

2 Likes

This totally makes sense, thanks for the reply !

Sorry for the thread ressurection, wanted to add my vote and some context as a project manager. I’m not a paying user yet but I’m very excited to implement Fibery in companies that need lightweight PM software, something I do quite fairly often with apps like Jira, Clickup and Smartsheet.

Part of what’s attracted me to Fibery has been the problem that most project management tools seem to think that a team can manage itself with just a kanban board. Yet there are always actions coming up that don’t live on the backlog that have to be tracked in a different tool like a RAID log (and inevitably forgotten about by the owners). And one of the reasons that people don’t comment on kanban cards is because they never have the board open, there’s just too much friction to go from note.txt to Jira.

Fibery appealed to me because if each context (team, chapter, guild, train, etc) has its own database storing actions/risks. I can create actions directly out of meeting notes docs which is amazing, then use “My Space” to create a personal view of everything assigned to me. Now the friction is gone and all my work is listed in one place.

However if I have a private action like “Update line manager with WFH dates for my vasectomy” or “Fire Dave before his RSUs vest next quarter” there’s no way to include these in my personal view.

I recognise that managing your personal workload isn’t strictly a “collaboration” feature, but every collaborator has to do it, so seems like a reasonable use case rather than having people leave Fibery. Some roles like HR have to work quite privately but still have incoming tasks from shared contexts.

Or maybe I’m missing something obvious about how we should be structuring work management in Fibery in which case I’d love hear examples of how it should work.

Thanks for reading this far :slight_smile:

2 Likes

Would like to add strong support for this in order to make other features offered work better.

Currently all integrations (Google Calendar, Email, Slack) create databases that are accessible by our workspace admins.

Our users need to be able to create databases that are only accessible by them so that they can connect their tools and retain their privacy.

I can imagine that. But the ‘problem’ of Fibery is that it’s so damn good that you ideally want to put everything in it. And because there is no good way to combine two workspaces (a ‘team workspace’ and ‘private workspace’) it would be really nice if you can put private stuff in the workspace as well.

Think of private tasks, private notes etc.

Ideally the owner of the company is not the only admin since admin work can be delegated easily to others.

Currently admins always have access to everything. Would be great if you can somehow prevent admins from seeing certain data. Or some super admin setting who can determine which admins have access to which spaces/databases.

1 Like

We are trying to move towards more flexible permissions, so that Admin level is not required for the vast majority of users, and also allowing the possibility for an Admin to turn off their superpowers (so that they don’t see everything in everyday use).
However, fundamentally, it is difficult to imagine a design of a permissions model that does not grant at least one user complete access/control to the whole workspace. Otherwise, it’s possible to foresee situations where a company could end up getting locked out of its own workspace.

Also, if ‘private’ databases are allowed, it effectively grows the number of workspaces from one per company to one per user (where each user is the admin of their own My space) and that is a massive scaling issue.

1 Like

I think you already solve a lot if you can determine per space/database which members have admin rights/which persons can see each and every entity.

Currently admins always have access to everything. Although they may not need access to HR/Finance etc.

I think that already solves a lot.

That’s also helpful. But it does not solve the following.

Let’s say you have

  • 1 task database
  • 1 note database
  • Some tasks/notes in that database are private for a user

It would be really helpful if you can set permissions like “only if you created the entity or if you are assigned to the entity (or belongs to a user group, you will have xxx access”

The super user/owner of the workspace/the one that pays the bills always have access to everything in the workspace. That’s not a problem I think. They can then determine which users can/can’t have access to sensitive data.

I understand your doubts but I don’t know if that will be the actual situation.

Most of the use cases are not about ‘a fully private database’. More like ‘certain entities/databases can’t be seen by admins’.

We’ve worked with ClickUp and Notion. There we’ve had private databases/areas. But it’s not that the freelancers in my team want to put all their personal stuff in the workspace of my company.

And if you are an employee, I also doubt that you want to put your private life in the workspace of your boss.

It’s more applicable for business partners/co founders/C level. They have private tasks/notes/databases (HR/Finance etc.) that can’t be seen by every admin.

1 Like

Just an idea: when you share a calendar, you’ll have the option per appointment to set the appointment to ‘private’.

I think something like that would be awesome.

So if you create an entity yourself, you want to be able to mark that entity as ‘private’. Then you don’t need a whole private database; some entities are just private for you.

And if you combine it with this one, I think you’ve solved most use cases.

This is a valid use case that we do plan to solve as part of the permission features released in the near future

3 Likes

Just want to add another vote for this issue. My boss wants private DB, though he says just plain table is negotiable at the moment.

2 Likes

I understand your position but I’m not sure that the number of workspaces will significantly grows. Currently, if I have things that I prefer to keep private but it’s ok if workspace admins can see this things, I create my databases on Spaces and manage the things related to my role there. So it don’t avoid the problem, it just moves it.

There is users that are admins/creators but many users are just members who uses what it is created by others. Perhaps one manner to solve the problem is to limit the number of databases that can be created on My Space. Sometimes, we just need one database so we can keep some stuff private. What about giving the possibility to create one or two databases per user in My Space ?

Another solution that is related to a feature request is to be able to set Spaces private. If a user asks the admins to have a private space, admins can discuss with the user the needs and determine if a private space is really the best solution. If the tool does not provide the possibility to have things private, it will be complicate to attract some departments. HR is a good example. Perhaps they want to conduct interviews with Fibery but they won’t because the candidate information can been seen by Workspace admins. So they will not use Fibery.

I love Fibery, I understand the philosophy, the transparency, etc… I pushed my team and other departments to use it. But I will not be able to push some of other departments if they cannot have some privacy.

I think there is a slight distinction between ‘private databases’ (accessible to only one user) and ‘sensitive info databases’ (accessible by one or more users with specific roles). I think your needs fall under the latter.

Putting that aside, the fundamental requirement that they share is that only a subset of users should be able to access them, and that subset may be users who are all ‘non-admins’.

Unfortunately, Fibery permissions are currently based on a set of axioms, including the following:

  • all workspaces must have at least one admin
  • admins are permitted to do anything within the workspace (= cannot be inhibited from doing something)

Partly, the reason for these is that it should not be possible for users to configure a workspace in such a way as to irreversibly lock themselves out of any of the data in the workspace.

For your use case, I would suggest that you can get by with having mostly non-admin members, some of whom have Creator level permissions in specific spaces but not in others.
If necessary, you can have a single admin account, that is not a ‘real’ user, and have internal policies about which people in the company are allowed to log in with the admin credentials, and what actions they can take/data they should be allowed to view.

1 Like

Thanks for your message.

Yes I understand that as per design, Workspace admins should always have access to all spaces. But what about trying to solve this in another manner ?

If a Space is set as private, Workspace admins always have access but they should fill a form or something. The idea is that if a Workspace admin does not have a role in the private space, he will need to pass by a new layer of verification before he can access the Space. If the Workspace admin have a role in this Space, he don’t need to pass by this new layer.

This new layer can be a simple form where you need to explain the reason for entering this private Space. When the “unauthorised” Workspace admin enter into the private Space, admins of this Space are notified.

On my understanding, the structure of permissions will not be changed. To get this work, you need :

  • a switch to set a Space private
  • a new verification layer (a prompt that ask the Workspace admin the reason of entering into the Space)
  • a rule that notify the admins of the private Space when a Workspace admin that don’t have a role in the private Space enter into the Space

I don’t know if it’s something feasible but it’s the idea.