search

erasmus-without-paper / ewp-specs-api-omobility-las

Learning Agreements
MIT License
1 stars 2 forks source link

Deletion of LA #33

Closed jiripetrzelka closed 3 years ago

jiripetrzelka commented 3 years ago

Consider the following scenarios:

  1. Student cancels the mobility after the first version of the LA has been accepted. Subsequently, the student or the coordinator deletes the LA (regardless of whether it is a hard or a soft delete) and the LA is no longer available through any endpoint.

    • Question A: Should the sending institution send a CNR at the moment of deletion?
    • Question B: Should the receiving institution consider the absence of the LA in the GET endpoint as the LA having been deleted?

  2. Later, it turns out that the student's mobility will not be cancelled after all because, for instance, a place has been found on another IIA at the same institution. Now the student creates a new LA, which will be associated to the original mobility and thereby it will use the original omobility-id in the LA GET/Index endpoints.

    • Question C: Am I right in assuming that client implementers have to be able to handle this scenario and accept the fact the owning side of the mobility discarded the LA and created a new one? I.e. they must not consider it an error that a change proposal which they assume should end up to be an approved change will actually end up as a new first version.

  3. The LA's type is blended or short-term doctoral. The first version has already been accepted. The student wants to make a change. The LA is therefore deleted and a new LA is created.

    • Question D: Since it is still the same mobility the new LA has the original omobility-id of the deleted LA. Is this right?

Generally, I'm assuming that the owning side is free to delete the LA at any point and create a new one and that the omobility-id can be reused if none of the immutable fields (sending-hei, receiving-hei and nominee) change, as described here: https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/blob/3c76b350bc33b3a52acb8673bc958dafba871ef9/endpoints/get-response.xsd#L58

kamil-olszewski-uw commented 3 years ago

Ad A. The general specification of CNRs for all APIs is that a notification must be sent in the event of any object change that will be visible by the EWP partner - including in the event of object deletion.

Ad B. Better not to assume anything about the absence of the LA. LA may have been removed, temporarily hidden after receiving HEI's rejection of the first version, temporarily unavailable due to a bug in the system...

Ad C. Receiving HEI cannot consider it technically incorrect that a completely new LA (with changes proposal of first version) comes with the same omobility-id from sending HEI. Obviously, such a rare situation can cause concern for receiving HEI and in that case it may be explained in some way, but rather outside of EWP.

Ad D. Yes, we always use the same omobility-id. This is especially important when using the Outgoing Mobilities API - because the same omobility-id must be used in both APIs.

Generally speaking, when we are dealing with the same mobility, we always use the same omobility-id no matter what happens with different LAs related to that mobility.