Implement a more sophisticated generic handler restore implementation

[davidradl]

Currently there is an OMRS restore implementation that restores an entity. There is no generic handler methods to help with restore. Subject Area OMAs is the only OMAS using restore at present - it is moving to use a simple restore implementation.

Issues with the existing code:

• a simplistic implementation of restore does not account for anchors.

Proposal:
As much as possible the generic handlers should undo what ever the generic handler delete does. This was discussed in a the community on a call on the 6th of July.

Entities

• if the restore is for an anchored entity, only restore if the anchor is active - otherwise error.
• if the restore is for a anchor entity - for example if it has comments. Then the anchored content should be restored.
• For directly connected deleted, non anchored relationships to active entities. For example if there was a has-a relationship to a parent glossary term, these relationships should be restored
• restore should update the latestChange in the anchor like update does.

Relationships
Only restore if both ends are active. the current logic does not check for this.

We need to consider what happens if we delete the TermAnchor relationship (and all other anchored relationships). This results in the Glossary Term entity being deleted.

• If we restore the GlossaryTerm then the logic could look to restore the TermAnchor if there is one rather than create a new TermAnchor. In this was the effectivity dates would be honoured
• if we restore the TermAnchor relationship, it should restore the anchored bean that was deleted for symmetry.

Scope considerations
There maybe situations where an anchored entity is deleted, then at some later time the anchor entity is deleted; in this case we would not want to restore the already deleted anchored entity. The should is that for the deletion of an anchored entity, we should do the cascaded delete, in addition to checking the state to deleted, we include a restoreScope property in everything that has been deleted (entities and relationships). The value of this property will be a new guid created at delete time.
Care needs to be taken when deleting anchored content that is itself an anchor, For sider these examples

• deleting a Glossary (an anchor) that has glossaryterm anchored entities, the glossary term could be an anchor for a comment. We would expect that the comment would be deleted. We would expect the restore to reverse this, restoring the comment.
• delete an asset with a schema, I believe deleting of the asset would not delete the schema. The restore logic needs to keep this behaviour.

**Classifications **
It seem reasonable that is an entity has classifications (which may involve security), these are restored with the entity.
Classification logic changes will be handled in #5466

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.

[Inventoroz]

I propose to apply the principle of method overloading, when the general logic is written on the lowest layer and each subsequent layer complements / expands the recovery process. In other words, each layer does what it can do at its own level, and all the logic is not done somewhere from above.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 20 days if no further activity occurs. Thank you for your contributions.