Moving nomination status to Incoming Mobilities API

[MartaJuzepczuk]

@erasmus-without-paper/all-members

We plan to move accepting nominations from Outgoing Mobilities update endpoint to Incoming Mobilities get + CNR.

As proposed here, we will introduce second mobility status, let's call it nomination status, owned by the receiving HEI and sent through Incoming Mobilities API.

In details:

1. We remove update-statuses from Outgoing Mobilities update endpoint.
2. We remove two values of MobilityStatus of outgoing mobility: nomination-verified and rejected.
3. We add new required field to Incoming Mobilities get response: status, with three possible values: pending (no decision made), verified, rejected.
4. We assume, that the receiving institution is the master of nomination status (status from Incoming Mobilities API) and the sending institution is the master of mobility status (status from Outgoing Mobilities API).
5. When the receiving institution accepts or rejects nomination, it sends CNR (Incoming Mobility CNR). The sending institution can check the decision by calling Incoming Mobilities get.

Does it fit you? Do you think we should make some changes in this proposal? We plan to release new versions of Incoming and Outgoing Mobilities APIs in a few weeks.

Discussion about removing update endpoint was in #25 and #31.

[BavoNootaert]

This proposal resolves indeed our issues with the status-updates.

[janinamincer-daszkiewicz]

Marta, I see no objections. Let's finalise the change.

[MartaJuzepczuk]

Changes submitted: Outgoing Mobilities API v0.15.0 Incoming Mobilities API v0.2.0

[georgschermann]

@BavoNootaert @MartaJuzepczuk @janinamincer-daszkiewicz

Sorry I hadn't had the time to look into this earlier. If I understand correctly, with this change we effectively lost the possibility to update or notify the sending Hei when the MobilityStatus changes. Changes between status "nomination", "live", "recognized" and "cancelled" can no longer be communicated from receiving to sending HEI ? I think the NominationStatus would have to be extended by at least "completed" and "cancelled". What are your opinions about this, how would you inform the sending HEI if the mobility ended at the end of the stay or early, the student extends it's stay or didn't show up in the first place?

[MartaJuzepczuk]

Thank you for your notice.

We would prefer not to extend the NominationStatus, to keep it clear who is the master of the MobilityStatus. However, you are right that there should be a way to inform sending HEI about shortening or extending the stay, or about the situation when the students did not show up.

There is one unreleased commit, which we are going to release until tomorrow. In this commit we add a new field with a comment to the Incoming Mobilities response. We planned to name it status-comment and use it to inform partner about reason of rejecting nomination (such field was present in Outgoing Mobilites update endpoint and was missing while moving nominations status to the Incoming Mobilities API).

After internal discussion, we came up with a solution to change the name of status-comment to comment and change its description, encouraging partners to send it when something strange happens. This, together with two existing date fields (actual arrival date and actual departure date), should be enough to handle the situations you mentioned.

For example:

Situation 1: Student did not show up. Receiving HEI: Leaves actual-arrival-date empty and writes a proper comment, sends CNR. Sending HEI: Receives CNR, makes get request, reads the comment, contacts student. Then, for example:

• student has resigned, sending HEI changes the status of the mobility to cancelled, sends CNR (Outgoing Mobility CNR)
• student will arrive few weeks later for some reason, sending HEI changes the planned-arrival-date, sends CNR

Situation 2: Student leaves earlier. Receiving HEI: Sets actual-departure-date and writes a proper comment, sends CNR. Sending HEI: Receives CNR, makes get request, reads the comment. Probably continues internally.