[Kingston] [WW] Escalations and target dates #5787
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## master #5787 +/- ##
==========================================
+ Coverage 82.66% 82.96% +0.30%
==========================================
Files 459 459
Lines 35850 37103 +1253
Branches 5854 6084 +230
==========================================
+ Hits 29634 30782 +1148
- Misses 4510 4605 +95
- Partials 1706 1716 +10 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
struan
force-pushed
the
5258-kingston-escalation
branch
6 times, most recently
from
868420f to
5f6b54a
Compare
struan
changed the title
struan
force-pushed
the
5258-kingston-escalation
branch
2 times, most recently
from
85f67cc to
d94b53a
Compare
|
(Question aside not to do with these changes for @sallytay here - as Kingston asked us to add the specific dates here (which we'd refused to do for Sutton previously when they tried to just shoehorn it in), do we want to have this for Sutton now as well given we've done the work - I'm guessing so?) |
|
@dracos yes, this time it was included in the quote and we said we do it for Sutton too at the same time |
|
Something more to be done on this ticket then, not sure that was known by @struan (hopefully Kingston/Sutton can share the changes to the template for displaying the target dates, so not a big change). I can probably look at this next week if @struan is on something else and it's not as simple as I hope. |
|
I've added in target dates for Sutton. I've assumed that the target days are the same for both of them: Container delivery escalation: 5 working days |
Now that Kingston are using escalations move the escalation code out of the Sutton cobrand and into the shared Role
This is used by the escalation code to check if there's an existing event that could be escalated
This currently assumes everthings works the same as Sutton
Kingston and Sutton have different container escalation windows so move the configuration for the window to a function in the Cobrand
Update waste_escalation_window to be more flexible so all the escalation data is in one place.
struan
force-pushed
the
5258-kingston-escalation
branch
from
8c2daa2 to
239efb6
Compare
chrismytton
left a comment
chrismytton
left a comment
There was a problem hiding this comment.
Looks good! Just a minor question about SLAs and one comment update suggestion.
| missed => 2, | ||
| missed_escalation => 1, | ||
| missed_bulky => 2, | ||
| missed_bulky_escalation => 1, |
There was a problem hiding this comment.
Should this be 2 days, as per your comment?
| missed => 2, | ||
| missed_escalation => 1, | ||
| missed_bulky => 2, | ||
| missed_bulky_escalation => 1, |
There was a problem hiding this comment.
And here, should this be 2 days?
| Sutton has custom behaviour to allow escalation of unresolved missed collections | ||
| or container requests. |
There was a problem hiding this comment.
Might be worth updating this comment, to avoid confusing future readers.
Fixes mysociety/societyworks#5257
Update Kingson Echo integration to support escalations and target dates.
The escalations code is much the same as Sutton, so the code for that has been hoisted up into the shared role, with a few configuration functions to cover differences in timelines.
This also adds target dates for Kingston to enable specific dates to be displayed on the bin page for things like container delivers, missed bin resolutions etc rather than "within n days".
[skip changelog]