We don't currently have a sortable column on the unit message table, since pass, fail, etc., aren't naturally sortable by any key MySQL can construct.

This is probably not a true race in the strict technical sense, I suspect you can reproduce it by doing one of these at walking speed:

I think it's very unlikely that we'll ever write some kind of script to just fix this stuff. I suspect such a script is impossible to write (i.e., the "correct" value for most fields is ambiguous) and that maintaining it is very difficult.

I don't particularly love ASIDE as the trigger, maybe MEMO is a little better? But it doesn't really capture the intent particularly well, I think.

I think this option would very rarely see use, and @avivey's suggestion (arc browse D1234 + use web UI) is a pretty good workaround.

T7789 has some discussion, but there's now a clear pathway forward here which doesn't require anything too drastic. Specifically:

I added you to Community so you should have task edit powers now.

Whoops, thanks. This got rebased across 200 years of changes and I didn't re-test creating a credential. D15512 should fix it.

"Is merge commit" detects this.

See T5726, T10363.

just convinced that Phab search didn't work and feeling powerless over it

See also T4103.

CircleCI fixed build_parameters in their API so support is now in HEAD of master. There's probably some remaining work but it seems to work properly locally. Let us know if you run into issues with it.

Sounds like this is resolved one way or the other. In the general case, "Another Herald rule" effectively allows you to group, negate, and combine conditions in addition to reusing/including them.

You can use two rules:

This should be fixed in HEAD of master. Let us know if you're still seeing issues after updating. Thanks for the report!

I think this should be fixed in HEAD, let us know if you're still seeing it after updating. Thanks for the report!

This is already documented, do you have any suggestions for improving the existing documentation?

Yeah, I think changing text size inline often tends to look pretty bad since line heights get all messed up, too.

Note that you can do this today:

We're planning to do this at some point:

Do you have some examples of things you'd like to use this for?

Yeah -- it's not very clear on its own, but this comment is specifically referring to that issue:

Closing this in favor of followups.

We are vanishingly unlikely to pursue this naturally. It is very complex and we do not consider it valuable. We have never seen similar requests from other installs, and this UI seems far worse for most users because it makes discovery difficult.

We can resolve this by parsing the query and rewriting the query we submit to the engine as "+x +y" if ft_boolean_syntax has not been adjusted.

These fields don't apply to other document types, and other document types have other fields which do apply to these results. It does not make sense to search all documents by, e.g., "Priorities". We definitely aren't going to pursue this as described.

T10486 is related; T6027 and T5214 are somewhat related.

T7190 has discussion of a similar case.

I think this isn't tremendously important for Countdown but should definitely be sorted out before we unbeta Calendar.

It might not be bad to always show timezones in email explicitly to deal with cases related to T3025 better (e.g., you fly to the east coast for a conference, get prompted to reconcile your timezone after T3025, and it may not be obvious that this also affects mail you receive until you return and re-reconicle back to PST).

With metamta.one-mail-per-recipient on, we can adjust this to the viewer's preferences.

I also may just restore this at some point to align with user expectation, even though I think it's a bad feature and we benefited on the balance from removing it.

T1258 might be another attack on this, not sure how much that overlaps things.

We have a large, and growing, set of teams that would like to get CCed whenever a review is created in a repository they work in.

Yeah, pretty much the same for me. I believe "Open Revisions" has a small population of fans and "Local Commits" may get more useful eventually (e.g., after whatever happens with T1508) but I think we're on fairly firm ground shoving these into tabs.

I spent some time on this, but this ends up being more involved than I thought because there's a lot of weirdness around how actions and property lists interact, so this is probably blocked on making all UIs which use property list tabs and actions switch to the two column view.

To provide some context, until recently, the API was in bad shape. Basically, the first time we wrote an application we'd maybe write some application.whatever methods, which shared some code with the rest of the application but not all of it, and then the API and application wouldn't always get changed in the same way. This resulted in methods like repository.create which can do maybe 20% of what the web UI can, does it in different, inconsistent ways, and edits made by the API might look or work differently than web UI edits. In bad cases, they'd even do different policy/permissions checks. This caused many many problems for a very long time.

Changes like T10569 should probably happen first. This is likely to be very complex, and is probably not a good task for a new contributor.

This request doesn't describe a root problem and we don't seem to be making progress toward one, so we can't move forward on it.

No, we're not open to implementing this as multiple separate select controls. We don't really have a UI in mind that we're happy with, but we have several we're less unhappy with than multiple select controls (leading contenders: single optgrouped select, alternate actions menu for workboard actions; possible contenders: visual table-layout control, select per-project in a dialog).

How do you imagine Phabricator learning about the existence of new external groups? Just polling a list of every group in LDAP every hour or whatever?

Like T10622, I think this is reasonable to expose as an extensible behavior, but it should wait for T10329 so we have better tools to support it.

I think this is generally reasonable but would like it to happen after T10329 (roughly, "proper extension infrastructure for arc"), when we'll have the tools we need to better manage versioning and deploying client changes.

Can you describe the root problem? What kind of rules are these? Revision rules?

You can already do some of this: "Land Revision" itself is added to the menu via DifferentialLandingActionMenuEventListener. You can use listeners like this to extend the menu.

I've updated D14284 + D14286 + D14288 for the new API and rebased them onto modern code.

It seems that tag builds do not support build_parameters. We need to pass parameters, so this is blocked on them again.

• Once D15499 lands, this is available as a prototype.

According to CircleCI this really truly works now, so I'll see if I can push our integration forward shortly.

I renewed the certificate and launched a new VPC load balancer, which can forward port 22 traffic:

We use secure.phabricator.com for both HTTP/HTTPS and SSH traffic and ELB can't currently forward port 22 -- except the docs now say EC2-VPC LBs can? So I need to figure out what's going on with that.