Thank you for such a quick turnaround! Highly appreciated.

Thank you! This fixed the issue.

Cool. In that case I'm going to land this as is.

In D16713#197297, @epriestley wrote:

This probably now allows you to move documents underneath a document you can't edit, and immediately lose edit access to them -- maybe? Ideally, that would be a different error ("You can not move this document to that location because you don't have permission to edit documents at that location and would no longer be able to edit it." or similar).

The repro steps I'm imagining are:

• Set a/ to "Can Edit: alice".
• As any other user, move b/example to a/example.
• a/example can now only be edited by user @alice?
  • The moving user was able to create a document they could not normally create?
  • The moving user can no longer edit the document?

That might actually work fine already, though.

Using PhabricatorUser::getOmnipotentUser() produces the correct error message even if the document is not visible to the user:

You can not move this document there, because it would overwrite an existing document which is already at that location. Move or delete the existing document first.

• Use omnipotent user to produce a correct error message

• Use $normal_slug as is

HTTPParameterType and ConduitParameterType seems to be more tied to the request source (e.g. web form or conduit) then request data type. Some fields for example are conduit-only and do not even return HTTPParameterType.

• Relaxed Conduit parameter parsing for non-JSON requests only

• s/validateStringList/parseStringList/ to be consistent with other parse<Type>() methods

Turns out this is a more general problem. I'm abandoning this in favour of D16694 attempt to fix this in a more general way.

In T8238#196204, @epriestley wrote:

I'm a little confused about how these tags are appearing so widely in developer working copies in the first place. Is git clone fetching them by default? Do you have unusual default options configured? Do users regularly explicitly fetch all tags present in the remote?

That is, my expectation is that git pull does not "bring everything back".

In T8238#196187, @epriestley wrote:

I think cleaning up closed tags probably isn't a particularly great long-term solution since some fraction of the revisions likely just get left open forever -- so you'd have 500 tags instead of 50000, but I assume that still causes about as many problems, and you'll be back to 50000 in just 100 more years anyway.

We see how bad this is (does pushing tags to the same repository create a big user-facing mess?) and then go from there.

Makes sense. Thank you for clarification.

I was wondering, besides that :-)

Could you point out whats wrong with the event, just so we know what to expect.

Not sure... Can we check old and new value in Herald? In event listener one of the checks is to compare old and new value in transaction to detect team change (custom field).

Auto-assignment for example.

We would like to have this too. Is there any timeline for this?

I tried implementing this myself but got a bit stuck. Since lines and line limit is passed to PhabricatorSourceCodeView from PhabricatorPasteSearchEngine::renderResultList() this looked like a good place to start, and pass line length limit. The problem I've encountered is that PhabricatorSourceCodeView receives lines already in HTML. Even though stripping tags and converting HTML entities back to original characters to get line length is easily doable but seems a bit awkward. And then truncating HTML markup is even more problematic...

This is about Paste application index page. I guess more generally speaking it would paste search query result list.

I'm not sure this is related to "T9415: PhabricatorApplicationTransactionPublishWorker requires unreasonable amount of memory for large numbers of mail recipients?".

Just an update: I've actually went out and checked Pygments source. Issue was in HTML formatter. Changing string concatenation to list extend/join improved performance by ~10x. My pull request was accepted upsteam so these cases shouldn't be a problem in the future.

I just checked and can confirm your results new pygmentize version. But your ~100x faster JSON lexer is way awesome result!

(I wonder why Pygments is so much slower on the single line input...)

Thank you for detailed response. I see your point.