Apr 1 2022
Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.
Mar 31 2022
Mar 29 2022
epriestley was very much against this idea but wikimedia's users loved it.
Mar 25 2022
Nov 29 2021
Nov 27 2021
I didn't know columns could be deleted... I thought they were only ever hidden.
Sep 22 2021
Expressing the desired behavior here seems difficult to fit into Herald.
- Level: Global
- Trigger: When a task's status is changed
- Action: Move the task to a different column X on project Y
Sep 17 2021
The Herald rule should be project specific. If X happens then move task to Project->Column
Sep 15 2021
Sep 14 2021
Sep 13 2021
Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.
Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.
Sep 10 2021
@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.
Just having a dropdown here would be enough, I guess?
Should we limit it to one column per type for each workboard?
A column type would be a new entity, I guess? How do we create a new column type? Or is a type just something we can configure in the Config application, like task statuses?
Sep 9 2021
It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.
Sep 8 2021
I started to implement this as a new herald action. There is just one major problem. I would have to load all columns from every project and present them to the user. A user could then select one specific column of one specific project for his herald action... This seems kind of pointless to me. It's way too specific to be usable.
Sep 5 2021
I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?
Sep 4 2021
I agree with @CSharp that option 3 is probably the best approach here. It looks like on https://secure.phabricator.com/T6409 the initial request was that items get automatically moved based on state change and the main pushback is against the design of an approach like 1 or 2. I think setting this up utilizing Herald makes sense though. I wasn't aware that triggers/transactions weren't fired from both locations though. That might be a bit involved.