search

erasmus-without-paper / ewp-specs-api-omobilities

Specifications of EWP's Outgoing Mobilities API.
MIT License
1 stars 4 forks source link

Alternative model for proposing suggestions #12

Closed wrygiel closed 7 years ago

wrygiel commented 7 years ago

The current (v0.1.0) mobility specs require the sending institution to allow receiving institution to directly change the mobility object. This was one of the requirements from WP2's output.

However, @janinamincer-daszkiewicz claims that that - in practice - the receiving HEI only suggests these changes, and it is always the sending HEI who actually applies them. This discussion lead us to thinking of some alternatives, but before I start on actually specifying them, I'd like us to discuss this here.

Is it required to allow the receiving HEI to change the Mobility object "in real time" (as in current specs)? Or, would it enough if they only proposed such changes, and the sending HEI would store them "on the side" and review them later (without changing the actual mobility object in real time)?

Currently, both solutions sound feasible to me, but our internal team claims that "suggestions" would be much simpler for them to implement. @erasmus-without-paper/all-members - what do you think?

georgschermann commented 7 years ago

We will abstract the api to suggestions either way, so if we use suggestions by design it would fit even better. Usually universities are not very happy if some 3rd party members change their student data. For our most recent customers (last ~2 years) it is even legally forbidden, since they have to state every person which has access to this data.

kaiqu commented 7 years ago

This concept is already in the model, but it's connected to Learning Agreement (which, in practice, means changes to the underlying Components): A New Revision of a LA has a "Suggesting IIA Partner" and Sending/Receiving Approval Dates. But if it always is the receiving HEI that suggests, the IIA Partner Reference isn't needed. I will replace it with a Suggesting Date (which should have been there anyway).

BTW, this connects with the discussion about which Mobility information that needs to be versioned: The Suggesting and Approval Dates are connected to LA, not the Mobility itself, which means that the Mobility fields Status, Planned/Actual Arrival/Departure Dates etc. are not subject to the proposed suggestion process.

wrygiel commented 7 years ago

Mobility fields Status, Planned/Actual Arrival/Departure Dates etc. are not subject to the proposed suggestion process.

As far as I know, actual arrival/departure dates are always provided by the receiving HEI.

I will think how this can be implemented. But probably there will be a couple of various types of suggestions one can send. Perhaps we will even need a separate API for each type of suggestion (because we need the sending HEI to be able to cover only a subset of all possible suggestions).

kaiqu commented 7 years ago

As far as I know, actual arrival/departure dates are always provided be the receiving HEI.

Hm - yes, of course. It seems there are three bad solutions here, model-wise:

  1. The Actual Arrival/Departure Dates are moved from Mobility to LA (even though they have nothing to do with the agreement per se) - meaning that the receiving HEI updates the dates in the final LA Revision.

  2. The Suggestion Date and Sending/Receiving Approval Dates are moved from LA to Mobility - meaning that the mechanism for suggesting/approving changes applies to the Mobility as a whole, not just the LA.

  3. The Suggestion Date and Sending/Receiving Approval Dates are duplicated from LA to Mobility - meaning that both Mobility and LA have a mechanism for suggesting/approving changes.

Alternative 3 is the worst, but I'm not sure about the other two. What do you think, @wrygiel ?

wrygiel commented 7 years ago

How about storing suggestions as XML blobs?

-- pseudosql
create table suggestions (
    mobility_id varchar,
    author_hei_id varchar,
    author_email varchar,
    date date,
    status? enum(...),
    suggested_change_xml text,
    -- possibly more... (comments? revisions?)
)

Since these are suggestions only, they will probably be processed by a single piece of software only. Only after they are reviewed, they would go to the actual data tables and become visible to other pieces of software.

If so, then there's no real gain in keeping these suggestions in multiple specialized tables - we may keep all kinds of suggestions in a single blob-based table, and suggested_change_xml would contain the actual suggestion, exactly as received from the partner, in XML format (specified by EWP).

kaiqu commented 7 years ago

How about storing suggestions as XML blobs?

Hm, maybe... Are you suggesting that these be used for versioning as well, i.e. for reconstructing the change history? If that is doable, it would solve the versioning issue as well.

wrygiel commented 7 years ago

Are you suggesting that these be used for versioning as well, i.e. for reconstructing the change history?

No. Versioning history is a somewhat separate issue. But this would make implementing versioning history easier, I think, because there would be only one "committer" in such history (so that he can modify the history, if need be - and this was not possible in previous model).

wrygiel commented 7 years ago

As far as I know, versioning has to be implemented for components only, and maybe nothing more. While suggesting needs to be implemented for a broader set of fields.

But this is not a mature concept yet. It requires much more thought on my part.

kaiqu commented 7 years ago

As far as I know, versioning has to be implemented for components only, and maybe nothing more.

Hopefully. I will remove versioning at the Mobility level for the time being, to unclutter the diagram.

While suggesting needs to be implemented for a broader set of fields. But this is not a mature concept yet. It requires much more thought on my part.

I will think about this at my end too...

wrygiel commented 7 years ago

The new way of proposing suggestions is described here.