This has been a source of confusion for people on our install as well. I have never made this task myself as I am not sure what is the lesser evil -- having descriptions process remarkup atypically on edit or the current. Maybe some version which has awareness for creation vs edit but that seems fraught with strange implicitness. Anyhoo, wanted to chime in and say this has come up a few times for us as well :)

Unsure if this is a useful thought but one sideways approach could be a syntax that allows project transform with a nice link and color but no association. \#myproj does all the usual but no association vs #myproj which is the standard.

That leaves it in user hands and actually I kind of wish that existed today. It is hard to say, should this issue be for #foo or #bar? at the moment since it links them automatically.

Is the auto-tagging with a project really useful on the balance? Offhand, I'd be OK with removing it completely.

I don't find it super useful, and is confusing if you're new. What about making the mention more specific, like @#guides

Do we need a project mention syntax at all? I'd guess that @#project would see close to zero use if we had it.

When I built project mentions originally, the thinking was roughly:

1. Seems like it might serve as a natural extension of @username (in practice, I don't think it does -- it still doesn't feel natural or expected to me after having a long opportunity to get used to it).
2. In Differential revisions from the CLI, #project is moderately easier than Projects: #project.
3. In inbound mail to create tasks, there's currently no alternative to #project.

For me, at least, (1) doesn't feel good; I've never used (2), and putting projects in the "Projects:" field doesn't seem like a big deal; and I've never used (3) and I think Herald + T5952 is probably a better approach in general (let installs define multiple mail addresses, and write Herald rules based on which one mail was sent to -- so you could send to iphone-bugs@ vs web-bugs@ or whatever).

I'm fine just killing it, i assumed others really wanted it.

IIRC, the email use case saw some interest from users (not sure it really got picked up though) but I haven't seen much interest in general, I don't think.

We do use the #routetoproject for email intentionally and advertise it. There are certain places scattered about that document how to file a bug for things in this manner. The ability to not orphan a new task on creation from email is much appreciated by folks i think at the moment. It also allows multiple projects(?). That doesn't imply affection for any particular syntax or anything. The primary use case for us is essentially a homebrew T5952 where an email sent to peanuts@ can cause the email to receive an appended #peanuts to the body and have the dest rewritten as task@. This bridges the gap for some legacy systems folded in especially.

I will say having #pizza not do association and ##pizza create an association (or whatever syntax) would be nice still. We do use the behavior really frequently and to great effect. But I am sure that has non-zero cost to maintain.

I think the least that should be done here is to make the behavior in descriptions equal to the behavior in comments. If a user mentions a project in a comment, it is automatically associated to the task, but if you remove the project manually, it is not added automatically again. Mentions in task descriptions will always bring the project back, which really confuses and annoys users.

About the feature altogether... I would keep the mentions (I think users like the rendering with the visible button and the link to the project page), but I would remove the automatic association, which indeed causes enough confusion. Associating a task to a project should be a conscious, explicit decision.

Tentatively, let's do this?

• Do T5952 (multiple addresses, Herald support for inbound addresses).
• Remove project-mention-implies-association from all contexts.
• If we get pushback from installs (and the new stuff in T5952 isn't satisfactory as a replacement), we can build a ## or @# or +# or something syntax.

The specific case of the description is probably most easily dealt with by not extracting mentions if the text doesn't change. This would incorrectly re-associate a ##/@#/+# project on a trivial/unrelated edit to the description, but that case seems very unlikely to be a common one.

With subscribers, we have a significantly more complicated system which tracks implicit vs explicit CCs and remembers "unsubscription". I'd like to avoid adding this level of complexity to the project stuff if we can.

Seems like a reasonable approach to me fwiw :)

In T6819#88767, @epriestley wrote:

1. In inbound mail to create tasks, there's currently no alternative to #project.

For me, at least, (1) doesn't feel good; I've never used (2), and putting projects in the "Projects:" field doesn't seem like a big deal; and I've never used (3)

FWIW we did 3. When you fail node from one of our compute clusters due to a hardware failure it send an email that uses this syntax to associate it with the right projects. It works pretty nice. I think it's all portable to T5952 & T5039.

Ah, okay, yeah. Assuming there's a fairly small set of valid projects in the hardware failure scope, you should be able to add a hardware-failure@ address, and you can use Herald rules that match #project in the body content to make those continue to work like they used to.

If there are like 100 possible projects that the cluster might add, that could be a huge pain; feel free to file a followup request. The auto-associations just seemed to be a solution in search of a problem for the most part, and causing some degree of collateral damage.

The originally reported bug was (roughly) "associating projects via mentions when editing a task is annoying." I agree that this is annoying when editing a task -- but I view it as a crucial feature when creating a new task.

Why not keep the association code, but gate it with if ($this->getIsNewObject())? Something like this: https://secure.phabricator.com/differential/diff/28160/

Can you explain why it's a crucial feature when creating a new task? Particularly, the field immediately above the description allows you to add projects on this workflow, and has a typeahead. Do you have an unusual workflow? Does the typeahead not work well for you? Have you made local changes which alter how this workflow behaves?

In T7187, you mention task creation via email, where obviously this field isn't present. Are the approaches described here and in T5039 insufficient? In particular, does the automated system create tasks with a very large number of different project tags?

We imagine that most use cases are satisfied by defining a new x-service-failure@ address, having the system send to that address, and then using Herald to add projects and otherwise route the request. This only seems worse if the systems are capable of adding a large number of configurations of different tags, which would be hard to express as a small number of addresses + rules.

We're open to adding an explicit "associate this project" syntax, we'd just like to know that there are use cases for it where the problem complexity makes service addresses insufficient.

I wouldn't want to make the decision based on isNewObject because if a description is edited and an association-mention is added, I think that should trigger the association.

It's not particularly difficult for us to add a syntax and fix this behavior, but all uses of the old syntax we are presently aware of were either undesirable or automated system email that's easily expressed with the new address stuff. Is your setup complex enough that re-expressing it is unreasonably cumbersome?

Our workflow is that we have a tool that automatically files tasks via email. We actually used to route these using Herald (not quite the approach described in T5039 and this task, but something similar -- we'd put key words in the body of the email, and write a Herald rule that assigned projects based on body text) but this quickly became unscalable. Relatively few people in our organization have permissions to create global Herald rules, so that became a bottleneck. It was also difficult to check if a tag from our email system had a corresponding Herald rule or whether we had forgotten to create one. I'd imagine we would face similar problems with routing via multiple email addresses + Herald.

This only seems worse if the systems are capable of adding a large number of configurations of different tags, which would be hard to express as a small number of addresses + rules.

Also this :)

I'd be interested in hearing proposals for other solutions. Maybe a Projects: #project field for creating tasks from inbound emails, as you mentioned earlier? That seems to avoid the problem of what the behavior should be when mentioning a project while editing a task description.

If the only use real use case anyone has for this this is email, maybe we just parse them as suffixes in email subjects, so:

Subject: broken thing #urgent #production #red-colored

...uses "broken thing" as the task title and consumes the rest of the subject as attached projects.

Another possibility might be "associate all mentioned projects" as a Herald action. Then you could write a single rule, like: Source is email, address is not humans@phabricator, take action: associate all mentioned projects, to restore the old behavior for all system-generated email. But this feels pretty meta and likely requires us to fix the root issue here, too, so that we get reasonable behavior if someone writes an "always" rule which takes this action.

Any of those options sound fine. I don't have a good sense of which solution would be the most elegant to build and maintain.

Thinking about this some more, I have most of a diff which expands the existing !claim, etc., actions to be parsed more generally. While they're aimed at replies to existing threads, it's probably cleanest to expand those rather than adding a new idea. That would let stuff like this work:

!assign epriestley
!subscribe #whatever
!projects #urgent #red-colored
!status broken
!priority urgent

System xyz is literally on fire.

This would be consistent with existing email commands and expand to human uses and replies, and not add any new concepts, so I like that best. We do have to come up with some better documentation approaches since inlining all of that in the "Reply handler actions" section of the email is going to get messy, but I think that's the way forward. I'll move this to a separate task.

^^ I dig that.

Thanks @epriestley!

I like the idea of !subscribe, !projects, etc. What's the status of that?

Also: would this apply to tasks created via the maniphest.createtask API call? It would be really convenient to add CCs and projects via !commands in the description field, rather than having to look up their PHIDs and then using the ccPHIDs/projectPHIDs fields.

T7199 is the ticket for that