Filtering: Filtering for 'servicebelofte'

[jaccobrouwer]

As a coordinator it would be helpful to have aan option in which you can generate an overview, or even better, get a notification of reports that run out of their 'servicebelofte' timeframe. So for example, if the 'servicebelofte'. is 14 days, you'll receive a (optional) notification when the that timeframe is about the exceed from the day the report was generated or you can set a filter which shows you all reports the are about the exceed their tmeframe

[jaccobrouwer]

Related to this issue: Hoe gaan we om met veranderingen die invloed hebben op de servicebelofte? Bijvoorbeeld een melding die wijzigt en daardoor in een andere categorie terecht komt met een andere servicebelofte dan de initiële.

[tcoenen]

FYI this seems to correspond to ticket SIG-3509 "Filter op afhandeltermijn" in Amsterdam. I will link the PR + documentation for this feature when it becomes available.

[tcoenen]

As promised the proposed implementation for Amsterdam: https://github.com/Amsterdam/signals/pull/728/files

[tcoenen]

Below some Dutch documentation explaining the implementation choices for PR 728.

Filteren op afhandel termijn

Bij de implementatie van JIRA ticket SIG-3509 zijn een aantal implementatie keuzes gemaakt die hieronder beschreven staan.

De wens

Het is handig om te kunnen zien welke meldingen nog niet volledig zijn afgehandeld terwijl de afhandeltermijn al verstreken is. Deze filter moet de volgende dingen tonen

• Alle meldingen (komt neer op niet filteren)
• Buiten afhandeltermijn
• 3x buiten afhandeltermijn

Implementatie keuzes

• Een dag is 24 uur, hetzelfde geldt voor een werkdag.
• Werkdagen zijn maandag tot en met vrijdag, met feestdagen wordt geen rekening gehouden.
• Na iedere categorie wijziging worden de dan geldige Service Level Agreement (SLA) gebruikt om de afhandel deadlines uit te rekenen. Bij iedere categorie wijziging wordt het moment van melden gebruikt.
• De deadlines zijn een eigenschap van de melding, maar omdat ze bij iedere categorie wijziging worden uitgerekend zijn ze beschikbaar onder het "category" veld. Oude deadlines worden op deze manier ook vastgehouden in de database, zelfs als de SLA worden veranderd.
• Als een SLA verandert voor een categorie worden de afhandel deadlines niet automatisch overnieuw uitgerekend. Alleen nieuwe meldingen of meldingen waarvan de categorie gewijzigd worden pikken de nieuwe SLA op.
• Voor deelmeldingen worden ook deadlines uitgerekend en bij die berekening wordt het moment van melden van de deelmelding gebruikt (niet het moment van melden van de hoofdmelding).
• Voor historische data worden geen deadlines uitgerekend. Deze meldingen zijn te herkennen aan "deadline" en "deadline_factor_3" die op null staan. We rekenen geen deadlines uit voor historische data omdat niet alle vereiste gegevens aanwezig zijn.
• Als een melding gemaakt wordt in een categorie waar geen Service Level Agreement voor is vastgesteld, dan kan er geen deadline worden uitgerekend. De waarde van "deadline" en "deadline_factor_3" staan dan op null.
• Bij het uitrekenen van drie keer de afhandeltermijn wordt rekening gehouden met niet-werkdagen in weekends (als de servicebelofte in werkdagen gegeven is). Als een melding in het weekend binnenkomt betekent dat dat de klok pas gaat lopen op maandag nacht om 00:00 uur.
• Er is een filter punctuality beschikbaar die op deadlines kan filteren. Die filter accepteert één van de volgende waarden: "null" voor alle meldingen die open staan en geen deadline hebben, "on_time" voor meldingen die open staan en die nog binnen de afhandeltermijn zijn, "late" voor meldingen die open staan en uit de afhandeltermijn zijn gelopen, en "late_factor_3" voor meldingen die uit drie maal de afhandel termijn zijn gelopen. Meldingen die worden gevonden met "late_factor_3" zullen ook allemaal gevonden worden met "late".

[someren]

Is gerealiseerd