Existing method: cancelComposition

Implemented changes:

…

Processing

After all validations:

1. For conclusions that have the relatesTo.code=REPLACES attribute set, a verification of the MC record to which the relatesTo link is reffered

   1. if the MC referred to by the current MC is not found — the task completes its execution with the code CANT_CANCEL_NOT_FOUND (1137)

   2. if the MC referred to by the current MC does not have the AMENDED status - the task completes its execution with the code CANT_CANCEL_NONAMENDED_COMPOSITION (1136). In an ideal situation, this code should never occur

   3. if the checks are passed, the MC to which the link is set changes its status from AMENDED to FINAL.

2. The body of the cancellation request signed by QES is stored in the Ceph object storage.

3. The MС status is set to ENTERED_IN_ERROR.

4. If the authorization method is specified in extension.authorize_with, check:

   1. Authentication method exists in person_authentication_methods table in MPI DB (with is_active=true), is active (ended_at > now() or null)

   2. For authentication method with type = THIRD_PERSON check that person from value is an approved confidant for a person from composition – exists active and approved confidant person relationship between person from composition and confidant_person_id from authentication method value (using following logic: https://e-health-ua.atlassian.net/wiki/spaces/CSI/pages/17667883028 with person_id = section.focus.value from composition and confidant_person_id = value from auth method - expected :ok, :approved response)

      1. in case any validation failed - do not send SMS to person

      2. else - send SMS to authorization method

5. The task of canceling the MC in the ERLN is planned.