search

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

Learning Agreements
MIT License
1 stars 2 forks source link

Change an OLA before it was accepted by the partner? #47

Closed JoepDemey closed 7 months ago

JoepDemey commented 7 months ago

Is a student allowed to make changes to his (proposed) OLA before the partner accepts it?

Student makes an OLA: course A course B and signs it, so it is a change proposal and a cnr is sent to the partner.

Partner has not yet reacted and the student decides to replace course A with course C, signs it, so a new cnr is sent to the partner.

When the partner calls the OLA get API, what is in the change proposal?

course A - inserted course B - inserted course A - deleted course C - inserted

or just

course B - inserted course C - inserted

?

umesh-qs commented 7 months ago

course A - deleted course C - inserted

kamil-olszewski-uw commented 7 months ago

The LA API specification doesn't prohibit withdrawing from the LA proposal not yet approved by the partner and replacing it with another one, but it should be done for a really good reason, because it's always troublesome for the receiving university. Nevertheless, the receiving university's system must be able to properly handle such a situation.

This is manageable by using the changes proposal id in get response and update request and by responding with an HTTP 409 to the update request with approval/rejection of the outdated changes proposal.

What is helpful here is that subsequent versions of LA do not contain a history of changes or refer to previous versions. Of course, apart from the fact that each later version (tables A2/B2/C2) must include the approved first version (tables A/B/C).

In your example, since the sending university canceled the first version of the LA before it was approved by the receiving university, a new first version should be created in its place. So it should simply contain:

course B course C

Without any additional information about inserted/deleted - because this applies to LA versions later than the first one.

JoepDemey commented 7 months ago

The LA API specification doesn't prohibit withdrawing from the LA proposal not yet approved by the partner and replacing it with another one, but it should be done for a really good reason, because it's always troublesome for the receiving university. Nevertheless, the receiving university's system must be able to properly handle such a situation.

This is manageable by using the changes proposal id in get response and update request and by responding with an HTTP 409 to the update request with approval/rejection of the outdated changes proposal.

What is helpful here is that subsequent versions of LA do not contain a history of changes or refer to previous versions. Of course, apart from the fact that each later version (tables A2/B2/C2) must include the approved first version (tables A/B/C).

In your example, since the sending university canceled the first version of the LA before it was approved by the receiving university, a new first version should be created in its place. So it should simply contain:

course B course C

Without any additional information about inserted/deleted - because this applies to LA versions later than the first one.

That's a very clear answer, thank you!