Page MenuHomePhabricator

Herald unable to place task up for grabs
Closed, ResolvedPublic

Description

At the moment, assigning a task to an empty user doesn't place the task up for grabs, as it does when assigning to an empty user from the maniphest task UI.

Steps to reproduce:

  1. Create new herald rule that assigns to an empty user based on association with a project
  2. Create new maniphest task assigned to yourself
  3. Associate new task with the project, triggering the herald rule
  4. Observe task remains assigned to you

Here's a screenshot of an example:

Then, on the task:

Running a3393c3ecb92753277cd7bf447631ebb510f59ce

Event Timeline

dpaola2 updated the task description. (Show Details)
dpaola2 added a project: Herald.
dpaola2 added a subscriber: dpaola2.

Here's the rule transcript:

epriestley added a subscriber: epriestley.

This behavior is currently expected: this construction means "no effect", not "place up for grabs".

(We interpreted something similar in the batch editor as "place up for grabs" a while ago and got a couple of reports that it was confusing/unintuitive/not discoverable. To avoid that, I want to make "unassign" explicit and discoverable going forward.)

The capability seems reasonable to add. I think there are two general approaches:

  1. Add a separate "Unassign Task" action.
  2. Let the user enter the "None" token into this typeahead (use ManiphestAssigneeDatasource instead of PhabricatorPeopleDatasource).

(1) is a little more straightforward technically, but not consistent with "Batch Edit" and not necessarily as intuitive as making this action available from "Assign Task".

(2) is relatively involved because the "None" token doesn't have a real PHID and parts of the editing and rendering pipelines don't fully pass through the Datasource stuff that they'd need to in order to pick up the rendering. There's also currently no way for a datasource to render plan text flavors of tokens (e.g., the text "No Owner" for the summary line "Assign task to: No Owner"). This is more flexible, general and consistent, but also relatively involved (I poked at it for a few minutes without making much headway).

At some point, we should also:

  • Limit the tokenizer to a single input (there are some TODOs about this in the code).
  • Raise an error in the UI when you try to save a rule with a meaningless action or field (e.g., assign to no targets).

I'd be curious how important it is to the project to maintain UI consistency between Herald and Maniphest. Currently leaving the field blank in Maniphest places the task up for grabs -- wouldn't it be preferable to maintain the same expectations in Herald?

(I may be dense here)

This comment was removed by epriestley.

In the past, the bulk editor worked like this under a similar theory (and or laziness, I don't remember which contributed more), but we had at least one (and maybe a few? I don't recall offhand) user who failed to guess it and didn't even try the interaction in the bulk editor.

I think these contexts aren't quite the same. On the task, all the fields are "set" fields: removing the assignee sets assignee to none. Removing all the subscribers deletes all the subscribers. Removing all the projects deletes all the projects. It's common for fields to be empty when they have no value.

On the bulk editor and Herald, most fields are "add" (or "remove") fields. "Add subscribers: X" means to just add that subscriber, not set the subscribers to that value. There is no "Subscribers:" field, and removing all subscribers wouldn't make much sense. Empty actions generally don't make much sense here. I think it's reasonable for users to come into these UIs with a slightly different mindset, and understandable that "Assign task to: [(blank)]" isn't obvious as an unassign action.

The new behavior of the bulk editor is:

Assign to: [ Type a username or "none"... ]

...which I think is clear, unambiguous, and discoverable.

Excellent point, thanks for clarifying.