Pile more atrocities onto the Maniphest burnup report
cb957f8d6242
Actions

Description

Pile more atrocities onto the Maniphest burnup report

Summary:
See PHI273. Ref T13020. After D18777, tasks created directly into the default status (which is common) via the web UI no longer write a "status" transaction.

This is consistent with other applications, and consistent with the API/email behavior for tasks since early 2016. It also improves the consistency of reading tasks via the API.

However, it impacted the "Burnup Report" which relies on directly reading these rows to detect task creation. Until this is fixed properly (T1562), synthetically generate the "missing" transactions which this page expects by looking at task creation dates instead.

Specifically, we:

Generate a fake status: null -> "open" transaction for every task by looking at the Task table.
Go through the transaction list and remove all the legacy status: null -> "any open status" transactions. These will only exist for older tasks.
Merge all our new fake transactions into the list of transactions.
Continue on as though nothing happened, letting the rendering code continue to operate on legacy-looking data.

I think this will slightly miscount tasks which were created directly into a closed status, but this is very rare, and does not significantly impact the accuracy of this report relative to other known issues (notably, merging closed tasks).

This will also get the wrong result if the default status has changed from an "open" status to a "closed" status at any point, but this is exceptionally bizarre/rare.

Ultimately, T1562 will let us delete all this stuff and disavow its existence.

Test Plan:

Created some tasks, loaded burnup before/after this patch.
My local chart looks more accurate afterwards, but the data is super weird (I used bin/lipsum to create a huge number of tasks a couple months ago). I'll vet this on secure, which has more reasonable data.

Here's my local chart: