Amendments cannot be submitted in some cases [6]

[dleard]

A bug is blocking the submission of a few amendments. The issue is caused by a combination of things: A trigger that protects archived table records (archived_records_are_immutable) is getting fired and throwing an error when submitting an amendment if a general revision has been applied after the amendment was created where the general revision has deleted an attachment (Note: I’ve only seen this with attachments, but the issue could be broader). This might also get triggered if a general revision removed a contact or manager.

Probability (how likely the bug is to happen, scored from 1-5): 2

Effect (how bad the bug is when it does happen, scored from 1-5): 4

Steps to reproduce the behaviour:

• Create a project with a couple attachments & submit it (should only need the project overview & attachments stuff)
• Create an amendment & leave it in pending (don’t apply it)
• Create a general revision, delete an attachment and apply it
• Return to the amendment & attempt to apply it.
• An error will be thrown when attempting to apply the amendment

[mikevespi]

Per discussion on Oct 25, we need to implement what we had previously been referring to as rebasing the project revisions when one is commit on a project with another open revision. If there is an open amendment, and a general revision is committed on that project, the changes need to be made in the open amendment as well. In the case of attachments and mangers, this means deleting the records entirely as they never would have existed if the amendment had been opened from the latest committed version of the project.

[mikevespi]

This work has been merged to develop but is staying in the review in progress column since we're going to have the CIF team test it out in Test before we deploy it to prod. cc @patriciarussellCAS / @pbastia

[mikevespi]

Scratch the above comment, moving this along and writing up a new card for the follow up testing with CIF staff.