7. Processes 7.1. User management processes User creation process f an organisation requires a new user, two possible scenarios arise, either the organisation already exists in the system, or a new organisation needs to be created. New organisation For new organisations the request needs to be send to the Application Administrator (MyConnectivity) that is the only role that can create new organisations. The requests is then analysed and approved / rejected by the Application Administrator. If the organisation is approved, it gets inserted in the system and then the application administrators can treat the API user request as any other user request. New API user New users can be requested to the Application Administrator or, if the organisation already exists in the system and the organisation has an Organisation Administrator, to an Organisation Administrator. The Administrator then analyses the request and can approve or reject it. If the user is approved, it is inserted in the System and a Administrator confirms its creation to the requestor. The way the user will receive his credentials will depend on the Authentication Provider used and will not be described here. User deletion process Organisation Administrators as well as Application Administrators can mark users as deleted. Marking the users as deleted will make it impossible for that user to login. Furthermore the system will not allow any creation of new links to that user, effectively it is as if the user would not exist anymore. The user itself does not get deleted and any potential private data will be deleted. The goal of keeping this data is to keep a trace of which user object performed which operations in the system and to be able to identify to which organisation it belonged. The system will automatically mark users as inactive if they are not used for a period of time defined by MyConnectivity. Inactive users will be deleted after a given time, if they are not re-activated. Inactive user deletion process Users can be marked as inactive, if they will not be using the system for a while (e.g. suspended account or temporary deactivation). Inactive users cannot login an cannot perform any action on the system. If an inactive user is not re-activated within a reasonable time interval X, the user will be automatically deleted. The exact value of X will be a parameter chosen by MyConnectivity, that can be adapted as needed. Organisation deletion process Organisation deletion follows the same principles as the user deletion process, except that the organisations can only be marked as deleted by Application Administrators. When an organisation is marked as deleted, all users linked to the organisation are also marked as deleted. Organisations must be explicitly deleted and are not automatically deleted when no users are assigned to it, this is important as an organisation can also be used in contexts others then document production (e.g. as a owners of equipments or contacts for a building) 7.2. Create missing address process Name Create Missing Address Request Purpose Allow Editors to add missing addresses to the system, so that they are not blocked during the data ingestion processes. Linked user stories 4.28. Editor - Create temporary address APIs used POST /addresses Scope This process only handles the creation of the address in a temporary state. This state will allow the Editors to enter data into the vertical cabling database for that temporary address. The process of validating and approving the temporary addresses is out of the scope of this process. Roles Organisation Editor, System Input - address (mandatory) - site structure, including site → blocks → units (optional) Output - temporary address - the given site structure or the default one if not structure was provided Detailed Process description Main process Step Description Actor(s) Input(s) Output(s) Decision points 1 An Editor sends a “create address request”. Editor - Address (mandatory) - Site structure (optional) - 2 The system checks if the address already exists System - Address (mandatory) - Site structure (optional) - yes / no If the address does not exist: - the ingestion process continues (Step 3) If the address exists: - An error is returned (E.1. Address exists) 3 The system checks if their are high confidence matches (e.g. potential spelling mistakes in the street / locality) System - Address - list of high confidence matches (if any) If no high confidence matches: - the ingestion process continues (Step 4) If high confidence matches are found: - Matches are returned to the Editor for verification (secondary process: S.1. High confidence address verification) 4 The system creates the address in the database with a flag indicating that it is a temporary address that is not yet validated. System - Address (with flag validated=false) - Newly created address 5 The system checks if a site structure was sent with the “create address request”. System - Create address request - yes / no If a site structure is provided: - the provided structure is created. If no site structure is provided: - a default structure is created. 6.a The system creates the provided site structure System - Requested site structure - Newly created site structure 6.b The system creates the default site structure System - - Newly created default site structure 7 The system returns the created address and the site structure System - - Newly created address and site structure 8 The Editor gets the newly requested address Editor - - Newly created address and site structure Secondary Processes S.1. High confidence address verification Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns a list of high confidence address matches System - - list of high confidence matches 2 Editor verifies if the address is present in the list Editor - list of high confidence matches - yes / no If address not present: - the secondary process continues (S.1. Step 3) If address present: - the ingestion process is canceled (E.2. Address exists) 3 The Editor sends again a “create address request” but this time flags it as forced (force = true) Editor - Address (mandatory) - Site structure (optional) - 4 The system checks if the address already exists System - Address (mandatory) - Site structure (optional) - yes / no If the address does not exist: - the main process continues (Step 4) If the address exists: - An error is returned (E.1. Address exists) Error Processes E.1. Address exists (System error) Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that the address already exists System - Error: Address exists E.2. Address exists (Editor cancel) Step Description Actor(s) Input(s) Output(s) Decision points 1 Editor finds the address in the high confidence matches returned by the system. The process is canceled. Editor - - Additional Information Address matching processes Exact match (link to algorithm or process) High confidence match (link to algorithm or process) Default site structure If no site structure is sent with the “address creation request”, a default site structure will be created composed of a site, to which one block is linked. No units are created by default, as more information is needed to create the units (floor, identification). Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. [409 Already Exists] Address already exists If the  Editor attempts to add an address that already exists, an error is returned. [300 Similar exists] High confidence matches If the  Editor attempts to add an address for which the system detects high confidence matches and the force flag is set to false, the system return an error 300 and the list of high confidence matches. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.3. Create missing address for existing site or block process Name Create missing address for existing site or block process Purpose Allow Editors to add missing addresses for an existing site or block to the system, so that they are not blocked during the data ingestion processes. Linked user stories 4.29. Editor - Create an additional temporary address for an existing site 4.30. Editor - Create an additional temporary address for an existing block APIs used POST /sites//addresses POST /blocks//addresses Scope This process only handles the creation of the address in a temporary state and link it to an existing site or block. This state will allow the Editors to enter data into the vertical cabling database for that temporary address. The process of validating and approving the temporary addresses is out of the scope of this process. Roles Editor, System Input - site id or block id (mandatory) - address (mandatory) Output - temporary address linked to the given site or block - the site structure attached the address Detailed Process description Main process Step Description Actor(s) Input(s) Output(s) Decision points 1 An Editor sends a “create address request” for an existing site or block. Editor - Site id or Block id - Address (mandatory) - 2 The system checks if the address already exists System - Site id - Address (mandatory) - yes / no If the address does not exist: the ingestion process continues (Step 3) If the address exists: An error is returned (E.1. Address exists) 3 The system checks if their are high confidence matches (e.g. potential spelling mistakes in the street / locality) System - Address - list of high confidence matches (if any) If no high confidence matches: the ingestion process continues (Step 4) If high confidence matches are found: Matches are returned to the Editor for verification (secondary process: S.1. High confidence address verification) 4 The system creates the address in the database with a flag indicating that it is a temporary address that is not yet validated. System - Address (with flag validated=false) - Newly created address 5 The system links the address to the given site or block System - Create address request - Address linked to the given site or block 6 The system returns the created address and the site structure System - - Newly created address and site structure 7 The Editor gets the newly requested address Editor - - Newly created address and site structure Secondary Processes S.1. High confidence address verification Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns a list of high confidence address matches System - - list of high confidence matches 2 Editor verifies if the address is present in the list Editor - list of high confidence matches - yes / no If address not present: the secondary process continues (S.1. Step 3) If address present: the ingestion process is canceled (E.2. Address exists) 3 The Editor sends again a “create address request” but this time flags it as forced (force = true) Editor - Address (mandatory) - Site structure (optional) - 4 The system checks if the address already exists System - Address (mandatory) - Site structure (optional) - yes / no If the address does not exist: the main process continues (Step 4) If the address exists: An error is returned (E.1. Address exists) Error Processes E.1. Address exists (System error) Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that the address already exists including the site it is attached to. System - Error: Address exists E.2. Address exists (Editor cancel) Step Description Actor(s) Input(s) Output(s) Decision points 1 Editor finds the address in the high confidence matches returned by the system including the site it is attached to. The process is canceled. Editor - - Additional Information Address matching processes Exact match (link to algorithm or process) High confidence match (link to algorithm or process) Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. [409 Already Exists] Address already exists If the  Editor attempts to add an address that already exists, an error is returned. [300 Similar exists] High confidence matches If the  Editor attempts to add an address for which the system detects high confidence matches and the force flag is set to false, the system return an error 300 and the list of high confidence matches. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.4. Address ingestion via the ETL process The background colors of the above image are to be interpreted as: purple : the core application a.k.a. backend that will be built in the context of this project green : supporting systems that will be used in the context of this project blue : trusted parties red : external users of the system The ETL process that is responsible for ingesting data from one or multiple trusted external Address Data Providers, is a key element of the RNCV. The ETL is responsible for: Ingest new addresses present on the Address Data Providers. Correct existing addresses Validate addresses ingested by the Data producers You will find below a high level representation of the ingestion process. The exact algorithms used by the ETL process are out of the scope of this project and therefore are abstracted as a black box in the process description The ETL algorithm is out of scope of this project ETL Process Name Address ingestion via the ETL process Purpose Ingest and validate address data to maintain the quality of the RNCV’s address database database to the highest standards Linked user stories 4.67. ETL - Retrieve addresses 4.68. ETL - Create and update addresses APIs used GET /etl/addresses POST /etl/addresses GET /etl/addresses/ PUT /etl/addresses/ PATCH /etl/addresses/ Scope This process handles the ingestion of addresses into the RNCV’s address database. It also handles the correction and validation of existing address data. This exact algorithm used by the ETL process is out of scope of this process. Roles ETL, System Input - Addresses from the Address Data Providers - Algorithm for the address data consolidation Output - Consolidated and up to date RNCV address database Detailed Process description Main process Step Description Actor(s) Input(s) Output(s) Decision points 1 The ETL process is periodically triggered ETL - - 2 The ETL process retrieves the data to synchronise from the Address Data Providers ETL - - addresses to synchronise 3 The ETL process process one address from the addresses to synchronise (could be done in parallel) ETL - addresses to synchronise - next address to synchronise 4 The ETL process extracts the address information to be stored in the RNCV address database ETL - address to synchronise - address information to be ingested 5 The ETL process searches for address matches in the RNCV address database ETL - address information to be ingested - address present in the RNCV address database if any 6 The ETL process checks if the address is present in the RNCV address database ETL - address present in the RNCV address database if any - yes / no If the address is present: Go to step 7 Else: Go to secondary process S.1. 7 Correct address information and set the flag “validated = true” ETL - RNCV address - Corrected RNCV address with flag “validated = true” 8 System applies the address update System - Corrected RNCV address with flag “validated = true” - Corrected RNCV address with flag “validated = true” 9 The ETL process checks if more addresses need to be synchronised ETL - addresses that still need to be synchronised - yes / no If there are still addresses to be synchronised: Go to step 3 Else: Go to step 10 10 The ETL process terminates successfully ETL - - Secondary Processes S.1. Address does not exist in the RNCV address database Step Description Actor(s) Input(s) Output(s) Decision points 1 The ETL process creates a new Address with the flag “validated = true” ETL - address information to be ingested - RNCV address to be created 2 The system creates the given address System - RNCV address to be created - RNCV address created  Go to Main process step 9 Additional Information Error processing during the ETL process If an error occurs during the ETL process (internal error, or error while using an external API), the system should log the error and process the next address. An error triggered during the processing of one address should never interrupting the ETL process for subsequent addresses, except if it is a system wide error, that would prevent all addresses from being processed. 7.5. Send update vertical cabling request process Name Send update vertical cabling request process Purpose Allow Editors to send an update request for a vertical cabling entry between two equipments Linked user stories 4.46. Editor - Send an update vertical cabling request APIs used POST /physical-links Scope This process only handles the creation of an update request for a vertical cabling entry between two existing equipments. The process of validating and approving the entry is handled in a dedicated process. Roles Organisation Editor, System Input - source equipment (mandatory) - destination equipment or destination unit (mandatory) - link type (mandatory) - additional metadata Output - confirmation that the update request has been transmitted Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 An Editor sends a “update vertical cabling request” for two existing equipments and a specific link type. Editor - source equipment (mandatory) - destination equipment or destination unit (mandatory) - cable type (mandatory) - additional metadata - 2 The System verifies that the two equipments exist System - yes / no If the equipments / unit exist: - the process continues (Step 3) If the equipments / unit do not exist: - An error is returned (E.1. Equipments not found) 3 The System verifies if the equipments / unit are geographically close enough to be connected System - equipments / unit addresses - yes / no If the equipments / unit are close enough: - the process continues (Step 4) If the equipments / unit are not close enough: - An error is returned (E.2. Equipments out of reach) 4 The System stores the connection in the database, adds the flag “approved = false” and the organisation of the Editor System - update vertical cabling request - connection stored with the flag “approved = false” and linked to the Editor’s organisation 5 The System triggers the approval process for the created connection System - stored connection - approval process is triggered 6 The Editor gets a confirmation that the update was successfully submitted Editor - submission confirmation Error Processes E.1. Equipments or unit not found Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that one or both equipment(s) or the unit do not exist System - Error: Equipments or unit do not exist E.2. Equipments or unit out of reach Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that the two equipments or uni are not geographically close enough to be connected. System - Error: Equipments or unit not in connection range Additional Information Deleting a cable type in between two equipments or unit Deleting a cable type between two instances follows the same process as above. In that case the user indicates in the update request that he wants to flag the connection as “deleted = true”. Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. This includes the case in which one or both equipment(s) do not exist. [409 Conflict] Equipments or unit out of reach If the Editor attempts to add connection between two equipments or unit that are geographically too far away to be connected, the system should return an error. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.6. Approve update vertical cabling request Name Approve update vertical cabling request Purpose Allow Approvers to validate an update request for a vertical cabling entry between two equipments Linked user stories 4.51. Approver - Approve or reject update vertical cabling request 4.56. Organisation Approver - Approve or reject update vertical cabling request for organisation APIs used PUT /physical-links//approve PUT /physical-links//reject PUT or PATCH /physical-links/ Scope This process only handles the validation of an already created update vertical cabling request The process of creating the entry is handled in a dedicated process. Roles System, Approver / Global Approver Input - id of the physical link update to validate - optionally the information to amend: - source equipment (mandatory) - destination equipment or unit (mandatory) - cable type (mandatory) - additional metadata Output - confirmation that the update request has been approved/rejected Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending. System - Outside trigger (e.g. Editor sent a new update request) - notification to the Global and organisation Approvers 2 The Approver verifies if the entry is valid and up to the expected quality standards Approver - Update physical link request - yes / no If the entry is valid: - Go to step 4 Else: - Go to secondary process S.1 3 The Approver verifies if pictures linked to the entry contain any private data Approver - Update physical link request - yes / no If the entry is valid: - Go to step 4 Else: - Go to secondary process S.1 4 The Approver approves the entry Approver - Update physical link request - update physical link request approval 5 The System verifies if the equipments/unit for which a physical link approval is sent exist System - update physical link request to approve - yes / no If the equipments/unit exist: - Go to step 6 Else: - Go to error E.1 6 The System verifies that the two equipments/unit are geographically close enough to be connected System - update physical link request to approve - yes / no If the equipments/unit are close enough: - Go to step 7 Else: - Go to error E.2 7 The System marks the update as approved and adds the approval date as well as the approver System - update physical link request to approve - Approved update request 8 The Approver gets notified that the approval was successfully done Approver - update request approval confirmation - Secondary Processes S.1. Submitted update physical link request needs adaptations Step Description Actor(s) Input(s) Output(s) Decision points 1 The Approver verifies if the update physical link request is partially valid and can be corrected Approver - update physical link request - yes / no If the request can be corrected by the approver: Go to step 2 Else: Go to secondary process S.2. 2 The Approver corrects the submitted update request Approver - update physical link request - corrected update physical link request Go back to main process Step 4 S.1. Submitted update is rejected Step Description Actor(s) Input(s) Output(s) Decision points 1 The Approver rejects the entry Approver - update physical link request - update physical link request rejection 2 The System marks the request as rejected and adds the date as well as the approver to the rejected update request System - update physical link request rejection - rejected update physical link request 3 The Approver gets a confirmation that the update request has been rejected Approver - update physical link request rejection confirmation Error Processes E.1. Equipments / unit not found Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that one or both equipment(s) / unit do not exist System - Error: equipments / unit do not exist E.2. Equipments / unit out of reach Step Description Actor(s) Input(s) Output(s) Decision points 1 System returns an error indicating that the two equipments / unit are not geographically close enough to be connected. System - Error: equipments / unit not in physical link range Additional Information Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. This includes the case in which one or both equipment(s) / unit do not exist. [409 Conflict] Equipments / unit out of reach If the  Editor attempts to add physical link between two equipments / unit that are geographically too far away to be connected, the system should return an error. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.7. Approve delete site request Name Approve delete site request Purpose Allow Approver to validate a site delete request Linked user stories 4.33. Editor - Delete a site 4.47. Approver - Approve deleted site request 4.52. Organisation Approver - Approve deleted site request for organisation APIs used PUT /sites//approve PUT /sites//reject PUT or PATCH /sites/ Scope This process only handles the validation of an already created site deletion request Roles System, Approver / Global Approver Input - id of the site that is marked for deletion - optionally the information to amend Output - confirmation that the update request has been approved/rejected Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending. System - Outside trigger (e.g. Editor sent a delete request) - notification to the Global and organisation Approvers 2 The Approver verifies if the site can be deleted Approver - Site deletion request - yes / no If the site can be deleted: Go to step 3 Else: Go to secondary process S.1 3 The System marks the site with the flag “is_deleted = true” and adds the information on the date of validation and the user that validated the request System - site with flag “marked_for_deletion = true” - site with flag “is_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date 4 The System sets all the objects linked to the site with the flag “is_deleted = true” (blocks, units, equipments). System - site - all linked objects marked with the flag “is_deleted = true” 5 The System creates validated update requests with the flag “is_deleted = true” for each active physical link that are connected to at least one unit of the site. System - site - new validated physical links with the flag “is_deleted = true” for each active physical link that links at least one unit of the deleted site 6 The Approver gets a confirmation that the approval has been applied Approver - confirmation of the validation Secondary Processes S.1. Delete site request rejected Step Description Actor(s) Input(s) Output(s) Decision points 1 The System removes the mark_for_deletion tag from the site entry System - site marked for deletion - site with the flag “mark_for_deletion = false” 2 The Approver gets a confirmation that the deletion rejection has been applied Approver - deletion request rejection confirmation Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. [404 Not Found] Site not found Error returned by the system if the site is not found. [409 Conflict] Site not marked for deletion Error returned by the system if the site being validated is not marked for deletion. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.8. Approve delete block request Name Approve delete block request Purpose Allow Approver to validate a block delete request Linked user stories 3.36. Editor - Delete a block 4.48. Approver - Approve deleted block request 4.53. Organisation Approver - Approve deleted block request for organisation APIs used PUT /blocks//approve PUT /blocks//reject PUT or PATCH /blocks/ Scope This process only handles the validation of an already created block deletion request Roles System, Approver / Global Approver Input - id of the block that is marked for deletion - optionally the information to amend Output - confirmation that the update request has been approved/rejected Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending. System - Outside trigger (e.g. Editor sent a delete request) - notification to the Global and organisation Approvers 2 The Approver verifies if the block can be deleted Approver - Block deletion request - yes / no If the site can be deleted: Go to step 3 Else: Go to secondary process S.1 3 The System verifies if the site has other blocks than the one being deleted System - Block to be deleted - yes / no If the site has more blocks: Go to step 4 Else: Go to E.1 4 The System marks the block with the flag “is_deleted = true” and adds the information on the date of validation and the user that validated the request System - block with flag “marked_for_deletion = true” - block with flag “is_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date 4 The System sets all the objects linked to the block with the flag “is_deleted = true” (units, equipments). System - block - all linked objects marked with the flag “is_deleted = true” 5 The System creates validated update requests with the flag “is_deleted = true” for each active physical link that are connected to at least one unit of the block. System - block - new validated physical links with the flag “is_deleted = true” for each active physical link that links at least one unit of the deleted block 6 The Approver gets a confirmation that the approval has been applied Approver - confirmation of the validation Secondary Processes S.1. Delete block request rejected Step Description Actor(s) Input(s) Output(s) Decision points 1 The System removes the mark_for_deletion tag from the block entry System - block marked for deletion - block with the flag “mark_for_deletion = false” 2 The Approver gets a confirmation that the deletion rejection has been applied Approver - deletion request rejection confirmation Error Processes E.1. Last block can’t be deleted Step Description Actor(s) Input(s) Output(s) Decision points 1 The Approver gets an error indicating that the last block of a site cannot be deleted System - Error: last block can’t be deleted Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. [404 Not Found] Block not found Error returned by the system if the block is not found. [409 Conflict] Block not marked for deletion Error returned by the system if the block being validated is not marked for deletion. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.9. Approve delete unit request Name Approve delete unit request Purpose Allow Approver to validate a unit delete request Linked user stories 4.39. Editor - Delete a unit 4.49. Approver - Approve deleted unit request 4.54. Organisation Approver - Approve deleted unit request for organisation APIs used PUT /units//approve PUT /units//reject PUT or PATCH /units/ Scope This process only handles the validation of an already created unit deletion request Roles System, Approver / Global Approver Input - id of the unit that is marked for deletion - optionally the information to amend Output - confirmation that the update request has been approved/rejected Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending. System - Outside trigger (e.g. Editor sent a delete request) - notification to the Global and organisation Approvers 2 The Approver verifies if the unit can be deleted Approver - unit deletion request - yes / no If the unit can be deleted: Go to step 3 Else: Go to secondary process S.1 3 The System marks the unit with the flag “is_deleted = true” and adds the information on the date of validation and the user that validated the request System - unit with flag “marked_for_deletion = true” - unit with flag “is_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date 4 The System sets all the quipments linked to the site with the flag “is_deleted = true”. System - unit - all linked equipments marked with the flag “is_deleted = true” 5 The System creates validated update requests with the flag “is_deleted = true” for each active physical link that are linked to the deleted equipments System - unit - new validated physical links with the flag “is_deleted = true” for each active physical link that is linked to the deleted equipments 6 The Approver gets a confirmation that the approval has been applied Approver - confirmation of the validation Secondary Processes S.1. Delete unit request rejected Step Description Actor(s) Input(s) Output(s) Decision points 1 The System removes the mark_for_deletion tag from the unit entry System - unit marked for deletion - unit with the flag “mark_for_deletion = false” 2 The Approver gets a confirmation that the deletion rejection has been applied Approver - deletion request rejection confirmation Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. [404 Not Found] Unit not found Error returned by the system if the unit is not found. [409 Conflict] Unit not marked for deletion Error returned by the system if the unit being validated is not marked for deletion. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. 7.10. Approve delete equipment request Name Approve delete equipment request Purpose Allow Approver to validate an equipment delete request Linked user stories 4.42. Editor - Delete an equipment 4.50. Approver - Approve deleted equipment request 4.55. Organisation Approver - Approve delete equipment request for organisation APIs used PUT /equipments//approve PUT /equipments//reject PUT or PATCH /equipments/ Scope This process only handles the validation of an already created equipment deletion request Roles System, Approver / Global Approver Input - id of the unit that is marked for deletion - optionally the information to amend Output - confirmation that the update request has been approved/rejected Detailed Process description Main Process Step Description Actor(s) Input(s) Output(s) Decision points 1 The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending. System - Outside trigger (e.g. Editor sent a delete request) - notification to the Global and organisation Approvers 2 The Approver verifies if the equipment can be deleted Approver - equipment deletion request - yes / no If the equipment can be deleted: Go to step 3 Else: Go to secondary process S.1 3 The System marks the equipment with the flag “is_deleted = true” and adds the information on the date of validation and the user that validated the request System - equipment with flag “marked_for_deletion = true” - equipment with flag “is_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date 4 The System creates validated update requests with the flag “is_deleted = true” for each active physical link that are linked to the deleted equipments System - unit - new validated physical links with the flag “is_deleted = true” for each active physical link that is linked to the deleted equipments 5 The Approver gets a confirmation that the approval has been applied Approver - confirmation of the validation Secondary Processes S.1. Delete equipment request rejected Step Description Actor(s) Input(s) Output(s) Decision points 1 The System removes the mark_for_deletion tag from the equipment entry System - equipment marked for deletion - equipment with the flag “mark_for_deletion = false” 2 The Approver gets a confirmation that the deletion rejection has been applied Approver - deletion request rejection confirmation Exceptions [400 Bad Request] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. [404 Not Found] Equipment not found Error returned by the system if the given equipment does not exist. [500 Internal Server Error] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation.