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.

Since there doesn't appear to be a way to reproduce this at HEAD, we can't move forward.

Ipsilon support would almost certainly take the form of an auth adapter. Phabricator auth adapters are not restricted to OAuth2: they include LDAP, username/password, OAuth1, and Persona (and T814 has examples that include HTTP Basic / Kerberos-via-HTTP Basic).

Community Resources has some other working examples of auth extensions and Adding New Classes explains how to write them today. But there's no formal support until T5055 / T5447.

We aren't interested in maintaining this since we haven't seen other interest in it, but feel free to add it to Community Resources.

I spent pretty much the whole afternoon yesterday getting "All Day" events working properly without getting a result I was happy with (some of this was untangling date controls, which will probably come upstream eventually).

This isn't a bug. List HTTP and HTTPS if you want to use these protocols.

Ohhh, sorry, I missed that this is a service call thing rather than a redirect/workflow thing.

You could write a CustomField that was hidden and had some static prefilled value for each form, but I think you might have some amount of trouble getting the UX to work well after the task was created (e.g., you can put some "link back to the thing you came from" in the properties, but not easily render a banner at the top of the page with an obvious "continue" button, nor easily detect that the user just created the object and seamlessly redirect).

Some general sorts of thoughts:

My test data is pretty sketchy:

Ah, fair enough. Two options it is, then.