That Herald rule is clever!

First thought is to do this:

Yeah, on further thought I suspect the magical config is just metamta.reply-handler-domain not being set.

Presuming this is resolved because the new feature is a superset of the old feature.

(I don't think we need this to repro anything.)

There's also no actual technical reason that objects legitimately need to have a mailKey at the PhabricatorMailReplyHandler level right now.

I can't actually figure out what configuration avoids this error -- metamta.public-replies on and off both try to call getMailKey() for me.

We are very unlikely to ever support this.

(I pushed this, too.)

I haven't seen this one before. My guess is that it might be because you have display_startup_errors on, and possibly we should detect that and raise an issue for it, although it's sort of good to show these errors somehow.

We aren't interested in supporting IPv6 in the upstream at this time, and don't have the time or resources to help you develop a patch.

Type r and then part of a repository name, like:

This behavior is expected. Cursor values are not intended to be human-editable. The fact that this worked in previous versions was a side effect of how the cursor was implemented at the time, and not an intentional feature.

See also T6403 for a longer-term fix for this.

Let me know if that didn't fix it ^^

I think this is something we'll probably revisit in the long run but it's probably a v2+ type of thing and I'd expect it to be informed by other product decisions between now and then (and possibly by application changes like having meaningful automatic escalation).

I'll see if I can guess what's going on here; otherwise maybe I'll just sneak a look at things the next time I'm over there.

I also confirmed that there are no outstanding "nuisance" invoices for trivial amounts of money.

I pushed this change to the cluster and marked the four $0 invoices we'd previously generated as paid.

We now default to "ignore". It would be nice to add a confirm step eventually.

Specifically, I'd expect these unusual behaviors from these notifications:

My thinking on this is that we literally just send the user a notification, which shows up in the notification menu:

I think adding a "View in Column" button to the Conpherence dropdown menu (and maybe making that menu show a few more items, like 10 instead of 5?) could push the specifics of this out.

I do expect this general class of behavioral stickiness overall, but I'm not sure how valuable sinking the effort in to get all the fine-tuning and details of draft stuff working ahead of other refinements (like showing threads with mentions or new messages) is.

I'd maybe start with this:

"Automate your companies process" should be "Automate your company's process", unless i'm wildly misinterpreting it

Thanks, I'll run this down.

I'm increasingly thinking that T4245 may also make "clone/checkout as" globally unique and allow it to serve as an alternate identifier, too, although that's a little messy.

In prepration for T4245, we should probably be moving this stuff to accept IDs, Rxx, rCALLSIGN or CALLSIGN, and getting the abstractions for that in place if they aren't already.

I like at least trying the last item as a dropdown. There are a couple of other similar "make UI elements work better on mobile by default" things too (T5752) that I sort of want to clean up, but holding these until after the redesign probably makes sense.

Specifically, this was almost certainly fixed by D12401, which is a little more than a month old. If updating Phabricator doesn't resolve this, let us know.

I made the "likely" edits locally without hitting an issue:

Does this reproduce on this install, or only locally? I can't immediately reproduce it.

I think Fixes Txxx (and other closes-when-landed relationships) is strong enough to imply this, but it feels a little unexpected with just ref/mention.

What version of Phabricator are you running? You can find it in Config → All Settings in the web UI. It looks like this:

Another alternative is for this to be a Herald rule... I'm not sure which is more preferable