Is it possible to ignore permissions check on a @relation and have id accessible to the permissions-profile?

[KK7NZY]

I would like to be able to assign a permission profile to a single entity without having to define seperate profile to check entity relation.

For example I have something similar to following:

type Ctx @valueObject {
  id: ID
  pfl: ID
  gal: ID
}

type Portfolio @rootEntity(permissionProfile: "portfolio") {
  gallery: Gallery! @relation
  tags: [Tag] @relation
  ctx: Ctx @accessField
}

type Tag @rootEntity {
  name: String
  ctx: Ctx @accessField
}

type Gallery @rootEntity(permissionsProfile: "gallery") {
   potfolios: [Portfolio]
   ctx: Ctx @accessField
}

permissions-profile.yaml

permissionProfile:
  portfolio: 
    - access: read
      roles:
        - /^viewer-gal-(.*)$/
      restrictions:
        - field: ctx.gal
          valueTemplate: $1
   - access: read
     roles: 
       - /^viewer-pfl-(.*)$/
     restrictions:
       - field: ctx.pfl
         valueTemplate: $1

In this example if I where to try and access tags I would get message Not authorized to read Tag objects (in Portfolio.tags)", To allow user access to the referenced entity I would need to add another policy for tag.

Is it possible to avoid having to add additional policy for each reference. If a permission profile is not defined for the referenced entity can the check be skipped?

I was also curious about the id field. Should it be accessible to permissions-profile. At the moment I am unable to reference id even when I define it in the schema with id: ID @key @accessField. I have getting around many of these things by adding a context field and giving it a uuid field.

Any help would be appreciated. Look forward to hearing back.

Thank you,
John

[mfusser]

Hi,
It is not possible to ignore permissions check on a @relation.
It is not that the related objects do not have a permission profiles, but that they have the default permissions set which does not allow access.
Using the id field as an accessfield is also not possible.

The idea behind the accessField is a more that you use a field that groups objects together and not have a role or custom claim for each id:
https://github.com/AEB-labs/cruddl/blob/main/docs/modelling.md#data-dependent-permissions

Using it with a unique id field might have multiple problems:

• The list of roles or custom claims will get very large as it has to have all IDs of all accessible objects in the whole database
• The id must be added to the roles/custom-claims before the user can create the object (which is also a reason why the accessField would not work with the 'id' field). If i understand it correctly this will even mean that you would need to relog during the creation of a new object.