6.3. Versioning, approvals and audit logs
In order to fulfil the needs of the different parties, guarantee the data quality and accountability of each actor, three different mechanism are put in place:
| Mechanism | Purpose | Concerned data |
|---|---|---|
| Audit logs |
The purpose of audit logs is to keep track of who did what on the system. The audit logs contain the exact actions taken on the system and link them to the user / organisation that triggered the action.
The purpose is not to version data, but to keep track of changes and keep the users of the system accountable for their actions |
|
| Versioning |
The purpose of the versioning is to:
|
|
| Approvals |
Approval processes are put in place to guarantee data quality and to avoid unintentional destructive modifications. |
|
Versioning of physical links
|
In the figure above each row of data represents on Physical Link data entry in the database. The background colors of the rows represent:
In this example, There are free approved Physical Links, two that indicate that Fiber and Coax are present between two units and one that indicates that ETH was removed. |
Description
Versioning of physical links between two equipments or an equipment and a unit in multi-dwelling units is a crucial part of the RNVC. In order to support the approval process, each version of a connection needs to have a flag “validated” that can be “true” or “false” to indicate if that specific version has been validated. Furthermore we also need a flag to explicitly indicate if a specific link type has been decommissioned.
When an Editor wants to send an update for a vertical cabling connection between an “Equipment 1” and an “Equipment / Unit 2”, the Editor creates a new connection with and POST it using the “physical links” endpoint. This POST contains following information:
- Source equipment
- Destination equipment or destination unit
- Link Type
- If all physical links of that specific link type were removed, a flag “deleted = true”
When receiving an update request, the system adds following information to it:
- timestamp of creation
- the editor that produced the data
- organisation to which the connection belongs is set to the Editor’s organisation
- version
- flag “validated = false”
The organisation approver always get the latest entry for a given connection that is not yet validated to validate. Once the validator has validated the entry following information is stored:
- flag “validated = true” or “rejected = true” depending on decision
- validation timestamp
- the approver
When retrieving data, the default version of the physical link returned are the latest validated once. The users can explicitly request the latest versions if needed or any other historical version.
Processes
7.5. Send update vertical cabling request process
7.6. Approve update vertical cabling request
Data deletion requests
The NRVC will contain some information that is very static by nature:
- addresses
- sites
- blocks
- units
- equipments
Due to the static nature of this data and to the fact that a history of the changes performed to this data is not relevant to the project, it has been decided not to keep any historical data on this data. Instead of versioning, audit logs will be used to keep track of who did what to the data.
One important principle is that once created these objects cannot and will not be deleted.
Instead if deleting the data a process is in place to mark data as deleted. This process involves an Editor marking the data as “to be deleted” and a Approver that will need to validate the deletion request. Furthermore Administrators and Organisation Administrators will have the power to recover deleted datasets.
Processes
7.7. Approve delete site request
7.8. Approve delete block request
No comments to display
No comments to display