Process for correcting wrongly mapped IIAs

[umesh-qs]

@janinamincer-daszkiewicz can you please confirm if this is correct.

1. Partner A maps IIA of partner B which it received earlier
2. Partner A call IIA CNR API of partner B
3. Partner B call IIA GET API of partner A
4. Partner B maps the IIA based on the mapping in IIA GET of partner A
5. Partner B realized that partner A has mapped wrong IIAs
6. Partner B removes the mapping in their system and calls CNR of partner A
7. Partner A calls IIA GET API of partner B and sees no mapping
8. Partner A also unlinks the IIAs and wait for partner B to do the mapping.
9. Partner B maps a different IIA and calls IIA CNR of partner A
10. Partner A calls IIA GET of partner B and sees the new linking and does the same in their system.

[janinamincer-daszkiewicz]

In this GitHub issue I shared results of the discussion from Thessaloniki. GitHub issue is not closed, anybody can comment. DG EAC will make a decision.

[umesh-qs]

In this GitHub issue I shared results of the discussion from Thessaloniki. GitHub issue is not closed, anybody can comment. DG EAC will make a decision.

@janinamincer-daszkiewicz Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

As @demilatof mentioned, please point out the specific complexity that you are referring to. Let us not make wild assumptions without providing examples.

As for the voting, I see rules of the game are being changed often. I am not sure how and when this new rule of DG EAC allowing voting came into effect. You cannot pick and choose what goes for voting and what doesn't. If there is a disagreement, it must go for voting.

[janinamincer-daszkiewicz]

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

DG EAC is making decisions, the rules are not changed, before the previous voting this was also their decision what exactly should be voted.

[umesh-qs]

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

@janinamincer-daszkiewicz then let us not try to influence the voting. And if there was a discussion then I assume that pros and cons would have been discussed. I would expect that to be listed instead of a one line that discussion happened

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

@janinamincer-daszkiewicz No you didn't. Please explain with examples. Merely specifying "complexity" wont do.

DG EAC is making decisions, the rules are not changed, before the previous voting this was also their decision what exactly should be voted.

@janinamincer-daszkiewicz This is not true. Again misleading. Process is to go for voting whenever there is lack of consensus.

[demilatof]

Since you are referring to the discussion Thessaloniki, please post here all the providers who voted against changing the mapping IIA ID in Thessaloniki.

There was discussion, not voting. I leave to the providers decision if they want to be named.

I attended remotely, I don't remember any discussion about this, otherwise I would have said or written something. May be I missed it; may even be they talked about this problem during a coffee or during the tests.

Anyway, I saw no more than fifty participants in Zoom, and some of the connection where present twice or three times in the same moment. In Thessaloniki there were 10-12 peoples, including Janina and Kostantinos. Too few people and too little representative (them, including me, are in-house system developers) to address a problem toward a solution or another. We are talking of no more twenty HEIs against thousands.

If I have a problem, I expose myself. @umesh-qs is doing the same. Doing so, we expose ourselves to criticism, no problem. I think that if someone considers the changing mapping a problem he must expose his/her problem on GitHub. Otherwise we may think that there isn't a real owner of the problem neither a real issue, but this a problem in your implementation or in the implementation of someone near you.

@janinamincer-daszkiewicz then let us not try to influence the voting. And if there was a discussion then I assume that pros and cons would have been discussed. I would expect that to be listed instead of a one line that discussion happened

please point out the specific complexity that you are referring to.

I already did and will not be repeating myself. I leave the floor to the others.

@janinamincer-daszkiewicz No you didn't. Please explain with examples. Merely specifying "complexity" wont do.

@umesh-qs I confirm, until now it is complex because it is.

[kkaraogl]

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions?

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

[umesh-qs]

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions? @kkaraogl this is irrelevant. Please focus on this issue.

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

@kkaraogl please share the problem with example. Let us not go over again and again with one liners. @janinamincer-daszkiewicz please share here the details of the discussion in detail (pros and cons).

[kkaraogl]

@umesh-qs I already did, multiple times. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

[umesh-qs]

@umesh-qs I already did, multiple times. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

No you didn't. You are replying exactly same as @janinamincer-daszkiewicz . Please explain what is the complexity here for the IIAs that are not approved?

[demilatof]

@demilatof more than 35 testing sessions in pairs have occurred in the workshop. Have you tested with someone during the sessions?

No, because I'm alone in developing our in-house system and we are not yet ready (almost ready, but not completely). And I'm involved not only in this project, but even in the existing Erasmus software at our HEI. And, moreover, I've to spend half of my time discussing here to stop proposals that have no sense or are necessary due to a bad design and analysis of the EWP. I answered you, even if I've not to justify myself.

All that said, you may consult your file to realize that 35 testing sessions means 14 HEIs. https://docs.google.com/spreadsheets/d/19nldiHlWsbBOF0gX_RR2ySvsmP9U7xL4TfkIeT9VTD0/edit#gid=196398466

For this thread, Umesh's proposal is not wholesome, in my opinion. I've already shared it a couple of times in this thread. Until someone presents a simple and efficient way, always keeping in mind the integrity of data for both involved partners, I cannot add anything else here.

Who has an issue, should publicly declare it, not during a coffee or a private chat.

[kkaraogl]

@demilatof please ping the EWP Dashboard team whenever you are ready to test in the development registry. Most of your questions and objections will be resolved by testing, once you actually test the exchanges with a working implementation of another partner.

If you still have objections or questions you could bring them up in GitHub, not the other way around.

Please don't take this the wrong way, I am simply suggesting the way that makes sense to me, after testing with a vast number of partners.

[umesh-qs]

@kkaraogl since you have come to the discussion forum, please do not disappear as usual before closing this. Also if there are problems with Dashboard, as the previous comment suggests then fix those in Dashboard and not just blindly say it is complex.

[kkaraogl]

@umesh-qs I am ignoring the remark of me disappearing from the forum as usual, because it is kind of unfair, and sounds like an insult.

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

We can follow up on this in a call, to properly discuss this.

Let's investigate collaboratively If there is a simple wholesome technically feasible way to handle this, and we will not object to it. If there is such a solution, then both of us will come on this thread asking from Warsaw to acknowledge the issue and properly address it from specs.

[demilatof]

If you still have objections or questions you could bring them up in GitHub, not the other way around.

Is what I have done, I write often in GitHub. Did you do the same?

Please don't take this the wrong way, I am simply suggesting the way that makes sense to me, after testing with a vast number of partners.

So this is your need or your proposal?

Also if there are problems with Dashboard, as the previous comment suggests then fix those in Dashboard and not just blindly say it is complex.

As a matter of fact, often I have the impression that we have to conform to the Dashboard model and not the contrary, even when it could be a good practice.

[umesh-qs]

@umesh-qs I am ignoring the remark of me disappearing from the forum as usual, because it is kind of unfair, and sounds like an insult.

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

We can follow up on this in a call, to properly discuss this.

Let's investigate collaboratively If there is a simple wholesome technically feasible way to handle this, and we will not object to it. If there is such a solution, then both of us will come on this thread asking from Warsaw to acknowledge the issue and properly address it from specs.

@kkaraogl it might sound unfair, but I am only telling the what I have seen. Last reply from @demilatof seems to suggest the same. Also your point of view has and is always from Dashboard perspective. I have mentioned this earlier and I am saying it again. We will do what is best for our clients and not go by what technical problems/limitations Dashboard has. AND THIS IS NOT A PROPOSAL. THIS IS A GENUINE USE CASE. Your limitation cannot force us to limit our system. I cannot force my clients to do more work for a silly mistake that they can make when linking IIAs

[demilatof]

Again, this is not about the Dashboard. The steps you proposed will not work, in my opinion, for all partners, and will add to the confusion.

Your opinion should not be more relevant than the others. You haven't explained what is the confusion, until now. I have two IIAs bounded together with A1 id and B1 id; I make a change and I associate A1 to B2, and send you an IIA CNR. Now, two possibilities:

1. If your IROs work basing on their IIAs, when they open B1 IIA they see that it is bounded with A1 IIA that instead is bounded to B2. You remove B1-A1 association and open B2 to join it to A1.
2. If your IROs work reacting to IIA CNR, they fetch A1 IIA, they see that it was joined with B2 and therefore they remove any other association with A1 IIA.

Where is the confusion, where is the complexity?

The confusion starts with your proposal, when the content on an IIA start flying from an IIA ID to another.

We can follow up on this in a call, to properly discuss this.

No, this is a public matter, all are interested in this solution and can bring their contribute.

[demilatof]

@kkaraogl it might sound unfair, but I am only telling the what I have seen. Last reply from @demilatof seems to suggest the same. Also your point of view has and is always from Dashboard perspective. I have mentioned this earlier and I am saying it again. We will do what is best for our clients and not go by what technical problems/limitations Dashboard has. AND THIS IS NOT A PROPOSAL. THIS IS A GENUINE USE CASE. Your limitation cannot force us to limit our system. I cannot force my clients to do more work for a silly mistake that they can make when linking IIAs

Standing ovation ;-)

[kkaraogl]

@umesh-qs again, nothing to do with the Dashboard. I am sharing my technical opinion on this matter.

You proposed some steps to tackle a problem. I've shared my opinion and pinpointed why it is not technically feasible.

I've also offered to collaboratively figure it out, thoroughly test it, and bring forward a joint proposal for Warsaw to review and address it from specs. So that all partners in the network can implement it without adding more confusion.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub.

[umesh-qs]

@umesh-qs again, nothing to do with the Dashboard. I am sharing my technical opinion on this matter.

You proposed some steps to tackle a problem. I've shared my opinion and pinpointed why it is not technically feasible.

I've also offered to collaboratively figure it out, thoroughly test it, and bring forward a joint proposal for Warsaw to review and address it from specs. So that all partners in the network can implement it without adding more confusion.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub.

@kkaraogl you may say so. But in absence of any concrete example from your side, it will only point to limitation in Dashboard. Can you please point out what is wrong in the steps? I am repeating again .. this is not a proposal. This is a scenario that exists already.

[kkaraogl]

@umesh-qs I already did pinpoint where the problem with the proposal lies, multiple times.

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, show you where your proposal lacks, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub. Please do take up on the offer to collaboratively figure this out.

[umesh-qs]

@umesh-qs I already did pinpoint where the problem with the proposal lies, multiple times.

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

I will send an email to QS technical team, Monday morning, to collaboratively discuss the issue, show you where your proposal lacks, and investigate if we can jointly bring forward a wholesome technical proposal for other partners and Warsaw to review publicly in GitHub. Please do take up on the offer to collaboratively figure this out.

@kkaraogl I think you have not provided any counter arguments. Even if you would have I am sure all are countered. If not please for benefit of everyone please list down again. Can you please elaborate on "unilaterally disseminate this changing of IDs"? This is where I say you only think from the current design of Dashboard. I am open discussion on call, once you have listed down the problems with changing the mapped IIA ID, which I already mention is one of the workflow that is already in place.

[demilatof]

This issue persists in the production network, because there are some implementations that unilaterally disseminate this changing of IDs from their local implementations to their remote partners.

How much? 1, 10, 100? If they are few, they have to review their implementation, not the others. If they have problems, they have to represent them here, not to you. Until now, I heard only "it's complex"; the complexity depends on the competence. For a child may be complex 2x2; for a boy not. Let's understand what kind of complexity we have, please invite the partners that find the actual solution "complex" to come here and explain their difficulties. We all want to collaborate, but here.

[jiripetrzelka]

Here is Umesh's scenario:

1. Partner A maps IIA of partner B which it received earlier
2. Partner A call IIA CNR API of partner B
3. Partner B call IIA GET API of partner A
4. Partner B maps the IIA based on the mapping in IIA GET of partner A
5. Partner B realized that partner A has mapped wrong IIAs
6. Partner B removes the mapping in their system and calls CNR of partner A
7. Partner A calls IIA GET API of partner B and sees no mapping
8. Partner A also unlinks the IIAs and wait for partner B to do the mapping.
9. Partner B maps a different IIA and calls IIA CNR of partner A
10. Partner A calls IIA GET of partner B and sees the new linking and does the same in their system.

Here is Janina's proposal:

The proposed approach is the following. IIA-id is a key of the copy of the IIA (its primary key). A pair of (mapped) copies is identified by a pair of iia-ids. They should also be treated as the primary key. Different primary keys mean that we have different objects. If the system find out that the local IIA with some id A1 once mapped with id B1 now comes from the partner mapped with another id B2, it should treat this as an error. Identifiers are identifiers and should not be freely mapped and unmapped.

My thoughts:

What happens if partner A makes a mistake in point 1 and later realizes it and needs to change it? According to Janina's proposal, it would not be possible (partner B could find out that the mapping changed and would consider it to be an error). Partner A would therefore have just one chance to come up with a correct mapping and if s/he fails, s/he would face dire consequences: The obligation to rewrite the contents of its incorrectly mapped IIA with the other (correct) IIA and then probably discard the other IIA. I think this would create total havoc considering that there may already be mobilities attached to the IIA from previous academic years (2021/22 or 2022/23). If this interpretation of mine is correct, I am strongly against this proposal.

I think that we need to take into account that IROs can make a mistake and that both parties can almost simultaneously come up with different mapping and that neither party is automatically right because it was first to suggest a mapping. The truth is with the business level, and in case of conflict, it must be the business level at which a mutually acceptable mapping is found - that is, in some cases, IROs will have to contact each other by phone/e-mail and decide which IIA belongs to which IIA. Once both partners have identical mapping in their systems and they have verified this, they can start approvals. At this point, the mapping should become immutable and any change by any partner should be treated as an error.

[kkaraogl]

@jiripetrzelka please consider the following and please help towards closing it

1. Partner A & Partner B have successfully exchanged IDs that are binded: A1, B1.

Partner A: A1, B1 Partner B: B1, A1

2. Partner B changes its local ID to B2 and sends CNR

Partner A: A1, B1 Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction. If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

[jiripetrzelka]

If the intention of partner B is to re-associate A1 to B2, partner A would GET IIA B2 and would find there the binding B2-A1.

In the other scenario you describe, B2 would not have anything to do with this pair of IIAs. Yes, Dashboard could consider it to be a new IIA. But it could also be that B2 would correspond to some other "orphaned" IIA in Dashboard and the IRO could locate it and bind it to B2 so that a duplicate creation is prevented. I don't know how much leeway Dashboard gives their users at this point but in our system the IRO could decide between the option to bind the B2 to an existing IIA or create a new IIA.

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Back to the "workable" scenario you described: Partner A would see that partner B suggests that the correct mapping is B2-A1. Partner A has A1-B1. So partner A would change it to A1-B2. In our system, this would require an explicit action from the user because there already was a mapping and this is a non-standard scenario and the user should be aware of what is happening, at least in my opinion.

[demilatof]

Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction.

This is a real mapping change

If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

In this case B2 has nothing to do with the previous mapping, how can you say that B2 has replaced B1? What we have to see is if B1 still exists and still have an A1 ID in its body. If B1 no more exists, A should remove the association A1-B1. If B1 has no partner's ID inside its body, A should contact B to be sure that he has to remove the association A1-B1. If B1 has another A's ID inside (e.g. A2), A should unlink A1-B1 and if A accepts the new match, open A2 and join to B1

[kkaraogl]

The real mapping changes, as @demilatof put it, must be thoroughly tested, then communicated/presented to the IF to all the partners, and then addressed by the specs, in my opinion.

There are a lot of partners, including Dashboard, that honor the binding of IIA IDs and do not allow this, as @janinamincer-daszkiewicz already shared in her proposal, treating them as primary keys. I still prefer Janina's proposal. There is not a use case I can identify for a local implementation to change its local ID, especially if they've previously shared another ID with their partner. Why not maintain the local ID, and change the data in the response, as a simple edit action?

Once Delete kicks-in in the network, the potential (A1, B1) stuck copy on Partner A, will organically resolve by itself, right?

The *manual matching/linking/unlinking of IIAs in the local system, changing local IDs, still looks to me like a feature of a local system, that once disseminated in the network, can cause problems to the other partner, unless everyone technically acknowledges it and deals with it efficiently.

*I've used more candid words about this local manual matching feature when we discussed with @jiripetrzelka in Thessaloniki, but I am not trying to impose my technical opinion on what other local systems do.

[kkaraogl]

And after all said and done, we are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

[demilatof]

The real mapping changes, as @demilatof put it, must be thoroughly tested, then communicated/presented to the IF to all the partners, and then addressed by the specs, in my opinion.

I think that it is not necessary; the specifications don't forbid the mapping changes, as they don't forbid a change in a cooperation condition. Or should we come back and require a discussion for everything during the IF? The explanation of the EWP mobility process says: "Each partner uses his own ID for the IIA, so partners will need to manually "bind" their local agreements with their remote counterparts"

If some implementer is doing this automatically and now he has problems to manage particular cases, the problem is in his approach that don't follow the above sentence.

There are a lot of partners, including Dashboard, that honor the binding of IIA IDs and do not allow this,

As I already said, these partners should participate in this discussion on GitHub; I hope you'll be so kind to invite them to explain here their problem. "A lot of" doesn't tell me anything: 1, 10 or 100? Until now, we can suppose that only Dashboard has this problem; we are waiting for other partners coming out.

Why not maintain the local ID, and change the data in the response, as a simple edit action?

Because an ID identifies an IIA and not other data, not only on EWP but even in local system where most of the partners have other software. From "Important Rules": Partners should exchange identifiers of their copies of the IIA to match these copies respectively in their systems. Not two generic identifiers that later the partners can fill in some information, but the identifier of a given IIA (and not another one). @janinamincer-daszkiewicz also said: "Identifier is the unique identifier of the object and should never be reused to identify a different object."

Once Delete kicks-in in the network, the potential (A1, B1) stuck copy on Partner A, will organically resolve by itself, right?

You have to delete nothing; it's probably a problem of your implementation. There is no (A1, B1), there is an A1 that doesn't need to be joined to B1. You remove B1 from it, and then you could associate A1 to another B's IIA or delete, if you want.

The *manual matching/linking/unlinking of IIAs in the local system, changing local IDs, still looks to me like a feature of a local system, that once disseminated in the network, can cause problems to the other partner, unless everyone technically acknowledges it and deals with it efficiently.

I think you are wrong: as I've reminded you just above, the manual bind is strongly suggested as a well known need.

*I've used more candid words about this manual matching feature when we discussed with @jiripetrzelka in Thessaloniki, but I am not trying to impose my technical opinion on what other local systems do.

We are not imposing our technical opinion on what your local system does, but if your system has problems because it doesn't consider all the technical requirement (e.g. manual mapping), we cannot take in consideration to modify and complicate our systems to help you.

[demilatof]

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing.

This happens almost always: I (partner A) have my list of IIAs, you (partner B) have your list of IIAs. The first time I fetch your B1 most probably it has no binding and I have to do. What is the difference with the problem you've described? If I can bind B1 with something, I do it. Otherwise, I know there is a B1 that I can ignore.

[umesh-qs]

@jiripetrzelka please consider the following and please help towards closing it

1. Partner A & Partner B have successfully exchanged IDs that are binded: A1, B1.

Partner A: A1, B1 Partner B: B1, A1

2. Partner B changes its local ID to B2 and sends CNR

Partner A: A1, B1 Partner B: B2, the question is if A1 is still included in Partner's B IIA GET response

3. Partner A does IIA Get from Partner B

If B's GET response includes both B2 and A1, there might be a possibility that this could work, so let's look into this direction. If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA. Partner B, in the process of changing local ID, also left Partner A with the (A1,B1) copy, stuck in their system.

@kkaraogl please do not mislead on according to the specs. What specs say that individual system might treat it as duplicate. So it is up-to your implementation. No problem for our system. Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

[janinamincer-daszkiewicz]

Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

Umesh, please, do not make such statements which are not true. Never ever anything in the specification has been crafted with the Dashboard in mind. Nor any other system. You should remember that as you were partner in EWP 2.0.

[umesh-qs]

Also I strongly believe this statement in the specs is added in favor of Dashboard alone.

Umesh, please, do not make such statements which are not true. Never ever anything in the specification has been crafted with the Dashboard in mind. Nor any other system. You should remember that as you were partner in EWP 2.0.

I am ready to take it back. Please share just a couple of providers who were facing this duplicate issue at the time this statement was added. Yes we were partner in EWP 2.0. But that does not mean that we were ok with everything that was done

[kkaraogl]

@umesh-qs specs are pretty clear about what I wrote above:

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/83a208eb83bb6a93525f8e8b036d41a5e406484a/endpoints/get-response.xsd#L99

If we start debating step 0, I won't be able to contribute in the discussion.

We are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

[jiripetrzelka]

From the position of partner A you show B1 to the user and let him decide to either import it as a new local IIA (ID will be automatically created and assigned to B1) or let them link B1 to an existing IIA from the list of "orphaned" local IIAs in A's system. Ideally, user's attention should first be brought to the list of best potential matches and only if the match is not found should he be offered the option to import the IIA and create a new IIA. In our system, the system lists potentially matching IIAs in such an order that the most probable matches are on top of the list (i.e. IIAs with the same ISCED).

[demilatof]

@umesh-qs specs are pretty clear about what I wrote above:

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/83a208eb83bb6a93525f8e8b036d41a5e406484a/endpoints/get-response.xsd#L99

What is the problem with this point? It may always happen, not only when someone removes the mapping.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

If A gets B1 and doesn't find the mapping with A1, in our implementation the IRO see an error and:

1. Cannot approve B1
2. Can select "remove this association" and remove A1-B1 from A1

After point 2 we have reset the situation to the initial point: we have A1 that we need to associate to another B's IIA. Since we fetch all B's IIAs by means of the Index API, we most probably have even B2 that suggest a mapping with A1. The IRO can check this suggestion and eventually associate A1 to B2. I think that this is a normal good practice, no much complicated.

In our implementations we always start from our IIAs; if we lack some IIA, we may add it. But our implementations are not driven by partner's IIAs

[skishk]

we are discussing an internal implementation of each system that is not EWP spec. Everyone choose how to manage it and if you choose to link/bind automatically you have to manage this scenario when someone remove the link/binding. if you choose to link/bind them manually you already could manage all scenarios.

this is my point of view.

[umesh-qs]

@umesh-qs specs are pretty clear about what I wrote above:

https://github.com/erasmus-without-paper/ewp-specs-api-iias/blob/83a208eb83bb6a93525f8e8b036d41a5e406484a/endpoints/get-response.xsd#L99

If we start debating step 0, I won't be able to contribute in the discussion.

We are still left with this edge case that both @jiripetrzelka and @demilatof described. Copying it from Jiri's response:

The question is rather what to do in case partner A GETs IIA B1 and the binding is missing. This corresponds to Umesh's points 6 and 7. How to interpret this? Partner B has probably realized B1 does not belong to A1 and neither has he found any other IIA of partner A that would correspond to B1. So it either does not exist or he didn't look properly at all potential matches of partner A for B1. So Partner A would then probably look too and realize that he should create a new IIA or would match it to some of his "orphaned" IIAs.

Could you contribute on how you are currently dealing with it or how you suggest that the other partners should interpret it and act upon it?

@kkaraogl I am not starting from 0. I am only countering what you said "If B's GET response contains only B2, according to the specs (nothing to do with the Dashboard), this is a new IIA". I cannot help if you don't like it the counter arguments. As I said your statement is not entirely true. It depends on how individual systems handle it. And I guess only Dashboard creates automatic IIA internally which creates duplicates.

[kkaraogl]

I'll agree with @skishk that what we are discussing is a matter of the local implementations to handle it.

I would still argue that it should be communicated to all the other partners, so that they are aware. Nothing further to contribute in this discussion.

[janinamincer-daszkiewicz]

DG EAC suggests to vote on this issue. Help me in preparing the questions for the voting. The first draft proposal.

Wrongly mapped IIAs
GitHub issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/101  
Let’s assume that partner A maps IIA received from partner B with their local copy A1 
and shares this mapping with B. After some time it changes the mapping to A2 
and again shares this mapping with B. 
Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.
2. No – after sharing the mapping with the partner the user can not change it.

In case 2 how should B behave?

1. Treat such change in the mapping as an error.
2. Allow the local user to update the mapping.

[demilatof]

My two cents...

The voting will be for wrong mapping not mutual approved IIAs or even for mutual approved IIAs? I think it could be specified to avoid misunderstandings.

I understand and agree with the question; I understand less the two possible solutions...

In case 2 how should B behave?

1. Treat such change in the mapping as an error.

What does it mean treat such change in the mapping as an error? Or, to be more clear, once we decide to treat such change in the mapping as an error, what can we do to remove the error?

2. Allow the local user to update the mapping.

How can the local user update the mapping if this possibility is the consequence of "after sharing the mapping with the partner the user can not change it"?

[janinamincer-daszkiewicz]

Only for not mutually approved IIAs. Please give your proposal for the questions.

[skishk]

1. Yes – users can freely map and unmap copies of IIAs.

I agree with point 1 : user can freely map and unmap copies of IIAs.

In every scenario this happen, mutual approved or one side approved or not still approved, this must be managed as a change that need approval , in my opinion. That solve all scenarios.

[demilatof]

Please give your proposal for the questions.

I am in trouble in finding any proposal, since I would like better the first solution (free mapping and unmapping). Therefore, if the partners vote for the second option, I hope in the less invasive consequence (even if ugly). My proposal, in this case, is:

A) The wrong mapping A1-B1 makes void IIA IDs A1 and B1, therefore they cannot be used anymore in EWP and should be considered as deleted (as a matter of fact, what happens if I delete an IIA that I've already mapped? We have not discussed about this possibility, or perhaps we said that we can delete it anyway).

The consequence should be managed at local level, if the partner needs to reuse the same IIA; e.g. one partner could:

• Make a copy if its own IIA and give it a new IIA Id.
• Change the IIA ID of the object with a completely new one IIA ID
• Change the IIA ID simply by adding a suffix (A1 -> A1v2, in case of a second error A1v3, then A1v4 and so on)

[fioravanti-unibo]

Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.

Agree with point 1; the mapping of an IIA with the corrisponding partner IIA is an attribute and - in my opinion - an un-map and a re-map should be managed as a change.

[umesh-qs]

DG EAC suggests to vote on this issue. Help me in preparing the questions for the voting. The first draft proposal.

Wrongly mapped IIAs
GitHub issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/101  
Let’s assume that partner A maps IIA received from partner B with their local copy A1 
and shares this mapping with B. After some time it changes the mapping to A2 
and again shares this mapping with B. 
Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs.
2. No – after sharing the mapping with the partner the user can not change it.

In case 2 how should B behave?

1. Treat such change in the mapping as an error.
2. Allow the local user to update the mapping.

@janinamincer-daszkiewicz if in option 2 you are allowing "Allow the local user to update the mapping", then how is it different from option 1?

[janinamincer-daszkiewicz]

@umesh-qs Please give your proposal for the questions..

[umesh-qs]

Wrongly mapped IIAs GitHub issue: https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/101
Let’s assume that partner A maps IIA received from partner B with their local copy A1 and shares this mapping with B. After some time it changes the mapping to A2 and again shares this mapping with B. Should specification allow A to change the mapping?

1. Yes – users can freely map and unmap copies of IIAs. This should be treated like any other change.
2. No – after sharing the mapping with the partner the user cannot change it. Treat such change in the mapping as an error and not accept the IIA.

[demilatof]

2. Treat such change in the mapping as an error and not accept the IIA.

And then? What do you mean with "not accept the IIA"? How do we have to manage those IIA-IDs? If they are lost, what are the lost IIA-IDs? A1, B1 and even A2?

@janinamincer-daszkiewicz At some point we have A1-B1, the old mapping, and A2-B1, the new attempting. A1-B1 is wrong by the wills of the A partner, A2 is good but used with B1 (already used with A1).

What have we to discard for ever? A2 remains good and B partner has to replicate B1 in B2, and then we can have A2-B2? That is, for the mistake of A, B has to go into trouble to duplicate and to discard B1?

[umesh-qs]

2. Treat such change in the mapping as an error and not accept the IIA.

And then? What do you mean with "not accept the IIA"? How do we have to manage those IIA-IDs? If they are lost, what are the lost IIA-IDs? A1, B1 and even A2?

@demilatof then is it a special case, to be handled via email. Like many such cases that is handled outside the system. Partner causing this error should correct it. I do not see any problem here.

@janinamincer-daszkiewicz At some point we have A1-B1, the old mapping, and A2-B1, the new attempting. A1-B1 is wrong by the wills of the A partner, A2 is good but used with B1 (already used with A1).

What have we to discard for ever? A2 remains good and B partner has to replicate B1 in B2, and then we can have A2-B2? That is, for the mistake of A, B has to go into trouble to duplicate and to discard B1?