Hi,
Is there an option for date: under a target to have the targets being weekly instead of all time or monthly (by using reported and now)?
Hi @magp18
Unfortunately, there is no way to change targets to not be monthly or all time.
That said, there’s an issue that might end up also implementing this feature: Support additional reporting periods: DHIS2 & Supervisor Targets · Issue #6797 · medic/cht-core · GitHub - I know this issue refers to DHIS2 integration, targets are how DHIS2 integration is achieved in the background. The most complete implementation of this issue will introduce configurable reporting periods for targets.
There was an attempt to schedule it earlier this year, but due to the increased complexity, a workaround for the requesting project was preferred.
1 Like
Many thanks for the prompt reply. Would love to see this feature implemented:)
In the documentation, it says that you can also use function(contact, report) for the date property.
Does this mean you could have a function that only selects documents for the current week?
If so, I can imagine it might actually display to the user correctly (ie weekly) but the underlying target document would be misleading since they are month-based.
We’ve implemented ‘weekly’ targets through code (seen below). However, CHWs have experienced inconsistent target count resetting.
Could caching be playing a role? Skimming through the Implications of Task Cache Expiration forum thread, it appears that targets are recalculated in two cases:
- When a contact changes.
- Cache expiry after 7 days
Perhaps they are also recalculated when a new month rolls over?
On Sunday evening we created items to increment the counts on all our targets. However, this Monday morning, all targets still displayed “1” despite the week having rolled over - even after logging out and back in:
We then edited the dwelling (item counted in top left), and the count reset to what we expected:
When editing the household, its report counts also reset as expected:
On what day does the 7-day cache expiry countdown start?
Is there a more user-friendly way to force recalculation?
Would supplying a date function make the target behave differently or trigger recalculation?
Dwelling weekly target:
{
id: 'dwelling-registrations-weekly',
icon: 'wcg-dwelling',
translation_key: 'targets.dwelling.registration.weekly.count.title',
type: 'count',
goal: -1,
date: 'reported',
appliesTo: 'contacts',
appliesToType: ['dwelling'],
context: 'user.role === "chw" || user.contact_type === "chw"',
appliesIf: passthrough(
({ contact: { reported_date, visit_date } }) =>
visit_date ? isISOWithinWeek(visit_date) : isMilliWithinWeek(reported_date),
['Target: ', '[Weekly] Dwelling registration'],
['Reported date:', ({ contact: { reported_date } }) => reported_date],
['Visit date:', ({ contact: { visit_date } }) => visit_date]
)
},
Target extras Weekly exports:
isISOWithinWeek: (isoString) => isISOwithin('week', isoString),
isMilliWithinWeek: (milliseconds) => isMilliWithin('week', milliseconds),
Date calc methods:
function isWithin(unit, luxonDateTime) {
const now = luxon.DateTime.now();
const contains = luxon.Interval.fromDateTimes(now.startOf(unit), now.endOf(unit)).contains(luxonDateTime);
return contains;
}
function isISOwithin(unit, isoString){
return isWithin(unit, luxon.DateTime.fromISO(isoString));
}
function isMilliWithin(unit, milliseconds){
return isWithin(unit, luxon.DateTime.fromMillis(milliseconds));
}
Hi @Anro
I’m not sure how you enabled weekly targets, so it’s hard for me to assess what might go wrong.
We have recently made changes to the engine that does this calculation, and I am not sure you are on the most recent code. You should be if you intend to make code changes, as the overhaul was significant.
In terms of calculations, previous to 4.14, targets were calculated when:
- the user visited the targets page
- the user visited the tasks page
Targets only get recalculated for contacts that require it, and these contacts are:
- ones for which calculations never ran (new contacts)
- ones that have been edited since last calculation
- ones that have new/edited/deleted reports since last calculation
- ones that have not been calculated for more than 7 days
Post 4.14, targets get recalculated each time any of the events above happen, so we don’t “wait” for the user to visit the pages, and the recalculation happens in the background.
Hi @diana,
Currently we’re on version 4.3.x. We made no core code changes with regards to the targets, we simply tried to enforce a weekly increment/reset through the appliesIf in target.js config (as seen above).
I, naively, thought that by keeping the date: 'reported' (which reduces the evaluated data to this month) and by only incrementing the count if the evaluated item falls within the current week (by checking if the luxon interval contains the reported_date), the targets would automatically reset when the new week rolled over. Did not account for the cache. Interestingly, it worked in our tests when we manually changed the dates.
Since our CHWs don’t necessarily treat the same patients every week, which would trigger a recalculation, the targets don’t reflect as anticipated.
If I understood the explanation correctly, our implementation of weekly targets won’t work regardless of the version of CHT - unless there’s a way to ensure the cache expiry occurs every Sunday evening?
Do you perhaps know a way around this?
Do you perhaps know a way around this?
There is currently no way around this, unfortunately.
Additionally, the target emissions that get counted are included/excluded based on their calendar month. So if your interval month ends on a wednesday, you will never have access to emissions from tuesday.
I don’t believe you will find a complete workaround to have functional weekly targets without some significant code changes in the CHT.