This should learn from Auth and support multiple providers of the same type from initial implementation (see T6703).

I think we're going to fix this with T7667 instead. Binding to a particular domain creates headaches if you actually move the LDAP server, and unlocked authentication creates a lot of other problems that we can't address in a similar way.

This is conceptually easy but we have no outstanding requests from customers.

At this point, I don't anticipate this ever coming upstream. This is probably a good candidate for third-party maintenance after T5055.

This doesn't seem to be cropping up terribly often and I think this use case is fairly weak.

Presuming something fixed this.

This might happen eventually, or as a side effect of T7303, but the use case here is pretty narrow and there's currently no customer interest so I don't currently anticipate building it.

There are two flavors of this:

Password management is in good shape after T13043 , and this would now be fairly easy to implement in a general way by adding a check in PhabricatorAuthPasswordEngine->isUniquePassword().

There are probably some stragglers that have yet to turn up, but we appear to have survived this largely unscathed.

In T12145#242682, @joshuaspence wrote:

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

In T12588#242719, @epriestley wrote:

If any of these lists only have one form (or the user can only see one form), we'll take the user directly to the specified form.

When users click "Create Subtask", we now look for a list of possible subtask forms.

This is a great badge!

See D19829 for a followup change: getDetail()/setDetail() should be more-private APIs than they are today, and callers elsewhere (like transaction logic) should use methods like getEncoding(), not getDetail('encoding').

I'm having some trouble getting this new behaviour (which IIUC basically means that multiple hosts in a Drydock pool should be load-balanced across). In "active resources" I see three Drydock hosts, which all belong to the same Almanac service. In "active leases", however, I see only a single host lease and many working copy leases.

Ah, thanks! Yeah, that looks like the same thing. I think the bug title isn't quite correct (runtime is dramatically worse than O(input), but not infinite) and the analysis is slightly misleading (escaping the $ doesn't matter, I think) but the patch looks like it will get the job done (although, offhand, I'm unsure about the ($|(?=")|(?=\$) groups).

FYI, I think this upstream issue with pygments addresses this issue (was open since 2016, but only recently had a commit made to fix it): https://bitbucket.org/birkenfeld/pygments-main/issues/1257/infinite-loops-in-specific-files

Mostly, there's just relatively little interest from paying customers right now. PHI64, PHI675, PHI723 and PHI985 are all somewhat interested, but they're generally low-priority / "nice-to-have" sorts of requests, or this is a tangential or supplemental approach that might help with some other problem the request focuses on. Since there's limited customer interest, this isn't a very high priority right now.

Is this functionality blocked on something else?