Dec 3 2020
That seems reasonable. I also ran into a couple of other suggestions elsewhere:
Off the wall suggestion: how about a trigger that sets the subtype:
Dec 19 2019
See also PHI1594, which wants:
Jul 31 2019
See T13357 for followup.
Jul 24 2019
Jul 17 2019
a logical clock to complement the wall-time clocks
From D20653:
Jul 8 2019
Jul 3 2019
Just thinking out loud:
Jul 2 2019
Here's roughly where I'm headed next. I'm planning to:
The "default" controller currently needs to "force" the URI parameters...
The "filter" controller currently needs to "force" the URI parameters...
The "apply" flow, where a new custom filter is applied...
Jun 29 2019
A couple of weird cases on state management:
May 9 2019
Got it, thanks for clarifying.
It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop). Is this expected / intentional?
It looks like these triggers don't run when you move tasks via "Move on Workboard" (instead of drag and drop).
Apr 13 2019
Apr 10 2019
ah, I missed that. I guess I should start testing this stuff soon :)
well, I'd say for example the "Close as <status> (only acts if task is not already closed)" is useful, and definitely needed.
Move the task to "done" column on the workboard, and the task automatically gets closed. That's handy.
Things feel pretty reasonable to me for now. I'm going to fix those bugs you hit and I think I have a couple other things I wanted to tweak, but I'm largely happy with the featureset as a v1.
Broadly, it's not clear to me that any of these rules are actually good/useful/worth building.
Are these different from the existing implementation in PhabricatorProjectTriggerManiphestStatusRule?
- Close as <status> (only acts if task is not already closed).
- Reopen as <status>.