Consider setting registration ID value for approved or rejected operations

[petrdvorak]

Description

Currently, we only use the registration_id database column (reflected in the registrationId API attribute when creating a new registration) to store the initial registration ID if the operation should only be approved using a specific registration. (The registration ID is used as a filtering mechanism.)

After approving or rejecting an operation, the registration ID of the registration that was actually used to approve/reject the operation is only stored in additionalData.activationId, which makes it difficult to work with the value (i.e., to find all operations that were approved/rejected via given registration).

We should evaluate if setting the value of actually used registration to registrationId attribute / registration_id column during the approve/reject operation would make some things easier.

However, we need to be careful when implementing this (!), as we want to retain the information "This operation was intended to only be approved via given registration" vs. "This operation was actually approved via given registration." I think this information can only be in the audit log, or it can be added to additionalData during approval/rejection. Alternatively, we could add an additional column for registration_id_finalized (or similar naming), but this seems more complicated.

Acceptance criteria

No response

Technical specification

No response

QA specification

No response