Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

The idea is to allow to configure a project so that the user certification check is bypassed once vetted by ACT. The users are not considered certified, but we still want to allow them to contribute and we as DCC should validate the uploaded data before making it public.

Since the users are not certified we need to make sure that the data created is not shared publicly while a project is configured as such. The certification requirement for a project can be enabled or disabled only by ACT.

API Design

The changes to the API would involve the following additions:

  1. A new ProjectSetting to allow enabling/disabling the configuration. Can be of type certification with a boolean property certificationRequired. The following restrictions apply:

    1. Can be applied to Projects only (e.g. not allowed at the folder level)

    2. Can be created/updated only by ACT

    3. TBD: Cannot be enabled/disabled on a project that is shared with the PUBLIC_GROUP (This check is only performed on the project entity)

  2. Add a property certificationRequired to the response of the GET /entity/{id}/permissions that indicates if certification is required for editing and/or create (add child). The current properties (e.g. isCertifiedUser, canEdit, canCertifiedUserEdit etc) would need to be computed accordingly. Note that if the entity is public and the user is not certified the canEdit, canAddChild will be false despite user permissions and the certificationRequired property will be set to true (despite the project setting) since the user would need to be certified in this case (See constraints below).

Additional constraintsAdditional constraints:

No additional constraint is applied aside from:

  1. Only certified users are allowed to add/remove ACLs despite the change permission accessWhen the certification requirement is disabled an entity cannot be created if the benefactor is public. To avoid scalability issues (if implementing 3.) when disabling the certification on an existing project we check only at the project level if it's shared with the public (since we cannot check every entity within the project) and we defer the check when entities are created/edited.Note that this means that we could have projects where we can disable the certification requirement that have public folders/entities, those are assumed to contain/be entities that were either created by certified users or vetted by the ACT (e.g. removing the configuration is an operation that is performed by ACT and the responsibility falls on the project creator or whoever was signed off by ACT).

  2. TBD: When the certification requirement is disabled for a project no ACL to the PUBLIC_GROUP can be added to any entity within the project, additionally:

    1. When a local ACL is removed the resulting inherited permissions should not include ACL with the PUBLIC_GROUP

    2. This applies also when we force the inheritance of the ACL from a specific entity, the permissions from the resulting benefactor should not include any ACL with the PUBLIC_GROUP

  3. The rest would work the same, if a user that is not certified creates an entity in a project for which the certification is not required the certification check is bypassed and the standard ACL/AR checks are performed (the user still needs to be allowed to create/edit).

Note: when an entity is moved under a different entity (or restored from the trashcan) the same access checks apply according to the target container (e.g. there is not special treatment as the target holds the access requirements/certification requirements etc). Since this can potentially break the “private” project lockdown and depending if we implement 3., we should consider disallowing moving entities outside of those projects as long as the configuration is enabled (both from a move or a trashcan restore).

Auditing:

We need to keep track of the entities that have been created without certification: we already store the user certification date so we can infer this information from the data warehouse already. If might be useful to add a new property to the node snapshot that indicates if the project was configured this way when the snapshot was taken (E.g. CERTIFICATION_REQUIRED, default true for past entities).

...