allow workflow config to unset global events config

[TomekTrzeciak]

This addresses a bug whereby it is not possible to reset list-type values like mail events from the global config to empty list by overriding them in the workflow config.

Check List

• I have read CONTRIBUTING.md and added my name as a Code Contributor.
• Contains logically grouped changes (else tidy your branch by rebase).
• Does not contain off-topic changes (use other PRs for other changes).
• Applied any dependency changes to both setup.cfg (and conda-environment.yml if present).
• Tests are included (or explain why tests are not needed).
• Changelog entry included if this is a change that can affect users
• Cylc-Doc pull request opened if required at cylc/cylc-doc/pull/XXXX.
• If this is a bug fix, PR should be raised against the relevant ?.?.x branch.

[MetRonnie]

Thanks @TomekTrzeciak 👍 it might be January before we have a chance to look at this however

[oliver-sanders]

This would change the meaning of mail events = from "reset to global default" to "reset to empty list".

The "reset to empty lisy" behaviour makes sense, but unfortunately, I think there may be valid use cases for both behaviours (especially when you take inheritance into account). I had a skim through workflows at our site to see what list items are being "unset" in this way and found the following:

• mail events (a lot of instances)
• (submission|execution) retry delays (a lot of instances)
• handler events (a few instances)
• collapsed families (a couple instances)

[MetRonnie]

I think this "reset to global default" behaviour only happens for events settings and no other settings?

[TomekTrzeciak]

I think this "reset to global default" behaviour only happens for events settings and no other settings?

My reading is that only events and mail settings under scheduler section would be affected by this change.

This would change the meaning of mail events = from "reset to global default" to "reset to empty list".

The "reset to empty lisy" behaviour makes sense, but unfortunately, I think there may be valid use cases for both behaviours (especially when you take inheritance into account). I had a skim through workflows at our site to see what list items are being "unset" in this way and found the following:

• mail events (a lot of instances)
• (submission|execution) retry events (a lot of instances)
• handler events (a few instances)
• collapsed families (a couple instances)

Out of this list only mail events and handler events would be affected by this change. On our site only the former (mail events) is set in the global config and thus would behave differently (and as expected IMHO).

[hjoliver]

So this change would mean:

• no mention in workflow config: you get the global defaults
• explicit key = # nothing: you get nothing

Seems good to me, no blockers as far as NIWA is concerned.

@oliver-sanders - would it be sufficient for you just to ping the owners of the workflows you found and tell them about the change?

[oliver-sanders]

@oliver-sanders - would it be sufficient for you just to ping the owners of the workflows you found and tell them about the change?

Will do. I'll confirm the scope of the change and try to work out the intention of the users impacted. So long as it's just [scheduler][events and [scheduler][mail], I'm not expecting any issues.