Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Current »

From PLFM-5908 - Getting issue details... STATUS .

Use cases discussed here: https://docs.google.com/document/d/1koH4PxTwhjA46rpxW01X8nME6FTnQ8PZ1Ew-DwB-2v4

Synapse requires any user that wants to create or edit data to be certified. The certification requires the user to pass a quiz to evaluate their familiarity with the Synapse data use procedure (See https://docs.synapse.org/articles/accounts_certified_users_and_profile_validation.html).

The use case is for a set of projects where Sage is acting as a Data Coordinating Center responsible for receiving and curating the data before making the curated data available to reduce the friction in contributing to the data.

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 constraints:

  1. Only certified users are allowed to add/remove ACLs despite the change permission access

  2. When 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).

  3. 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

  4. 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).

We might want to also add snapshot of the node configuration so to keep track when/who enabled/disabled the project configuration.

  • No labels