Open mkurzydlowski opened 2 months ago
janinamincer-daszkiewicz
commented
1 month ago @daniel-vitoriano I am on a conference, I will try to get the authors of MBRs to give their answers and also will add mine, but during the weekend, the earliest.
janinamincer-daszkiewicz
commented
1 month ago * Is this "Cancelled" value a new value to be added to NominationStatus?
No. This is the status of the mobility in the sending institution system (MobilityStatus).
* Since we're using a Master/Slave Model, where the receiving HEI is the owner of the NominationStatus information, how is the sending HEI supposed to change the "NominationStatus" value since this field is the receiving HEI's responsibility?
The receiving institution need not change the status on their side (NominationStatus). This mobility will not become 'life' anyway.
* Could you please clarify the differences between "NominationStatus" and "MobilityStatus" and their relationship?
Please, have a look at the scenarios listed in https://github.com/erasmus-without-paper/ewp-specs-api-omobilities#workflows-of-changes-in-nomination-and-departure-statuses I hope they are helpful.
(For instance, when MobilityStatus == Canceled should we change the NominationStatus as well? If so, to what value?)
No, the receiving HEI need not change the NominationStatus. Remember that NominationStatus and MobilityStatus are statuses exchanged via the network. Local systems may use own statuses to differentiate between various cases.
* Could you clarify in line 518, who is this "partner HEI"? Is it the receiving or the sending HEI? (https://github.com/mkurzydlowski/ewp-specs-api-omobilities/blob/1ece71b3025a507a9e63629ba859ae8d36b92215/endpoints/get-response.xsd#L514C12-L521C30)
Sending HEI (omobilities API describes mobility object as exposed in the network by the sending HEI)
* Given the whole Nomination process, until when can the sending HEI change nomination information that will cause the NominationStatus to revert to "Pending: delivered"?
Good question. In my opinion once nomination is verified/rejected it is never again pending. I will ask RMs for confirmation that I properly interpret MBR.
@kamil-olszewski-uw, @jiripetrzelka, please share your opinion.
jiripetrzelka
commented
1 month ago In my opinion once nomination is verified/rejected it is never again pending.
@janinamincer-daszkiewicz, isn't this quite the opposite of what you wrote here? https://github.com/erasmus-without-paper/ewp-specs-api-imobilities/issues/9#issuecomment-2127842292 - Sections starting with "Look at the orange arrow" and "Look at the green arrow"? You answered "Yes", which means that after a nomination is verified/rejected, it can always return to the "pending" state if any of the nomination data change.
This could also be of relevance: https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/blob/85cbafa0bc9500b15eec37f37539ed536fd34bac/endpoints/get-response.xsd#L622-L632 But here, the specification says "SHOULD become read-only", which means it may not.
So my understanding is that if the nomination status is set to "nomination" or "live" and the receveing party detects a change in the data of the owning party, it must change the incoming status to "pending". And if the nomination status is set to "recognized" and any data changes, the receiving party does not need to change the status to "pending" but should report it to Monitoring Portal or at least notify the IRO that something untoward happened. And if the nomination status is set to "cancelled" and any data changes, the receiving party can ignore it.
But these are my assumptions. I think a proper diagram with all possible transitions would be highly beneficial and should be part of the specification because the chart in the MBR does not seem to reflect all scenarios that may occur.
demilatof
commented
1 month ago What mobility type could we manage? I see that it will be removed from the README this part:
Currently, this API describes mobilities of one type only - Student Mobilities for Studies. More types MAY be added in the future
And in the get-response.xsd we have as MobilityActivityType both "student-studies" and "student-traineeships".
BUT
in the imobilities get-response.xsd we have only a student-studies element, without any student-traineeships
Doing so we cannot have any feedback about the nominations for traineeship.
janinamincer-daszkiewicz
commented
1 month ago But here, the specification says "SHOULD become read-only", which means it may not.
Yes, I agree that in this case MUST is appropriate, we will change that (after confirmation from the MBR authors). The description of statuses 'live' and 'recognized' needs refreshment.
So my understanding is that if the nomination status is set to "nomination" or "live" and the receiving party detects a change in the data of the owning party, it must change the incoming status to "pending". And if the nomination status is set to "recognized" and any data changes, the receiving party does not need to change the status to "pending" but should report it to Monitoring Portal or at least notify the IRO that something untoward happened. And if the nomination status is set to "cancelled" and any data changes, the receiving party can ignore it.
In the meantime I have got Kamil's opinion and it is compliant with what you suggest. When the sending HEI changes something in nomination and sends us CNR, it makes sense to give IRO staff from the receiving HEI some time for reaction, and in the meantime keep the status as pending.
On the other hand it does not change much as the sending HEI is the master in this process. The sending HEI is the one informing the receiving HEI about the nomination and only asking for acceptance. If they have got the acceptance they can proceed with the process. When they change their mind and withdraw the nomination, why should they care what the receiving HEI has to tell?
I am not trying to say that this is the best way to go. I just think loud if the change of the state to pending is a MUST.
But these are my assumptions. I think a proper diagram with all possible transitions would be highly beneficial and should be part of the specification because the chart in the MBR does not seem to reflect all scenarios that may occur.
Eh, I am not good at drawing diagrams :( Also I am afraid that the number of transitions is such diagram can make it unreadable. I may give it a try, but let's first try to 'draw' transitions in a way similar to what Kamil prepared here: https://github.com/erasmus-without-paper/ewp-specs-api-omobilities?tab=readme-ov-file#workflows-of-changes-in-nomination-and-departure-statuses.
We definitely need support from the MBR authors in identifying ALL state transistions.
janinamincer-daszkiewicz
commented
1 month ago Doing so we cannot have any feedback about the nominations for traineeship.
Let's discuss traineeships in https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/assets/15743501/9290406d-ab89-4545-9dce-cced2c5c607d Could you, please, move your post there?
demilatof
commented
1 month ago Doing so we cannot have any feedback about the nominations for traineeship.
Let's discuss traineeships in https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/assets/15743501/9290406d-ab89-4545-9dce-cced2c5c607d Could you, please, move your post there?
Your link doesn't work for me; anyway, if the traineeship is missing from imobilities, I'll follow the link.
janinamincer-daszkiewicz
commented
1 month ago
On the proposed pull request, it was added a new file under the resources section which raised the following questions (https://github.com/erasmus-without-paper/ewp-specs-api-omobilities/blob/1ece71b3025a507a9e63629ba859ae8d36b92215/resources/mandatory_business_requirements_nominations.pdf).
In Chapter 9, it's stated that "Nomination cancelled: the sending higher education institution cancelled the nomination as the mobility won’t take place." However, a NominationStatus is only defined by the values "Pending", "Verified" and "Rejected".