Access template allowing related entity creation

Get Help
1

Hey there,

As what could happen often happen, here comes the moment where we would like to use the access template to grant permission to user to create a related entity.
Here is an example of what we would like to do: we have 2 DBs (DB_1 & DB_2) with restricted access (as containing sensitive information), both being linked, and we do grant access to internal users to DB_1 entities when needed and once shared, we would like the user to be able to create a new entry in DB_2.
With current access template capabilities, we can provide additional rights to associated entities, but we can’t grant creation right (thus, requires someone else with needed rights to do it on behalf of the actual user).
As the associated doc is suggesting to ask you whenever we do face such a situation, here comes the request :wink:
May you have some kinda workaround to allow such access right workflow?

Keep the spirit, cheers :metal:

1 Like
2

Hey!

A few quick questions before I jump to suggesting any solutions:

  1. Should a user who created an Entity of DB_2 be able to unlink it from its DB_1 parent?
  2. If yes, should the user retain access to the DB_2 Entity once it’s unlinked from the parent?
  3. In general, do you currently have “orphan” DB_2 Entities not linked to any DB_1 in your workspace? If yes, is this desired?

If you can deanonymize DB_1 and DB_2 that would be nice as well but I’ll understand if you want to keep the names private :slight_smile:

3

Hey,
Thanks for the swift feedback, some answers below:

  1. this is actually not an expected requirement for our use case, on a standard way of working, unlinking both entities should not happen
  2. not expected does not mean it won’t happen, it’d actually make sense for the creator to keep the access to the created entity (but again, not a mandatory thing)
  3. nope, we should not (thus point 1/, but may happen depending on point 2/)

DB names are the following (and may indeed help to understand the use case and the need to keep some privacy):

  • DB_1 = Position
  • DB_2 = Interview

Long story short, we do manage our hiring process through Fibery as follows:

  • when needed/possible, we create a new Position (aka DB_1)
  • we create an Interview (aka DB_2) to track output of our discussion

Not sure if it does change that much the solution you may have in mind, Interview name is generated through a formula (from linked position and candidate - which is another DB from the same Space).

1 Like
4

Thanks, it makes perfect sense now!

We don’t have creation rights as a part of custom access templates since there is currently no way to enforce a parent for a newly created Entity. This means you cannot grant permission to create Interviews for a certain Position — only to create Interviews in general.

To unlock your use case we are missing two things:

  1. Specify who has the right to create Entities of a DB without granting read access to all the Entities of the DB.
  2. Mark a certain relation as required and do not allow “orphans”.

The first part is planned for this year as a part of Database access. The second part is more tricky but, I assume, less pressing.

The current workarounds would be to use publicly shared Forms to create Interviews or use Contributor Space access. Neither is great, I have to admit — that’s why we are working on DB permissions :construction_worker_man:.