Do we really need the revert as a particular case?

[demilatof]

Since something has gone wrong during the testing session on revert, we have asked @janinamincer-daszkiewicz and I discovered that she changed again the revert scenarios after the workshop in Thessaloniki. Therefore, now I learnt that:

1. "If one of the partners approves the new version of the other partner, we have a new pair of mutually approved copies.."
2. "A new mutual approval means that we cannot revert to the previous mutual approval. We can (in the future) revert to this new mutual approval."

The need for the revert has been justified so: "DG EAC saying many times that what they want to avoid on a business level is to force approvals which are not needed."

But if we consider that now should be commonly accepted that the Approval API must return always the last approved IIA Hash, it's clear that the "revert" doesn't require any extra approval if considered as a normal amendment:

• If we approve the amendment, the partner cannot revert (and he has to approve our copy only if needed at a business level)
• If we don't approve the amendment, the partner can revert or not, and in both of the cases we keep on returning the last approved IIA-Hash, that is the same of his current version if he reverts (he can do whatever he likes better).

I show hereafter all the scenarios, in a short way (avoiding CNR, Get and so on step by step, that are needed anyway).

There isn't any step that requires a not needed approval on a business level just to satisfy the revert on a technical level if managed as a normal amendment. If there is, please show me where.

On my opinion, the revert should be excluded from the testing sessions, and the saved time used to test more critical function to avoid issues like the empty index or the wrong IIA hash in the approval response.

Scenarios when both of the partners start to modify before reverting (you can imagine it as a second amendment)

Scenarios when only one of the partners start to modify before reverting (you can imagine it as a second amendment)

Since the scenarios changed after the 4th march, 2024, what about all the testing session concluded before that date?

It's not a question if I like or not the scenarios, the point is if we can reduce the number of scenarios and particularly the number of useless tests, that carry only delays or errors in triggering something in the test environment.

[janinamincer-daszkiewicz]

I discovered that she changed again the revert scenarios after the workshop in Thessaloniki.

Just to clarify. During the workshop which took place on 19-20 February I discussed with UBologna the revert and we concluded that the scenario should be corrected. Nothing was secret, in particular testing sessions done at that time were aware. Scenario was corrected immediately after my return home and the new Excel file was posted with the date 2024-03-01, the 1st of March. The log inside the Excel file contains the list of changes, in particular I do not see any previous changes to revert.

Since the scenarios changed after the 4th march, 2024

I do not see on the list any test reports signed before the workshop in Thessaloniki.

It's not a question if I like or not the scenarios, the point is if we can reduce the number of scenarios

Scenarios are only for those who consider them useful. No obligation to be read by the others.

[demilatof]

I discovered that she changed again the revert scenarios after the workshop in Thessaloniki.

Just to clarify. During the workshop which took place on 19-20 February I discussed with UBologna the revert and we concluded that the scenario should be corrected. Nothing was secret, in particular testing sessions done at that time were aware. Scenario was corrected immediately after my return home and the new Excel file was posted with the date 2024-03-01, the 1st of March.

The Workshop is a useful and interesting moment, but what is said there is not an official communication that something, included in the specifications is changed or, better, is going to change. The commit history only says that delete and update were changed, not the revert.

The log inside the Excel file contains the list of changes, in particular I do not see any previous changes to revert.

You cannot expect that someone looks through almost 1710 cells (3x30x19) to see what of them has changed in a relevant way! In particular, e.g., scenario 11 in 2024-01-20-DeleteModifyScenarios.xlsx was a really revert scenario, whilst in the new release is still under the sheet "11. Modify, Unil.appr., Revert" but it's no more a revert, as you wrote in cell (A,17). The conclusion is that a partner could not revert if the new version he has proposed has been changed in the meantime. And this is a huge difference.

Moreover, thanks to the assumption that after a single approval we have a new mutual approval, become useless al scenarios with action after a single approval, because they become a similar scenario that simply restarts from the first row.

Less scenarios = less cells to look through do discover the relevant part changed

Since the scenarios changed after the 4th march, 2024 I do not see on the list any test reports signed before the workshop in Thessaloniki.

The new scenario file was published on 4th march, 2024; we can rely on it only from that date, before we cannot know how you could have formalized what you have concluded during the workshop. It would not have been the first time it had been decided something resulting in something different when written. In particular, before that date, we can see 13 session tests concluded.

It's not a question if I like or not the scenarios, the point is if we can reduce the number of scenarios Scenarios are only for those who consider them useful. No obligation to be read by the others.

Not so exactly. If you open the document with the tested cases concluded, you can see that 4 test cases concern the revert (10% of the total). And all of them are declared as concluded when the partner sends an IIA CNR, that's not the true, because instead Dashboard consider that they are concluded only when the reversion can arrive on their side, for some magic trigger, in the final state you have described in the scenario.

[janinamincer-daszkiewicz]

something, included in the specifications is changed or, better, is going to change.

The specification has not changed. Changes in the Excel with scenarios are logged in Excel.

[demilatof]

something, included in the specifications is changed or, better, is going to change.

The specification has not changed.

Could you kindly show me where the specifications define the following aspects, recalled by the scenarios:

• The definition of a revert
• Why we SHOULD do a revert
• What versions the HEIs should take a snapshot of (both of the copies or only their own one)
• How a revert is performed
• The definition of mutually approved for the first time and later on

Changes in the Excel with scenarios are logged in Excel.

But they don't explain why for the same action (B approves, row 14, scenario 11) we have now a different behavior and A cannot revert anymore (row 16 and 17). And the logs don't explain why sometimes it's used the expression "mutually approved" and sometimes not. Who decides that two versions are mutually approved? Who decides that the final state, with mutually approved versions, is not at row 14, but at row 28?