blob: 383695b900695f6314e57797f9d7c7475916bf8b (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
-- Splits the two jobs `due_date` had been doing at once.
--
-- `due_date` had meant both "this has an externally-imposed deadline" (Bills,
-- meds, a signup cutoff) and "this is when I intend to work on it." Chains
-- leaned entirely on the second reading: every step was stamped due_date = now
-- the moment it unlocked, so a five-minute phone call and a six-month
-- certification both arrived looking overdue, and the only way to quiet them was
-- to hand-reschedule -- which is what had been happening.
--
-- After this, due_date keeps only its first meaning, and committed_date carries
-- the second: "I chose to do this today." The day's list is then a pull of what
-- was committed plus genuine deadlines, rather than a push of everything not
-- blocked -- which is what makes finishing a day at zero possible at all.
ALTER TABLE native_tasks ADD COLUMN committed_date DATE;
-- Chain steps were given their due date by the machinery described above, not by
-- any real deadline, so clear it on open steps. Completed steps keep theirs as
-- historical record.
UPDATE native_tasks
SET due_date = NULL
WHERE completed = 0
AND chain_id IS NOT NULL
AND chain_id != '';
|
