To summarize discussion from elsewhere: it isn't clear to me when this is better than other tools -- including arc browse D123, which already exists.

Thanks for the extra context!

See T11343 for discussion of automatic "Depends On" detection. Briefly: desirable, but also complicated in the general case.

Clearly we should have a Services starting with "CloudF..." header.

Please read Contributing Feature Requests carefully before filing feature requests. In particular, we need you to describe a root problem (see Describing Root Problems).

@jonah214 said he's using CloudFront (AWS) while that note is about CloudFlare (an unrelated product/company with a nearly identical name) so I'm suspicious there may be more to this than meets the eye (or maybe CloudFront was a typo).

I added you to Community, so you should have sweeping janitorial powers now.

I can't reproduce this. Here's what I did:

Note that you need to bin/storage upgrade after picking up D16312 for this change to take effect. You should normally be doing this anyway, just mentioning it since it's not obvious that this would require database adjustments.

I think arc actually calls differential.getcommitmessage and then passes the result right back to differential.parsecommitmessage to split it into fields. That could/should work differently than it does.

This is desirable, but complicated in the general case. T3875 (and T3875#182020 in particular) has some discussion of a similar identification problem at the other end of the workflow, in arc land.

We can have this render "Tags: PHID-PROJ-abcdef" instead, which is an "improvement".

T8200 describes a somewhat-similar issue.

Well, that sounds scary.

Per above, I'd like to just fix issues here rather than add an automatic compaction process. I don't currently know how to generate un-compact files in modern code.

Presuming this is fixed / irrelevant / not scary / resolved / something since I don't think this went anywhere elese, yell if not or I just forgot something (or we can follow up after T11044 if this is waiting on that),

This appears to be a problem unique to your environment, because we and many other users follow the upgrade steps routinely without encountering this or similar errors. In particular, I can't reproduce it given the information provided.

Not only that but the language has moved away from human-friendly terms like "hosted" vs "non-hosted" to "observe".

They're available in the "points" field of maniphest.search.

I don't think we're really making any headway here. Here are some more actionable followups:

I don't want to continue expanding the existing "mail tags" system in Settings → Email Preferences. See some discussion in T11337.

No problem! We know this is pretty tricky to figure out right now, and plan to make it easier next time we do some work on dashboards.

If you can make the query you want in an application, you can use it in a Dashboard panel by following these steps:

Our problem is that the project panel shows both tags and projects

Oh, or I guess you're listing tasks? In that case, can you execute the query you want from Maniphest (at /maniphest/)?

Can you currently execute the query you want from the main query UI in the Projects application (at /project/)?

What about show only active projects in "Browse projects" window?

We've just been inching our way through this bit-by-bit to address specific use cases and improvements. That approach seems to be working pretty well and we have no plans to turn the whole mail into some fancy graphic thing, so I don't anticipate doing a specific whole-mail HTML redesign. We'll continue making improvements to specific sections.

We don't send from a static address, even in Phacility, since each install sends mail that originates from an install-specific address (@phabricator.mycompany.com or @instance.phacility.com). This is currently a hard requirement for these actions.

Per T7047#180833, no idea what the use case is for per-user/per-Herald/per-Mail.

This is a catch-all task that I don't anticipate us ever taking action on. Building some sort of templating system for mail would require a lot of resources, and using that templating system to accomplish some of the goals described in this task (like "always show associated projects") would not be significantly less complex than just forking.

We haven't seen other interest in this in about two years.

Presuming resolved by T11120 as we haven't seen further reports in more than two years.

I don't see anything we can do about Gmail's behavior here. Use a different client, or ask Google to improve Gmail's behavior.

Presuming resolved by T11120.

@nemobis, I previously warned you about the tone of your interactions with the upstream in T5908#84888.

I think most of this is in reasonable shape now, at least for the moment.