search

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

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

If a field is present in the IIA of one HEI should it also be present in the matched IIA of the partner HEI? #81

Closed janinamincer-daszkiewicz closed 2 years ago

janinamincer-daszkiewicz commented 2 years ago

Today, during the meeeting of the Infrastructure Forum, we discussed these commits:

There is a problem with point (6) on the list: Regardless of whether or not a field is mandatory in the API, if it is present in the IIA of one HEI it should also be present in the matched IIA of the partner HEI.

The intentions are good but practically speaking it would be too restrictive to apply this rule to all fields of the IIA, like contact details or PDF. Should we remove this requirement from the list or restrict it somehow, for example to fields from cooperating conditions which are covered by hash?

lioliosn commented 2 years ago

Both partners should have the same agreement, so they should have all fields of this agreement, whether they have been inserted by partner A or B. If a field has been inserted by a partner, it means that it is important for this partner (for some reason) and its counterpart should know about this and respect it (even if it is contact details, which are no less important than cooperation conditions, because you cannot cooperate if you do not know whom to contact).

umesh-qs commented 2 years ago

@lioliosn There can be cases where some data in one of the partners IIA is not relevant to other partner and they do not store it in their local copy, and hence don't send it back in their IIA. It should be decided between the partners, whether they are ok with, only the relevant information, for them to approve the IIA.

sascoms commented 2 years ago

Restricting it at least to the cooperation conditions would be good. But, having both copies to have the same information would be better.

pmarinelli commented 2 years ago

I think imposing a one-to-one match among all fields of an IIA would be too restrictive. I don't see the need to set such a kind of restriction for fields included in the condition hash neither: a partner is always free to not approve the counterpart's copy, either because of missing fields or because of different cooperation conditions. So, I agree with @umesh-qs: it is something that should be decided between partners, not enforced by the specs.

lioliosn commented 2 years ago

We are talking about agreements, and not just about data that we share. When there is an agreement, both parties have a copy of the same content, ie same data points.

umesh-qs commented 2 years ago

If we are going by that logic then there should be only one copy. Design of each partner having their own copy is flawed.

lioliosn commented 2 years ago

If we are going by that logic then there should be only one copy. Design of each partner having their own copy is flawed.

Agreements are always in duplicates and each counterpart holds his/her copy.

umesh-qs commented 2 years ago

If we are going by that logic then there should be only one copy. Design of each partner having their own copy is flawed.

Agreements are always in duplicates and each counterpart holds his/her copy.

Are you suggesting that the process of physically signing an agreement involved each party signing each others agreement copy with a separate agreement number?

HU-Berlin-IRO commented 2 years ago

I agree that the agreements would have to contain the same fields as they are bilateral (so it is really one agreement), and partners have to be sure that in singing they agree to the same conditions, and that after signature it cannot be altered again without consent by both parties. A process which creates the IIA per partner as separate processes, creating independent workflows/agreements eg for Incoming vs. Outgoing is indeed flawed.

Belenchusky commented 2 years ago

In our current implementation, we only check the equality of the agreements by checking the equality of the cooperation conditions without taking into account the contacts, that is, looking at the fields that are important for the agreement and for us. We get and show to our users all the fields that the partner sends us, but we only store the ones that are relevant to us, so this restriction would mean a lot of work and would not give us much.

LDeprez commented 2 years ago

Ghent University supports the idea to have identical local copies of the agreement but:

We need time to be compliant to this new requirement as it is incompatible with our current installation.

janinamincer-daszkiewicz commented 2 years ago

During the coming meeting of the Infrastructure Forum on May 25th, 2022 we will vote the following options:

  1. Remove the quoted point (6) from the list of requirements.
  2. Reformulate it to: Regardless of whether or not a field is mandatory in the API, if it is present in the IIA of one HEI it is highly recommended to have it in the matched IIA of the partner HEI.
  3. Reformulate it to: Regardless of whether or not a field is mandatory in the hashed part of the cooperating conditions section of the API, if it is present in the IIA of one HEI it should also be present in the matched IIA of the partner HEI.
  4. Keep it in its original form.

Do you see any other options?

kamil-olszewski-uw commented 2 years ago

Variations in the number of persons, months of days, and EQF levels should not be allowed. In the case of "less important" information - I know that partners here and there allow some flexibility in terms of differences when someone cannot or does not feel the need to store something in their system (eg. partner units) and the partner does not mind. A question for people who absolutely do not want any differences - is this the opinion of your IROs/clients?

Another thing is that even if we choose Janina's option 3 or 4 for the API specification, it may be unenforceable. Because some systems will implement validation, some will not. And those systems in which it will be implemented will have to painstakingly compare everything field by field and grapple with different ISCED codes (three or four digits) or other subtleties that I do not remember now. Some systems will not automatically allow for differences, some will detect them and leave the decision to the user, some will not validate, ignoring this specification point.

I'm afraid of a whole lot of new reports that so far someone has managed to sign IIAs, and now suddenly can't with some partners.

I personally would be in favor of option 2.

janinamincer-daszkiewicz commented 2 years ago

VOTING! Option 1 - 10 preferences, Option 2- 19 preferences; Option 3 - 5 preferences, Option 4 – 2 preferences. Implemented in v6.1.0.