fix: switch to POST for executing jobs

[mediremi]

Closes https://jira.dhis2.org/browse/DHIS2-12156

The HTTP method for the jobConfigurations/:id/execute endpoint has switched from GET to POST.

The RunJobModal component has been updated to use POST.

[dhis2-bot]

🚀 Deployed on https://pr-324--dhis2-scheduler.netlify.app

[ghost]

I'll assign this to @Mohammer5 as well as he's there tomorrow and I'm not. I'm happy to finish reviewing this next week if there's no rush, otherwise feel free to tackle this beforehand. The broad lines look good to me at a glance.

[Mohammer5]

I think we should either prevent the modal from being closed while loading to ensure that a potential error can be shown to the user or show the error in an alert (which would be my preference as it'd be consistent with other apps)

[ghost]

I think my recommendation would be this pattern: #325. I know it's verbose, but to me it seems wrong that we recommend from one lib to not set the query during runtime, and then in other areas implement workarounds to set the query during runtime. The engine was meant as an escape hatch so to me it seems like the stable solution in the meantime. Not ideal, but I think the semantics make more sense than us trying to subvert the recommended pattern from one of our other libs.

Couple of things that would probably be good to tackle later (seems out of scope for this PR):

• Discuss @Mohammer5's suggestion, see whether an alert makes sense for any errors (though I prefer the in context noticebox more)
• Update tests to use the CustomDataProvider instead of mocking
• Remove the store abstraction (not at all related to this PR, but I really want to get rid of it)
• Eventually I do think moving towards testing-lib would be nice. Enzyme is becoming a bit of a chore
• Add functionality to the app-runtime that allows us to deal with this pattern in a more convenient/terse manner

[Mohammer5]

If the thing that I found will be deferred, I'll approve this issue

[ghost]

I'm still wondering about the question I asked wrt. the choice for useState (see review note above). Also, I think we can remove the mocking from tests that don't click the 'run job' button (like in #325). After that's addressed this should be good to go as far as I'm concerned as well.

[mediremi]

I think we should either prevent the modal from being closed while loading to ensure that a potential error can be shown to the user

I'll implement that 👍

I'm still wondering about the question I asked wrt. the choice for useState (see review note above)

Since it seems like there's a strong possiblity that resource parameterisation might be implemented in app-runtime this week, I'm happy to keep this PR open until then.

[ghost]

Since it seems like there's a strong possiblity that resource parameterisation might be implemented in app-runtime this week, I'm happy to keep this PR open until then.

I'm good with this being merged with the useState based fix.

Only thing I think I'd do is remove the mocking from tests that don't need it. And setting the useState directly (i.e. with an object). If you want to be completely robust I can imagine that you'd want the dynamic query to respond to changes in the id prop, though practically speaking I don't think that's necessary as the app doesn't do that atm.

Feel free to merge if you're happy with the PR 👍, looks good to me!

[dhis2-bot]

🎉 This PR is included in version 99.9.10 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀