feat: Enable exceptional entries in support rota #690
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.Scanned FilesNone |
There was a problem hiding this comment.
Pull Request Overview
This PR removes the supportPeriod field from the SupportACL class and refactors support rota logic to enable exceptional (non-standard duration) entries in the support rota. The change eliminates the hardcoded support period concept that was duplicating rota structure and blocking flexible rota scheduling.
- Remove
supportPeriodfield fromSupportACLclass and update all creation calls - Refactor
activeSupportUsersandnextSupportUsersto use slot-based logic instead of period-based calculations - Update rota logic to find the last/next slot based on start times rather than fixed duration windows
Reviewed Changes
Copilot reviewed 12 out of 12 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| configTools/src/main/scala/com/gu/janus/model/models.scala | Remove supportPeriod field from SupportACL case class and factory method |
| app/logic/UserAccess.scala | Refactor support user lookup logic to use slot-based approach instead of period-based |
| test/logic/UserAccessTest.scala | Update test cases to remove supportPeriod parameter and add exceptional rota entry |
| configTools/src/main/scala/com/gu/janus/config/Loader.scala | Remove period loading logic from config |
| configTools/src/main/twirl/com/gu/janus/config/templates/janusData.scala.txt | Remove period field from config template |
| configTools/src/main/scala/com/gu/janus/model/configuredRepresentation.scala | Remove period field from ConfiguredSupport |
| Multiple test files | Update SupportACL.create calls and remove period-related test cases |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
61f2d34 to
27ca098
Compare
emdash-ie
left a comment
There was a problem hiding this comment.
I’m not very familiar with the code, but it looks good to me! Thanks for doing this – I had it on my list but never got to it :)
There was a problem hiding this comment.
Makes sense and looks good. We'll have to release this carefully because it's a breaking change to the config format.
I'm a bit nervous that we're adding behaviour and the overall test count is -1? Is it worth creating a group of tests that have a rota set up like the one in this issue, and asserting that the support gets calculated properly at each point? The approach in the PR means this behavious is neatly covered by the tests that are already there, so this certainly isn't essential! It'd more be to document the expected behaviour for a rota like this and prevent regressions if someone accidentally moves it back to a week-by-week approach in the future.
As you'll have guessed, the behaviour we're replacing here is there to cover the returns None if there are no entries for the next rota by provided date test and it's important to note that the new behaviour is a regression on that score. Based on the support rota's history I think it's probably fair to go forwards with the proposed approach and say "this will never happen", but if we want to be more defensive I'd keep the rota period and use it as a maximum length on a support rota. This would give us the flexibility to cover support shifts that change mid-rota (which is the missing feature that has prompted this PR) without losing our coverage of this edge case where legitimately no-one is on support. Apart from being more "defensive", the other benefit would be that we wouldn't have to change the janus data format, since the period would still be there as a maximum length.
Let's chat about what you think, it'd certainly be good to address this common use case more conveniently. Thank you!
The support rota has a concept of a support duration, which is strictly unnecessary as the structure of the rota can determine the length of a support slot. It would simplify things if we got rid of it.
There is also a more concrete issue with allowing exceptional entries to be slotted into the rota. Our current methods for changing support engineers mid-shift, in cases of illness or non-availability, don't work very well. This is the motivation for making this change. For context, see issue https://github.com/guardian/janus/issues/1965 and a recent discussion in the 247 general channel.
With this change, if I add, for example, a two-day slot in the middle of a standard support period this will be reflected in the support page and in the support functionality. So current, next and future slots work as an observer would expect from inspection of the support rota.
The risk is that the rota becomes jumbled and exceptions become the norm.
To mitigate against that we will keep a modified form of the current test that ensures slots begin on Tuesdays but allow an 'imminent' period in which slots can be more flexible.
Tested locally and Janus data ingestion works with and without a support duration.
Support page and functionality is unchanged.