People in our org love workboards as a way to freely organize tasks within a project. It would be awesome to have personal workboards as well. Conceptually, I think it would work exactly as the project workboards.
Description
Status | Assigned | Task | ||
---|---|---|---|---|
Open | None | T5793 Add support for personal workboards | ||
Resolved | epriestley | T4807 Workboards should support alternate ordering rules, including "don't keep arranged by anything" | ||
Resolved | epriestley | T5476 Move workboard relationships to a dedicated (non-edge) table | ||
Resolved | btrahan | T5245 Migrate Maniphest Projects to use edge infrastructure |
Event Timeline
We're generalizing workboards a bit anyway (with an eye on both workboards-containing-objects-other-than-tasks and workboards-for-objects-other-than-projects) and might end up here, but if we do I think it will be after the core product works better.
This also gets complicated quickly if users want more than one personal board.
I'm not sure this feature would require support of multiple workboards. The fact projects support only one is actually a good thing IMO as it prevents over-organization at the detriment of actually working on stuff.
What if the "flags" app had a workboard and you could manage your flagged issues as if you had a personal project. /a crazy thought.
I would think that the personal tasks feature could/would be implemented with this feature so if we would treat flags as the way to add tasks to workboards I would think that some overlapping would take place.
After T7849 (in review), there's a sort of kludgey workaround for this that has some caveats but should get you 90% of the way there:
- Create an "epriestley's Workboard" project. This project will house your personal workboard. You can call it whatever you want (for example, you could use your own name instead of mine, although mine is a perfectly fine name too.)
- Write two Herald rules (at least for now, these must be "Global" rules):
- When [Assignee][is any of][epriestley] take actions [add projects][epriestley's workboard]
- When [Assignee][is not any of][epriestley] take actions [remove projects][epriestley's workboard]
This isn't super clean, but should more or less provide a personal workboard. It is more flexible than a real personal workboard would be, because you can add more rules and have several boards if you want.
If anyone does this, I'd be interested in feedback on how it goes. In particular, did you stick with one board or end up using more than one?
Implementing this in a "real" way is complex and I'm not convinced that no one will ever want multiple personal workboards, so I'm hesitant to commit to a one-to-one model, but a one-to-many model is even more complex.
I'm trying to use this, but having a conflict with another Herald rule.
In our workflow, we have a custom status 'Open, ready for testing' and a Herald rule that auto-assigns tasks in this status to our QA department (i.e. Jeff). This part works fine ... when i put the task in this status it correctly gets reassigned, however the '[Assignee][is not any of][me]' rule is not triggered. If I manually reassign the task to someone else, the task is correctly removed from my personal workboard.
I could make this work by modifying the 'assignee is not me' rule to include a trigger based on our 'ready for testing' status ... but it'd be nice to allow these rules to work off of each other.
For T5214 / T12074, I am moving forward with an API query model where columns are associated with another, different object as a boardPHID (currently, always a project), and boards do not have their own objects or PHIDs.
I also expect to introduce API methods for workboards into the project namespace, e.g. likely as project.column.search.
These decisions make this feature (personal workboards) less likely. If we do implement in the future, they mean it will almost certainly be in the form of allowing particular projects to act as "personal projects" and automatically acting like assigned tasks are tagged with a user's personal project.
I think this implementation is likely the one we would have pursued anyway -- since we get multiple board support, subproject support, milestone support, etc.