Details
Details
- Reviewers
- None
- Group Reviewers
O1: Blessed Committers - Maniphest Tasks
- T16064: New Column Trigger: Assign only unassigned tasks on move
- Go to a project workboard like http://phorge.localhost/project/board/1/ and define a second column
- On the non-default column, click the Cogs button in its column header and select "New Trigger..."
- Set some random trigger name
- In the Rules condition dropdown, select new "Assign unowned task to"
- In the Rules condition value field, either set a user account (or write/select "viewer()" or "Current Viewer" if D25991 applied)
- Click "Create Trigger"
- Move tasks (both assigned and unassigned) into the column with the trigger, see preview in bottom right workboard corner, see that the card assignee avatar becomes the current user only when previously unassigned; open the task and see the timeline entry that the assignee was changed to the current user in case of previously unassigned tasks
- Edit the trigger to include a second action (e.g. Change Priority); still works as expected
- Move task back to previous column without trigger on workboard; no assignee changes
- On the non-default column, click the Pencil button in its column header and select "Bulk Edit Tasks..."; in the Bulk Editor, under Bulk Edit Actions, see that no new option "Assign unowned task to" exists, as expected as this is only affects workboard triggers
Diff Detail
Diff Detail
- Repository
- rP Phorge
- Branch
- T16064triggerUnassignedOnly (branched from master)
- Lint
Lint Warnings Severity Location Code Message Warning src/applications/project/trigger/PhabricatorProjectTriggerManiphestOwnerRule.php:3 XHP87 Class Not `abstract` Or `final` - Unit
Tests Passed - Build Status
Buildable 1976 Build 1976: arc lint + arc unit
Event Timeline
Comment Actions
What's the expectation for classes which have a child class extending them? Marking them as abstract though they are really not abstract at all? protected class? Uhm.
Comment Actions
I wonder if we should just extend PhabricatorProjectTriggerRule. So, leaving PhabricatorProjectTriggerManiphestOwnerRule as-is 🤔 any opinion about that?
Comment Actions
That was my patch initially but it felt like too much duplicated code... I don't have a strong opinion though; I'm also fine with that other approach. :)