search

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

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

IIA CNR automatically send when receiving IIA #96

Closed milsorm closed 1 year ago

milsorm commented 1 year ago

Currently we expect that IIA CNR identify "something changed" from other party so we will locally inform our IRO staff to "review changes and decide what to do next".

But some providers (e.g. Dashboard) sending IIA CNR back automatically when we publish new IIA and send our IIA CNR to them. The only change is associated iia_id from partner. This cannot be translated as "something changed" and local information to IRO staff is useless.

Is it correct behaviour from Dashboard to send IIA CNR when IIA is received without any human interaction? Is it necessary to compare field-by-field and identify that only partner_iia_id changed so we don't need to inform IRO staff about this CNR?

What is your behaviour when IIA CNR is received? Inform somebody or not?

Thanks for clearance.

kkaraogl commented 1 year ago

Hello Milan,

indeed, this is Dashboard's current behavior to ensure the binding of the IIA IDs, before any other negotiation action occurs.

Notifying your partner about your local IIA ID is crucial for the flow to progress and conclude.

umesh-qs commented 1 year ago

Hello Milan,

indeed, this is Dashboard's current behavior to ensure the binding of the IIA IDs, before any other negotiation action occurs.

Notifying your partner about your local IIA ID is crucial for the flow to progress and conclude.

Problem here is not about notifying about local IIA ID, but about sending that local IIA without human interaction. I thought that it was decided and agreed that this behavior should not be allowed.

milsorm commented 1 year ago

Problem here is not about notifying about local IIA ID, but about sending that local IIA without human interaction. I thought that it was decided and agreed that this behavior should not be allowed.

I recognize that behaviour only with Dashboard. And I read it in new guidelines from Dashboard. But I also think that human interaction is necessary.

If IIA ID is such crucial without human interaction than send some version of IIA CNR which indicates "automatic IIA ID assignment" but not "new version of IIA from your human partner is available". We are mixing two type of information (technical and human) in one CNR.

kkaraogl commented 1 year ago

Human interaction for the system to assign a local IIA ID and notify the partner about this ID so that the negotiation can begin?

Just to be clear, I am not saying do it this way. I understand that in your systems a user needs to click a button for this to happen, which is great (sometimes users never get to actually pressing that specific button, to actually notify their partner about their local id, but that's another story).

I am trying to understand (if and what) is the actual technical problem that the Dashboard is potentially creating for your systems.

umesh-qs commented 1 year ago

@kkaraogl there is no benefit in going over this again. To simply put, this has been decided and Dashboard must not do it.

kkaraogl commented 1 year ago

Not sure when or how it was decided. But yes, if it is decided, we will obviously comply.

But if you have an actual technical problem now in exchanging, please do come forward.

umesh-qs commented 1 year ago

image Adding this screenshot from last infrastructure forum meeting.

demilatof commented 1 year ago

@milsorm

But some providers (e.g. Dashboard) sending IIA CNR back automatically when we publish new IIA and send our IIA CNR to them. The only change is associated iia_id from partner. This cannot be translated as "something changed" and local information to IRO staff is useless.

Do you mean that Dashboard automatically associate your IIA Id to its IIA? And how it does? Does it rely on your IIA, where you fill in the partner's Id? Is it sure that you have filled it in the IIA and that it is right?

@kkaraogl

I am trying to understand (if and what) is the actual technical problem that the Dashboard is potentially creating for your systems.

Well, the Dashboard operator in the meantime could be modifying something that makes the IIA unsuitable to be immediately shared, but if the Dashboard receives an IIA CNR and it decides to reply immediately with an IIA CNR on its turn, it forces the partner to download an IIA that is not what the Dashboard operator wants to expose. And the partner has to check and understand why is it so in a mess.

IMHO, Dashboard should take care a bit more of the effects that its actions can produce in the other systems.

kkaraogl commented 1 year ago

We are taking into serious consideration comments from both of you, and the business requirements, and I am positive that we will have a conclusion soon.

The only frustration I have is that there a lot of partners that send approvals before binding IIA IDs from both systems, which creates an even bigger mess down the line of the negotiation flow. It is evident in day-to-day production exchanges. It has to be made clear to everyone, that binding of IDs should occur before any other action.

milsorm commented 1 year ago

@demilatof

Do you mean that Dashboard automatically associate your IIA Id to its IIA? And how it does? Does it rely on your IIA, where you fill in the partner's Id? Is it sure that you have filled it in the IIA and that it is right?

When we initiate IIA than Dashboard will immediate send back IIA CNR when they record IIA in their system. We recognize IIA CNR and inform IRO that something new arrived. But that is nothing new - only Dashboard immediate respond with technical ID from their side, nothing more. How can distinguish business change from technical change?

milsorm commented 1 year ago

We are taking into serious consideration comments from both of you, and the business requirements, and I am positive that we will have a conclusion soon.

The only frustration I have is that there a lot of partners that send approvals before binding IIA IDs from both systems, which creates an even bigger mess down the line of the negotiation flow. It is evident in day-to-day production exchanges. It has to be made clear to everyone, that binding of IDs should occur before any other action.

We decided to send IIA CNR just before IIA Approval to be sure that Dashboard has all IDs correct. But soethimes IIA Approval is delivered sooner than IIA CNR which cause disapproving that approval. So we made some queue and especially delay IIA Approval for several seconds after this "synchronizing IIA CNR". Sounds pity but works with Dashboard.

Because it is question what means "IIA CNR delivered after IIA Approval" - Dashboard discard approval and start negotiation again, many of other providers ignore this IIA CNR.

demilatof commented 1 year ago

@milsorm

When we initiate IIA than Dashboard will immediate send back IIA CNR when they record IIA in their system. We recognize IIA CNR and inform IRO that something new arrived. But that is nothing new - only Dashboard immediate respond with technical ID from their side, nothing more. How can distinguish business change from technical change?

I agree with you, I don't like this automatism

umesh-qs commented 1 year ago

@kkaraogl can we show some urgency here? Should be pretty easy as only 1 provider has to make changes.

demilatof commented 1 year ago

@kkaraogl can we show some urgency here? Should be pretty easy as only 1 provider has to make changes.

To fully understand how Dashboard works, does it send an IIA CNR every time a change has been saved? Or it sends an IIA CNR only on demand of the operator?

umesh-qs commented 1 year ago

@kkaraogl can we show some urgency here? Should be pretty easy as only 1 provider has to make changes.

To fully understand how Dashboard works, does it send an IIA CNR every time a change has been saved? Or it sends an IIA CNR only on demand of the operator?

I guess @kkaraogl can answer this better.

mbilalari commented 1 year ago

We prefer the wait IROs to edit an IIA when a partner initiate it. But we have got this issue too with Dashboard on exchanging IIAs. This automatism is not the only user friendly way also it is a confusing situation for IROs. Also this approach is changing the approval process as that:

So if user of X will approve the automatic copy of Dashboard, Dashboard's user will wait for a new conditions or approve the copy of X's.

Kion wants to hear different ideas to solve that.

kkaraogl commented 1 year ago

This is to avoid receiving approval from the partner without both IIA IDs being matched first. All nodes are affected by this, and it depends on the implementation of your partner. From the Infra Forum, it was evident that not everyone in the network implements this binding of IIA IDs in a strict way, which unfortunately creates more problems down the line (duplicate IIAs on your partner's side, is the first problem that comes to mind). If someone has found another way to deal with it, I am open to suggestions.

As we discussed, and most of us voted in favor of, in the Infra Forum, binding of IIA IDs will be enforced in an even stricter way by the specs, see section "IIA Approval with both identifiers", so we will also remove it soon.

demilatof commented 1 year ago

This is to avoid receiving approval from the partner without both IIA IDs being matched first. ... If someone has found another way to deal with it, I am open to suggestions.

I don't understand... Even if you immediately reply with an IIA CNR and the partner downloads your copy, you have no warranty that it puts your IIA Id in its copy (in our implementation it's done by hand, it's impossible to match them automatically; unless you replicate the partner's IIA and you throw away your copy, with the risk of and endless loop). To receive an approval you have to call its Approval APIs; but you receive the approval of your copy, the one that your partner has got from you, where you have put your partner's IIA Id.

It's up to you to approve or not the partner's copy, the one you have downloaded. If it misses your IIA-Id, you should not send an Approval-CNR to partner. If we don't send an Approval-CNR before, then we don't accept an Approval Request, because we are not ready to approve.

janinamincer-daszkiewicz commented 1 year ago

The discussion continues in https://github.com/erasmus-without-paper/ewp-specs-api-iias/issues/99.

umesh-qs commented 1 year ago

This is to avoid receiving approval from the partner without both IIA IDs being matched first. All nodes are affected by this, and it depends on the implementation of your partner. From the Infra Forum, it was evident that not everyone in the network implements this binding of IIA IDs in a strict way, which unfortunately creates more problems down the line (duplicate IIAs on your partner's side, is the first problem that comes to mind). If someone has found another way to deal with it, I am open to suggestions.

As we discussed, and most of us voted in favor of, in the Infra Forum, binding of IIA IDs will be enforced in an even stricter way by the specs, see section "IIA Approval with both identifiers", so we will also remove it soon.

@kkaraogl your comments are misleading. Can you please mention here who is not binding IIAs strictly before approving? Also we are messing the IIA process further with 2 different sources of truth. One in the IIA and other in IIA approval. Looks like you just want to avoid making changes in Dashboard system to not to automatically link IIAs on false pretext of this new change in IIA Approval API. Both IIA in approval API is just and overhead.