search

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

Learning Agreements
MIT License
1 stars 2 forks source link

Student data and changes-proposal #40

Closed spinho-uporto closed 1 year ago

spinho-uporto commented 1 year ago

  1. When student data such as date of birth is changed, should these changes be reflected in the XML (student element) or should they remain only in an approved change (after approval)?

  2. If mobility data such as the planned start/end date changes, should these changes be reflected in the XML after there has already been a first notification? These dates may change before the student starts the mobility.

  3. When changes to student data need to be approved, this must be shown in the change proposal element. If there are no components to change, what to show in the ListOf_Components in the changes-proposal? No changes in the changes-proposal can be understood as no changes from the first version (https://github.com/erasmus-without-paper/ewp-specs-api-omobility-las/issues/ 39 ).

janinamincer-daszkiewicz commented 1 year ago

Our analyst from the University of Warsaw is on vacation, he will answer after his return, i.e. after 4th of August.

kamil-olszewski-uw commented 1 year ago

Ad 1. Changed personal data of the student should appear both in main LA data and in the changes-proposal element. There is no need to wait with the partner's approval for the change of this data in the main LA data. Placing student's changed personal data in the changes-proposal element is only intended to draw the attention of the receiving university to this change. However, you should not put student data in the aproved-changes element - it would be against the specification.

Ad 2. Changes to these dates (and all other data sent via LA API) must be always reflected in the LA. However, the dates are minor changes that are not reported in the changes-proposal element.

Ad 3. Yes, the absence of components in the changes-proposal could be interpreted as going back to first version. So these components should be repeated in changes-proposal. Having to report personnel changes this way is inconvenient, but these are top-down guidelines that we must stick to. Hopefully this will be removed from this API in the future when the use of the Outgoing Mobilities API becomes mandatory.