Closed anantqs closed 7 months ago
Linking mobilities with IIAs is not covered by EWP specifications. Of course if the mobility module is part of the Student Information System (SIS) there is such a linking. Otherwise this becomes the responsibility of the user to know is such linking exists and express this relation somehow in the mobility module.
We will have the similar issue with Transcripts of Records, as grades and credits are stored in the local SIS and have to be somehow transferred to the mobility module connected to the EWP network. The mobility module should somehow be integrated with the local SIS otherwise more responsibility is put on the end users.
So before the termination takes place, if the system is not able to make some validations by itself, it should ask the end user for confirmation and base further actions on the user's decision.
Also, if a service provider sends a termination request to a partner and partner sends an error saying "mobilities exist" - what should be the steps taken?
The users should contact outside the EWP and resolve the situation. In fact the best approach is when the users first contact outside EWP and then terminate, modify, etc.
I think the point 2, cell B10, in the scenario sheet
- No mobilities exist for this IIA
may sound ambiguous: mobiities exist for this IIA (they are listed in the cooperation conditions element). What should not exist is even a single "active" mobility, a situation that could be not completely true anyway. For example, an HEI has started the applications but for any reason it knows that they cannot be brought on and could accept to terminate the IIA as a whole.
What I mean is that it should be demanded to the officers to accept or not the termination as a whole for an IIA, and not to the developers (except checking if it is mutually approved). And therefore there should not any error reporting, except for not mutually approved IIA.
No mobilities exist for this IIA
Can we terminate an agreement that had mobilities for previous years, but has no "active" mobilities for the next year? For example, if we have an agreement from 2022 to 2027, and we had 5 mobilities in 2022/2023 (all finished) and we have another 5 mobilities for 2023/2024, but they are not "active" yet (all the LA for this year are in version CHANGE_PROPOSAL without any FIRST VERSION or CHANGE_APPROVED).
Can we terminate an agreement that had mobilities for previous years, but has no "active" mobilities for the next year?
The 'no mobilities' condition is related to 'terminated as a whole' only. Any other terminations are implemented as modifications.
Can we terminate an agreement that had mobilities for previous years, but has no "active" mobilities for the next year?
The 'no mobilities' condition is related to 'terminated as a whole' only. Any other terminations are implemented as modifications.
so that means if the IIA had one mobility and it's ended and now there are no mobilities (actvie) we could not use Terminate as a whole? so with "no mobilities" it's mean zero mobilities on the Agreement and not "no mobilities active". if it is like that i think IROs will use 99.99% of times a normal modification.
i'm asking again just to be sure thank you
Can we terminate an agreement that had mobilities for previous years, but has no "active" mobilities for the next year?
The 'no mobilities' condition is related to 'terminated as a whole' only. Any other terminations are implemented as modifications.
so that means if the IIA had one mobility and it's ended and now there are no mobilities (actvie) we could not use Terminate as a whole? so with "no mobilities" it's mean zero mobilities on the Agreement and not "no mobilities active". if it is like that i think IROs will use 99.99% of times a normal modification.
i'm asking again just to be sure thank you
You are probably right. "Terminate as a whole" it hardly going to be used. Even if it is used it can be reverted back and the IIA can be used normally. I do not see much value of terminate as a whole.
May be not much value, but a special case, which - unfortunately, for the technical reasons - needs special treatment.
May be not much value, but a special case, which - unfortunately, for the technical reasons - needs special treatment.
A special case that can be reverted? So what is special about it then?
A special technical solution (using special attribute).
A special technical solution (using special attribute).
Exactly; just a recap to help everybody to understand. Normally, if we need to terminate in advance a mobility, it's enough to lower the receiving-last-academic-year-id value.
E.g.: we move from this:
<cooperation-conditions>
<student-studies-mobility-spec>
...
<receiving-last-academic-year-id>2027/2028</receiving-last-academic-year-id>
...
</student-studies-mobility-spec>
<cooperation-conditions>
to this
<cooperation-conditions>
<student-studies-mobility-spec>
...
<receiving-last-academic-year-id>2024/2025</receiving-last-academic-year-id>
...
</student-studies-mobility-spec>
<cooperation-conditions>
But if we need to say that the mobility will be never used, even if we have mutually approved the IIA, we cannot use any of the following solutions:
This is why we need a special attribute, as @janinamincer-daszkiewicz said
A special technical solution (using special attribute).
Exactly; just a recap to help everybody to understand. Normally, if we need to terminate in advance a mobility, it's enough to lower the receiving-last-academic-year-id value.
E.g.: we move from this:
<cooperation-conditions> <student-studies-mobility-spec> ... <receiving-last-academic-year-id>2027/2028</receiving-last-academic-year-id> ... </student-studies-mobility-spec> <cooperation-conditions>
to this
<cooperation-conditions> <student-studies-mobility-spec> ... <receiving-last-academic-year-id>2024/2025</receiving-last-academic-year-id> ... </student-studies-mobility-spec> <cooperation-conditions>
But if we need to say that the mobility will be never used, even if we have mutually approved the IIA, we cannot use any of the following solutions:
- set the receiving-last-academic-year-id to the same value of receiving-first-academic-year-id (this would mean that the mobility last one year and that it is valid for that year)
- set the receiving-last-academic-year-id to a lesser value than receiving-first-academic-year-id (this would put in a mess the controls of data consistence)
- remove the mobility, because we will have a mutually approved IIA with an empty cooperation-conditions
This is why we need a special attribute, as @janinamincer-daszkiewicz said
Yes in theory. What is the practical use of this?
Yes in theory. What is the practical use of this?
In order to know how a critical case has to be managed if it ever happens. Feel free to ignore it if you will never have this issue
Yes in theory. What is the practical use of this?
In order to know how a critical case has to be managed if it ever happens. Feel free to ignore it if you will never have this issue
Such a critical case (that can be ignored) must be documented and shared with everyone. Please enlighten everyone on the critical case that you have in mind. May be we are missing something.
Unfortunately we cannot ignore and have to put efforts to implement it, else we will not be compliant.
Yes in theory. What is the practical use of this?
In order to know how a critical case has to be managed if it ever happens. Feel free to ignore it if you will never have this issue
Such a critical case (that can be ignored) must be documented and shared with everyone. Please enlighten everyone on the critical case that you have in mind. May be we are missing something.
Unfortunately we cannot ignore and have to put efforts to implement it, else we will not be compliant.
It was; I'm sorry if you missed it (again), but it was widely discussed and shared on GitHub and during Infrastructure Forums, starting from February, at least
https://github.com/erasmus-without-paper/ewp-specs-api-iias#important-rules
I wish you will enjoy your reading time
Sadly, you are just acting like someone who is the owner of the specification, when they get agitated when questioned. I wonder if you drafted/requested this change?
Your replies now days are so wayward. I just asked for a real world example of terminate as a whole. How is it useful practically. Just provide a practical use of it, at-least with respect to how your clients will use it? If it is worth we will encourage our clients as well.
Your replies now days are so wayward. I just asked for a real world example of terminate as a whole. How is it useful practically. Just provide a practical use of it, at-least with respect to how your clients will use it? If it is worth we will encourage our clients as well.
This is what you have asked
Such a critical case (that can be ignored) must be documented and shared with everyone.
A practical use? Your IROs should be able to describe it... It has been enough described in the previous months, do you need only now a practical use of it?
Anyway, here you are:
Your replies now days are so wayward. I just asked for a real world example of terminate as a whole. How is it useful practically. Just provide a practical use of it, at-least with respect to how your clients will use it? If it is worth we will encourage our clients as well.
This is what you have asked
Such a critical case (that can be ignored) must be documented and shared with everyone.
A practical use? Your IROs should be able to describe it... It has been enough described in the previous months, do you need only now a practical use of it?
So, is it wrong to ask now, if it was not asked earlier? I assume that whatever is introduced in the specification is consulted with IROs. Problem is that we do not get to know which all clients have asked for it. How many of those who asked for it are using which provider system. We are just told that IROs were consulted/informed. Process is opaque.
Anyway, here you are:
- October 2023: we have mutually approved an IIA (my copy and your copy) for a particular area, starting from February 2024
- November 2023: our only teacher interested in that IIA is no more available and we don't have a replacement
- December 2023: we decide that we cannot exchange students any more for that area, so we terminate as a whole the IIA
Ok so this is "critical" because, your IROs want proof/acknowledgement from the partner institution that, no mobility has taken place on a particular IIA? How are you tracking this? In your system are you making IIA mandatory in omobility response?
You had your answer, we are talking about IIAs, the omobility response is outside the issue.
The decision process is outside the issue too. It's the same always used, not the best, but the fact that you discover it when you have to review your code is only a way to make others waste their time.
You had your answer, we are talking about IIAs, the omobility response is outside the issue.
How conveniently you have skipped the question. This only proves how critical your scenario is. Problem with EWP is that we want to introduce something without running through the entire process. And when shown the problem, standard answer is, "This is outside scope of the EWP. Partners must coordinate and sort out".
The decision process is outside the issue too. It's the same always used, not the best, but the fact that you discover it when you have to review your code is only a way to make others waste their time.
You create/defend specifications, that is waste of time and then talk about wasting others time. You jumped into responding the question. No one forced you. Please feel free to stay out of it.
Btw are you now part of the team drafting the specifications? And you don't like people questioning it? Have never seen you defend things so vociferously.
How conveniently you have skipped the question. This only proves how critical your scenario is. Problem with EWP is that we want to introduce something without running through the entire process. And when shown the problem, standard answer is, "This is outside scope of the EWP. Partners must coordinate and sort out".
If you knew the process, you would know the process start with the IIAs. You have to correctly manage the IIA, the omobilities play a role later and you have to model them according to the IIA. Termination-as-a-whole avoid whatever ambiguities, the ones that you like so much when you give an empty approval putting in a mess who has to set up his internal system.
You create/defend specifications, that is waste of time and then talk about wasting others time. You jumped into responding the question. No one forced you. Please feel free to stay out of it.
Btw are you now part of the team drafting the specifications? And you don't like people questioning it? Have never seen you defend things so vociferously.
This is one of the few points we have discussed all together during Infrastructure Forums and in GitHub, for almost half a year. Where were you? Now that we have to implement the new specifications, not the best but the maintainers left no more space for discussion, you awake and try to re-discuss everything?
And note that I think you will not have more answers than what I gave you. For me is a pleasure to stay away, I will save my time. Anyway, I've not ever seen you proposing any solution about this issue, neither about saving the approval after switching to v7, and so on. Just complaining to force everyone to adopt your solution, so that you haven't to rewrite code.
I wish you a good implementation.
How conveniently you have skipped the question. This only proves how critical your scenario is. Problem with EWP is that we want to introduce something without running through the entire process. And when shown the problem, standard answer is, "This is outside scope of the EWP. Partners must coordinate and sort out".
If you knew the process, you would know the process start with the IIAs. You have to correctly manage the IIA, the omobilities play a role later and you have to model them according to the IIA. Termination-as-a-whole avoid whatever ambiguities, the ones that you like so much when you give an empty approval putting in a mess who has to set up his internal system.
You create/defend specifications, that is waste of time and then talk about wasting others time. You jumped into responding the question. No one forced you. Please feel free to stay out of it. Btw are you now part of the team drafting the specifications? And you don't like people questioning it? Have never seen you defend things so vociferously.
This is one of the few points we have discussed all together during Infrastructure Forums and in GitHub, for almost half a year. Where were you? Now that we have to implement the new specifications, not the best but the maintainers left no more space for discussion, you awake and try to re-discuss everything?
And note that I think you will not have more answers than what I gave you. For me is a pleasure to stay away, I will save my time. Anyway, I've not ever seen you proposing any solution about this issue, neither about saving the approval after switching to v7, and so on. Just complaining to force everyone to adopt your solution, so that you haven't to rewrite code.
I wish you a good implementation.
So according to you, maintainers and you will decide when to highlight a problem. You say "it is a pleasure to stay away". But you wont, because you take pleasure in taking a discussion personally and going to any extent (logical/illogical) to defend it. Please go back and see from where the discussion stated. The point that was being put forward was that terminate as a whole is most likely not going to be used as it is not well conceived. And you are only accepting that by stating "not the best but the maintainers left no more space for discussion". I did not invite you for discussion. You jumped in as if you are being put in the dock.
It is not my job to think of scenarios and write specifications. But it is my right to point out the problems at any point. Me not suggesting. Me not pointing problems when the specs were being discussed, has nothing to do with the problems I raise. But as usual, you have habit of taking a discussion in some random direction. Where I am forcing someone to adopt something that is not in specification? In-fact you have such tendency and you do this time and again.
You might be helping the team with specification. Which is good. But do not think yourself as the owner of specifications. You will not be able to judge between right and wrong.
@umesh-qs I decide nothing, I only say that it is ridiculous that you awake now, after almost a year, complaining that the information about this part has not been shared with all. I was trying to share with you (and with others) what I know about this issue, knowing that nothing from me can be an official position. But if you only interest is complaining, I'm really happy to stay away.
I've nothing to learn from you, if you aren't able to suggest any improvement this doesn't mean that others have to do the same and then complaining of solutions when it's late to modify them. I'm not a judge between right and wrong, I only give my opinion on what is reasonable according to the specifications. The problem is that you don't even accept any judge, neither @janinamincer-daszkiewicz or @mkurzydlowski
Where I am forcing someone to adopt something that is not in specification?
Every time you insist on adopting a wrong solution just because it's your implementation, such as using empty approval or not using terminate-as-a-whole just because you don't know the existence of this kind of need.
All that said, have a good time
@umesh-qs I decide nothing, I only say that it is ridiculous that you awake now, after almost a year, complaining that the information about this part has not been shared with all. I was trying to share with you (and with others) what I know about this issue, knowing that nothing from me can be an official position. But if you only interest is complaining, I'm really happy to stay away.
No you were not sharing. You were trying to justify that the scenario of "terminate as a whole" is a critical use case that if was not introduced would have stopped the IIA flow. Which you failed to, and with that frustration, doing personal attack.
I've nothing to learn from you, if you aren't able to suggest any improvement this doesn't mean that others have to do the same and then complaining of solutions when it's late to modify them. I'm not a judge between right and wrong, I only give my opinion on what is reasonable according to the specifications. The problem is that you don't even accept any judge, neither @janinamincer-daszkiewicz or @mkurzydlowski
Please learn from whoever you wish to, but please do learn to discuss without getting personal. Pointing out on what I do, what I don't, does not change the core issue.
Where I am forcing someone to adopt something that is not in specification?
Every time you insist on adopting a wrong solution just because it's your implementation, such as using empty approval or not using terminate-as-a-whole just because you don't know the existence of this kind of need.
Again I am not sure from whom you are learning to mislead (I would say just short of lying) this forum. Please visit the thread again on empty response on approval https://github.com/erasmus-without-paper/ewp-specs-api-iias-approval/issues/15. I spoke based on what is there in the specification and how some other provider are interpreting. You want to force everyone to use it in a particular way. I have never said not to use "terminate-as-a-whole". All I said was that it is not worth and that my system will have to implement it to be compliant.
Whoever is the judge as per you must get the specifications corrected. All these discussions/clarification are of no meaning if not part of specification. But the problem with the judges here is that they do not want to do this, as it would mean that the specification was loose. I have not seen a single comment from whoever is the judge is, that they will add more clarity in the specifications for various topics.
All that said, have a good time
Thanks. I am having a good time. I hope you are having it too. I will take a pause until there is anything concrete in your replies.
No you were not sharing. You were trying to justify that the scenario of "terminate as a whole" is a critical use case that if was not introduced would have stopped the IIA flow. Which you failed to, and with that frustration, doing personal attack.
I've never said that it would have stopped the IIA flow; this is how you gain what you call personal attack.
Please visit the thread again on empty response on approval erasmus-without-paper/ewp-specs-api-iias-approval#15. I spoke based on what is there in the specification and how some other provider are interpreting. You want to force everyone to use it in a particular way.
You are insisting; you are wrong, but you insist. I don't want to force nobody to use it in a particular way, I invite everybody to not introduce ambiguities on the network. And what I said was tested with Dashboard during a session testing and then confirmed by Janina during that session. I only report what was confirmed as correct; who have confirmed your interpretation?
All I said was that it is not worth and that my system will have to implement it to be compliant.
Who are you to say what is worth or not? And if it is not worth, why are you wasting our time with a lot of questions? If it is not worth, there should not be much to discuss.
Whoever is the judge as per you must get the specifications corrected. All these discussions/clarification are of no meaning if not part of specification. But the problem with the judges here is that they do not want to do this, as it would mean that the specification was loose. I have not seen a single comment from whoever is the judge is, that they will add more clarity in the specifications for various topics.
Yes, the specifications are weak, I've been saying for months that they are far away to be considered stable, but not in this particular case, that is enough documented. And yes, they speak a lot, but they write almost nothing in the specifications, I already said during an Infrastructure Forum.
There should not need of a lot of scenarios if the specifications clearly described the rules. Anyway, I hope you will open an issue about the mutual approval, if you have any doubt about it. If you don't, then don't complain later about different implementations.
No you were not sharing. You were trying to justify that the scenario of "terminate as a whole" is a critical use case that if was not introduced would have stopped the IIA flow. Which you failed to, and with that frustration, doing personal attack.
I've never said that it would have stopped the IIA flow; this is how you gain what you call personal attack.
I meant that the scenario was projected as critical, as if IIA flow would stop. I read 'critical' as "having the potential to become disastrous; at a point of crisis". Is that the case with this scenario? And if so then why is it not linked to mobility process. Why is it completely left at user discretion?
Please visit the thread again on empty response on approval erasmus-without-paper/ewp-specs-api-iias-approval#15. I spoke based on what is there in the specification and how some other provider are interpreting. You want to force everyone to use it in a particular way.
You are insisting; you are wrong, but you insist. I don't want to force nobody to use it in a particular way, I invite everybody to not introduce ambiguities on the network. And what I said was tested with Dashboard during a session testing and then confirmed by Janina during that session. I only report what was confirmed as correct; who have confirmed your interpretation?
I am reading the specification. And arguing logically. Unlike you who just keep saying "Janina has confirmed what you are saying is correct". Why wasn't that anomaly in Dashboard system communicated to all providers. Fact that someone raised the issue recently and mentioned that there are providers doing it in a way, that as per you is not as per specification, itself proves my point. Systems running in v6 with this are still running with this just like Dashboard is/was running until now.
Now all of a sudden your judge says, that this is not allowed. And that judge does not find necessary to communicate to all stakeholders, neither update the specification. This is how judges make decision? Btw since the start of EWP I have never got to know who the real Judge is :) So again, whatever is your claim please get them added to the specification. Happy to oblige once it is part of specification.
All I said was that it is not worth and that my system will have to implement it to be compliant.
Who are you to say what is worth or not? And if it is not worth, why are you wasting our time with a lot of questions? If it is not worth, there should not be much to discuss.
Whoever is the judge as per you must get the specifications corrected. All these discussions/clarification are of no meaning if not part of specification. But the problem with the judges here is that they do not want to do this, as it would mean that the specification was loose. I have not seen a single comment from whoever is the judge is, that they will add more clarity in the specifications for various topics.
Yes, the specifications are weak, I've been saying for months that they are far away to be considered stable, but not in this particular case, that is enough documented. And yes, they speak a lot, but they write almost nothing in the specifications, I already said during an Infrastructure Forum.
There should not need of a lot of scenarios if the specifications clearly described the rules. Anyway, I hope you will open an issue about the mutual approval, if you have any doubt about it. If you don't, then don't complain later about different implementations.
I have said whatever is to be said in this forum and outside of the forum as well. If someone doesn't want to listen, it is loss for EWP, as the implementations might be delayed.
In Termination scenarios, it mentions that when we receive a IIA with terminated-as-a-whole set to yes, we should check that "No mobilities exist for this IIA". See cell B10, point 2 in the scenarios sheet. If there are no mobilities, we are expected to send an error in EWP monitoring. However, it is not mandatory for us to link mobilities to IIAs. This gives rise to 2 cases
Case 1 - Let's take a university who uses different service providers for IIA and mobilities. If their partner sends a termination request - it not possible for the IIA service provider to check if there are LAs or nominations linked since they are different systems. Case 2 - The university uses the same service provider for IIAs and mobilities, but the service provider does not link the two (since this is not mandatory as per the EWP APIs).
In both cases, can the check for mobilities be skipped and error not sent to monitoring API? Also, if a service provider sends a termination request to a partner and partner sends an error saying "mobilities exist" - what should be the steps taken?