Approved status receiving HEI

[pleys]

The LA may only be considered as approved by the receiving HEI if it receives a GET response with the LA in so not when the receiving HEI sends an update approval because it is possible that the receiving HEI answers on a LA that is not the latest version from the sending HEI

[janinamincer-daszkiewicz]

You are right. Do you think that the specification should clearly mention this case?

[pleys]

I leave it up to you and colleagues with a more technical background to further discuss this: @georgschermann @mpuzar @kamil-olszewski-uw @vmmaSigmaaie @BavoNootaert ...

[georgschermann]

@pleys Why is this so?
The receiving hei can only send an update for which it has the get request with the same id and if the receiving hei approves this LA, than it has a valid version at the time of this id, and if this version was approved by the other 2 parties, than the receiving hei has a valid approved version of the LA, no matter if there is a more recent version.

Even when the sending hei rejects the approve-update request with a concurrent modification error, I would still conisder this version at the receiving hei as valid and approved. I would find it problematic if the sending hei could "revoke" their approval by issuing a new version of an approved LA and rejecting the approval of the receiving hei.

We will handle the approved-by information on the LA like signatures, so if one has a version with all three approvals, it is an approved version, or am I missing something?

@janinamincer-daszkiewicz
the documentation already is very clear on this:
The client (the receiving HEI) is REQUIRED to expect these HTTP 409 (Conflict) responses, and deal with them "appropriately". Usually this means that you need to fetch the fresh data from the server and ask your user to repeat his action once again.

[LDeprez]

Given the following scenario:

1. There is an initial learning agreement (LA), signed by 3 parties (so there is a before mobility and a latest approved version).
2. Sending hei modifies the LA (latest proposal id X).
3. Receiving hei does a GET request, does not agree and sends an UPDATE request with update-components-studied-v1 for latest proposal id X
4. Sending hei modifies the LA (latest proposal id Y)
5. Receiving hei sends an UPDATE request with approve-components-studied-proposal-v1 for latest proposal id X

=> I would suggest the following:

• Receiving hei does a Get request to check if his approval has been processed. That's why the GET response can contain up to 3 approval elements in the ListOf_ComponentsStudied
• Sending hei ignores the last update request approval in the above scenario and provides textual feedback in the update response.

If the sending hei should process the lateste update request, it should mark a depreciated version of the LA as approved and add this mutual agreement in the subsequent Get responses (latest approval).
This adds complexity without a morevalue as endpoints would be forced to store all versions that were not signed by the receiving HEI, to be able to listen to any update approvals for them.

In the following scenario, it is even more complex:

1. There is an initial learning agreement (LA), signed by 3 parties (so there is a before mobility and a latest approved version)
2. Sending hei modifies the LA (latest proposal id X).
3. Receiving hei does a GET request, does not agree and sends an UPDATE request with update-components-studied-v1 for latest proposal id X
4. Sending hei modifies the LA (latest proposal id Y)
5. Receiving hei sends an UPDATE request with approve-components-studied-proposal-v1 for latest proposal id Y
6. After a while, receiving hei sends an update request with approve-components-studied-proposal-v1 for latest proposal id X
   => If the sending hei can not ignore step 6 , it should mark the old version as last-approved...

[kamil-olszewski-uw]

@LDeprez I can't see these complications here. Each proposal has its own hash sent in get response. Sending HEI correctly handles only those update requests that contain hash of newest proposal. If there is a different hash in the update (for an older proposal, for example), sending HEI will send answer 409 (conflict).