You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when deleting a topic, all data for the topic is deleted, and in addition "related topics" are also deleted (relationship credentials that are "owned" by other companies, but are for relationships to the company in question (the company being deleted)).
If the company is being permanently deleted from OrgBook (e.g. it was posted to OrgBook by mistake, or the source company was deleted in BC Reg) then this is correct behaviour.
If the company is to be re-processed, then these relationships will eventually be added back (the BC Reg issuer will automatically include "related companies" during processing). This seems to work most of the time, however there seems to be some edge case scenarios where the relationships don't get re-added. (In which case they show up on the next audit report as "mis-matched relationships").
It would be better to be able to specify two types of "delete topic" when deleting a topic:
Delete permanently - delete everything related to the company because it's not coming back (this is basically the current functionality)
Delete (but it will be reprocessed and re-added) - in this scenario the "related relationships won't need to be deleted.
Add a new option to the "delete topic" function to be able to specify one of these two options.
Also update the audit script to specify which of the two options to use (the audit script generates the commands required to fix any data issues), and update the "orgbook-configurations" to support the two options.
The text was updated successfully, but these errors were encountered:
Likely best to do that with an optional flag on the ./manage deleteTopic command. Something like ./manage deleteTopic --hard for permanent delete (scenario 1, current behavior), and make the default behavior be the delete for reprocessing behavior (scenario 2) since we'll be doing that more often.
That should also eliminate the need to specify which version of the command to use in the audit report, since the audit report would never be recommending a permanent (hard) delete. It's always going to be providing recommendations based on the assumption the records need to be reprocessed.
Currently when deleting a topic, all data for the topic is deleted, and in addition "related topics" are also deleted (relationship credentials that are "owned" by other companies, but are for relationships to the company in question (the company being deleted)).
If the company is being permanently deleted from OrgBook (e.g. it was posted to OrgBook by mistake, or the source company was deleted in BC Reg) then this is correct behaviour.
If the company is to be re-processed, then these relationships will eventually be added back (the BC Reg issuer will automatically include "related companies" during processing). This seems to work most of the time, however there seems to be some edge case scenarios where the relationships don't get re-added. (In which case they show up on the next audit report as "mis-matched relationships").
It would be better to be able to specify two types of "delete topic" when deleting a topic:
Add a new option to the "delete topic" function to be able to specify one of these two options.
Also update the audit script to specify which of the two options to use (the audit script generates the commands required to fix any data issues), and update the "orgbook-configurations" to support the two options.
The text was updated successfully, but these errors were encountered: