FWIW, I've pretty much never looked at "Open Revisions Affecting These Files", and only look at "Local Commits" to check if the parent commit is already pushed.

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.

Thanks for the guidance. The exact UI is a minor detail. I'm pretty happy to contribute towards either of your leading contenders (and don't like either of the possible contenders much). But as you say, that's not going to become an issue until a little while down the track.

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.

Thanks a lot for putting your time into replying to my comments. I am thinking squarely in the context of T6027, and was looking primarily at the bullet points here as a stepping stone towards that. i.e.

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.

Are workboards 'un-beta' now, and stable enough for it to be worth putting some work into this? I can't promise to have time, but I'm certainly interested in having a look at this.

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).

@epriestley, I'm not sure if/when I'll have time, but would a patch for this along the lines of my previous comment be considered? I'm conscious it must be forward-looking to T5474, and might take a few attempts for me to get up to standard. If the core team can review/guide me, I'm certainly willing to give it a go as time permits.

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.

Thanks @CamilleBouliere we have a requirement to provide FR translations in our organization, so this was invaluable. I hope it is eventually incorporated upsteam!

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.

Thanks @chad, that worked great. I added applying the patch to our deployment script for phabricator. Much appreciated.

• 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.

I think the remaining part was "show a lot more versions of different things", but I can't immediately think of cases where that would have helped us resolve something faster.

See also T8660 for another discussion about searching open and closed documents.

Resolved?

CORGI will fix this and clearly it is too hard for me.

Nothing seems actionable here, closing.

See T10569#164546 also. We're tracking this in multiple tasks, probably don't need a third.

(2b) right now when doing a search, we see a ton of closed items (since the default is to show closed and open docs) which makes this UI inefficent to navigate and annoying to always have to check "Open" after realizing this (some folks don't even discover they can do this). It seems like searching open docs only is a much more common use case (you could verify via some surveying or talking with other folks, but I can't think of many use cases for normal users that care about closed docs more than a small % of the time), so I would recommend considering defaulting to open documents for convenience.

apologies ahead of time as I know each item below probably should be its own task, but feel free to separate as you deem fit.

Yep, that worked. Thanks.

That one worked OK, yell if you're still seeing an issue?

Test: User Guide: Prototype Applications

Oh -- I misunderstood. The issue isn't that we're getting invalid markup or emitting markup in a text context, but that the link is relative.

This is probably very easy to fix, let me spend 3 seconds on it.

Yes, Phurl provides URL shortening. U10 is the root object providing ((prototype)).

Yeaaah, I would assume this worked for free with Remarkup, but I guess not. Yeah it's Phurl,

So this actually in Phurl (not clear from the link) and not valid itself because Phurl is a prototype?

Phurl is a prototype, too.

@epriestley @chad I just synced w/my team after doing a bit more research. There are a few items here - apologies ahead of time as I know each item below probably should be its own task, but feel free to separate as you deem fit.

See Prototype.

It's expected, and I'm not convinced the work to reduce that to one email is viable or worth attempting to solve. That is, you may have rules set up to already handle this in your email client (like to move "reviews" to a separate folder). Doing magical things server side leads to likely user confusion and additional support work in the upstream. Personally, I understand I get two emails, but I also maintain two threads with history in my inbox. Having a new email that isn't threaded to either or just one, would be problematic.

I just remembered another similar scenario for which this happens frequently. If someone creates a new revision for a task I'm subscribed to and simultaneously adds me as a reviewer, I'll get two emails about it.

The technically-functional-prototype code is live on this install, now: