Emikat Trigger specifications

[patrickkaleta]

• [x] include forceRecalculate attribute Set the boolean forceRecalculate attribute in each PUT request to inform Emikat if the changes made to the study affect the calculations or not. Swagger Interface with examples: https://service.emikat.at/EmiKatTst/swagger/index.html#!/EmiKat32Scenario32resource/insertScenario
• [x] trigger Emikat only for certain Study types (TBD which ones)
• [x] handle events when Study type changes (e.g. change status in Emikat? TBD) it won't be possible to change study type

[patrickkaleta]

Emikat is now triggered only when the selected study type contains calculation methods that are appropriate for Emikat. Such calculation methods are those that have the emikat keyword in the Calculation method ID field.

ToDo:

Since the study type can be changed by the user, we have to take into account the possiblity, that a previously irrelevant study suddenly becomes relevant for Emikat and vice versa.

case 1)
non-relevant -> relevant: that's the simple case, since this will basically be like an "intial Emikat trigger" event, where the Study is sent to Emikat for the very first time. No action needed here

case 2) relevant -> non-relevant: In this case the study might already be stored on Emikat-side, so we need to tell Emikat that (for the moment) this study is not active. Need to discuss with @humerh how this could be implemented.

[DenoBeno]

Forget it. Just warn the users if necessary, that's all.

I suppose that the Emikat results aren't going to be shown in the different study type anyway.

Patrick Kaleta notifications@github.com schrieb am Fr., 6. Dez. 2019, 10:45:

Emikat is now triggered only when the selected study type contains calculation methods https://csis.myclimateservice.eu/admin/structure/taxonomy/manage/calculation_methods/overview that are appropriate for Emikat. Such calculation methods are those that have the emikat keyword in the Calculation method ID field. ToDo:

Since the study type can be changed by the user, we have to take into account the possiblity, that a previously irrelevant study suddenly becomes relevant for Emikat and vice versa.

case 1) non-relevant -> relevant: that's the simple case, since this will basically be like an "intial Emikat trigger" event, where the Study is sent to Emikat for the very first time. No action needed here

case 2) relevant -> non-relevant: In this case the study might already be stored on Emikat-side, so we need to tell Emikat that (for the moment) this study is not active. Need to discuss with @humerh https://github.com/humerh how this could be implemented.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/clarity-h2020/csis-helpers-module/issues/12?email_source=notifications&email_token=AAWTC7WGXIE7DLPYZNGUDITQXINMNA5CNFSM4IOT6PGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGDSNNY#issuecomment-562505399, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWTC7TS3KGWXGFKXFT6M73QXINMNANCNFSM4IOT6PGA .

[p-a-s-c-a-l]

Since the study type can be changed by the user, we have to take into account the possiblity, that a previously irrelevant study suddenly becomes relevant for Emikat and vice versa.

I would suggest to disable this feature and close this issue. Changing the study type shall no longer be allowed. For the implementation and testing phase it was helpful, but in the operational system it will just confuse users, e.g. if some steps or even results disappear after (accidentally?) changing the study type as observed here. Moreover, as steps are recreated, it breaks all permalinks containing a step id.

[patrickkaleta]

I would suggest to disable this feature and close this issue. Changing the study type shall no longer be allowed. For the implementation and testing phase it was helpful, but in the operational system it will just confuse users, e.g. if some steps or even results disappear after (accidentally?) changing the study type as observed here. Moreover, as steps are recreated, it breaks all permalinks containing a step id.

I agree. Setting the Study type should only be possible once during the initial creation of a new Study, since it has such a big (and unpredictable) impact on everything else. I'll remove the Study type field from all edit forms, so that it cannot be changed once it's set.