...
- In all cases, the change request must be formally documented and tracked as an issue in Jira to create an audit-able trail of the work to be done. A description This must include a description of who is performing the data change and the specifics of what the change entails. This should be detailed enough so that someone looking at the data after the fact can determine how the data was changed.
- For some projects, the authoritative change request must be recorded in a partner's record system, signed by approval authorities, and link to the Jira issue.
- An administrative user may temporarily assign write permission to the user who will oversee the change. This is to ensure that no administrative user has unilateral power over user participating in the project can modify participant data unilaterally, and that we have an audit-able record of following this procedure.
- Perform the change:
- The Investigator or delegate must issue an API call, such as through the web client, to create a snapshot of the table version. The snapshot becomes an immutable record of the state of the table before the change.
- A label reflecting the nature of the change and referencing the explanatory Jira ticket should added included in the version snapshot.
- The version comment should contain a link to a sign change request if appropriate for the project.
- The appropriate project staff may apply the change with appropriate supervision as defined by the project requirements.
- The Investigator or delegate must issue an API call, such as through the web client, to create a snapshot of the table version. The snapshot becomes an immutable record of the state of the table before the change.
- The Investigator, and no other, project investigator or other approval authority should review and validate prior and changed versions of the data . Once approved, they must create an annotation on the table entity with a reference to the prior version explaining the reason for the change. This annotation serves as a record of the transaction, including both prior and changed values of all data, and signature of the investigator approving the change. and close the Jira issue that documents the change request.
- The administrative user must revert permissions in order to prevent further modification of the table.
Managing Synapse Permissions
Permission control on the Synapse entities should be limited to those with a need to access and modify objects for the duration which requires access. Write access . to tables that require this level of control should be limited by Synapse Team. Tables generated through the Bridge export process require BridgeAdmin Team membership, for example, as described in the Bridge Ad Hoc Data Change Process.
Related articles
Bridge Data Change Request Process
...