Deploying Leylines + GC changes to admin now.

I used bin/files migrate to move some old files which were stored in MySQL before S3 was configured to S3. The file blob table is now down to 160MB from 477MB.

A big part of this appears to be that dumping the huge Leylines table locks it, so requests can't record their own Leylines data:

Changing the type is going to run into the issue of what to do about the fields which differ between the two types. Fields which are present in the old type will continue to be displayed unless you clear them when changing types.

Could you kindly suggest me extend which Remarkup rule for parsing a specific URL pattern into a token like we do for tasks like T5000.
I can't find where you do this exactly.

Specifically, I'd like to make these changes:

I think:

Things seem better here for me, although I'm still seeing a couple issues:

This is probably T12071. Does your php.ini set variables_order to something like "GPCS"?

@epriestley, what's weird is, I still have this on my bug install, despite having the latest stable updates. I checked, and the migration definitely ran. Thoughts on how to debug this further?

(Also, registration already requires filling out a CAPTCHA if CAPTCHAs are enabled, so adding a second CAPTCHA on this flow shouldn't meaningfully raise the barrier for attackers.)

I suspect these might be "security researchers" who are trying to demonstrate how Phabricator is rife with "critical vulnerabilities".

There is a task to create another target rendering engine, but I'm not able to locate it at the moment.

OK. But isn't it weird from an end-user POV to have unparsed remarkup there?
If it's a choice, you can close this issue! Thank you for your quick answer.

This is working as intended. We only have two choices for target rendering, full remarkup or text.

Thank you for the quick response and fixes!

In T12639#221773, @chad wrote:

I think this is T10038

I think this is T10038

What's the status on this right now? Looks like a fun thing to try and get over the finish line.

This would be useful for us as well, we want to migrate from using local authentication (which was very easy to setup when initially bringing up our server) to using LDAP authentication. We had most/all of our users create accounts using their LDAP username but using local authentication, but really we should have set up LDAP from the beginning.

Reference: Adding LaTeX support into the Phabricator team collaboration system
Should I extend PhabricatorRemarkupCustomInlineRule also?

• I deployed D17774 to secure.
• I verified that rSVNTEST now correctly raised an error because it was backed by a service with muliple hosts.
• I moved rSVNTEST and rHGTEST to a one-host service, securex-legacy.phacility.net.
• I can no longer reproduce any issues against this host.

T12635 had another similar report, and I believe I tracked down and fixed the root cause there.

And thanks for the report! Let us know if you run into anything else..

This should now be resolved at HEAD:

Actually I think there's a real path to this which remains available:

Here's a script which will identify affected users. Output is:

I think some very old users got into a bugged state where their primary email is verified but the "is verified" flag was never set on their account. We saw one of these users on admin.phacility.com earlier, but I wasn't able to identify a way that a modern account could get into this state.

Problems do not reproduce when downgrading svn client:

We run into this as well, mainly when uploading photos of flipover sheets and whiteboards (to Maniphest or Phriction). Our workaround for now is to ⌘ + click, so the image will render directly into the browser instead of using the lightbox.

This reproduces for me at HEAD: