Tasks deadline reporting
Tasks reporting distinguishes a deadline that was effective at an event from the first deadline recorded for the task. Later edits do not rewrite either an earlier completion result or an earlier overdue episode.
Use the installed Reporting data source catalog to discover and execute the available reports. Page access, permission to use the source, and current Task View access are independent. Historical participation does not grant current access. Opening a linked task checks access again.
Choose the observation
Section titled “Choose the observation”| Question | Observation and selection |
|---|---|
| When did tasks become overdue? | Confirmed episode starts in the selected local-date period. Distinct tasks and episode counts are separate. |
| How were deadlines changed? | Effective changes in the selected period, including post-completion changes unless filtered out. Creation and unchanged values are excluded. |
| Did the first deadline differ from the completion deadline? | The same successful completions, measured independently against both deadlines and on a common subset of comparable pairs. |
| Which unfinished tasks have no deadline? | Current saved values, or independently reconstructed values at an explicit historical instant. |
Periods use inclusive dates in the workspace time zone, converted to a half-open UTC interval. Snapshot instants must carry an explicit offset and cannot be in the future. One execution captures one calculation time. Durations use calendar time and keep their precision until display.
History and unknown values
Section titled “History and unknown values”A task becomes overdue only after its due instant. Completing or moving the deadline exactly at that instant does not create a natural overdue episode. Creation with an already-past deadline starts an episode at creation. Moving a deadline into the past starts one at that command. Moving an already-past deadline to another past instant keeps the same episode.
Removing a deadline, extending it to the command time or later, or completing the task closes the episode. Separate ordered commands at one instant can create a zero-duration episode; one atomic deadline-and-completion command cannot. Command revisions establish ordering. Legacy records require an unambiguous history; arbitrary identifier ordering is not evidence.
Unknown history is explicit. A gap does not fabricate an episode, and recovering an already-past deadline does not prove a new start. A known start with an unknown end remains visible. Queue attribution follows the historical visit; unknown queues are not replaced with the current queue. Completion stops new overdue starts, while the change report can still show later deadline edits.
The first recorded deadline is the first chronological non-null value known by completion, not the smallest date. Removing it does not reset the baseline. Unknown earlier history can make this baseline unknown while later facts still prove the effective completion deadline.
Denominators
Section titled “Denominators”Each deadline basis has its own on-time rate: OnTime / (OnTime + Late). Known absence and unknown history are shown separately. Known absence counts toward history coverage but not toward that rate.
The comparison also reports a common denominator containing only tasks with both deadlines known and present. Its difference is in percentage points and uses those paired rates. Subtracting the two independent rates would compare different populations and is not the paired result. An empty denominator gives an absent result; a measured zero remains zero.
For unfinished work, the percentage without a deadline is Without / (Without + With). Unknown deadline and unknown lifecycle membership remain separate. Unknown assignment does not erase a known deadline. Related worker identifiers and names are returned only when currently accessible.
Pure C# calculations
Section titled “Pure C# calculations”The additive deadline-history surface is available in
Moltaro.Package.NET.Tasks 8.1.0, under
Moltaro.Package.NET.Tasks.Reporting.Deadlines:
TaskDeadlineHistory.Transitionsreturns confirmedTaskOverdueEpisodeobservations andTaskDeadlineHistoryGapdiagnostics through a cut.TaskDeadlineHistory.Changesreturns localTaskDeadlineChangeObservationrecords, independently of an unknown earlier baseline.TaskDeadlineHistory.FirstRecordedreturns aTaskFirstRecordedDeadlinewith knowledge and the recorded instant.TaskDeadlineComparison.Readcompares both bases at proved successful completion.TaskDeadlineComparisonTotals.Calculatecomputes independent and paired counts and rates.
These functions operate on supplied TaskReportingFacts. They do not load a
workspace, enforce authorization, execute commands, or repair history. Use them
for deterministic calculations over facts that the caller is entitled to read.
For workspace reports, use the registered Reporting sources so that SQL access
filtering and protected related-data projection remain in force. Do not load all
tasks and attempt to reproduce authorization in memory.
Use the installation’s delivered developer surface and matching SDK version
when writing C# in the Net Operation Project.
An SDK package version does not change the Tasks automation contract, which
remains 3.0.0 for this additive calculation surface.
Configurable pages
Section titled “Configurable pages”Report sections and dashboard widgets remain ordinary Reporting definitions. Users with editing permission can add, remove, move, and reconfigure widgets. Creating a Tasks report or dashboard supplies its initial configuration; repeating creation opens the existing page without replacing its contents or audience. Existing pages can add new sources through the editor.
Details use stable pagination, normally 50 rows and at most 200. Summaries and percentiles use the entire authorized selection. A chart that exceeds its category limit asks for narrower filters instead of silently truncating data. Source descriptions come from the current catalog, including plain text overrides without localization keys.