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