Interesting triage. In legacy upstream this was a "feature request 🌈" - https://secure.phabricator.com/T12438

@valerio.bozzolan thanks for copy-pasting my comment, I didn't see a task was already created because I only checked the Bug Reports workboard. Should the Bug Reports tag be added to this task?

Super-useful comment:

I also ran into this issue, as reported in https://secure.phabricator.com/T12438 it also affects the "In Any" (or any()) searches, and makes it impossible to search for tasks that are in projectA or projectB, which seems quite a common use case:

I don't know if the file is really related, but PhabricatorDocumentRenderingEngine can be seen in scene while surfing a Diffusion repository and playing with View Options.

Relevant old upstream comment (from an unrelated task) that describes this problem as "ghosts in the UI":

adjust strings as suggested, also, renamed classes from "subscriber" to "subscribers"

Help welcome.

PhabricatorFileTransform: add null check

git config --global core.quotepath false

(It's about spam, but it doesn't have anything explicitly sensitive. I've made it public now)

Posted question at git@vger.kernel.org.

Thanks again. Generally super-useful.

Uhm. Incredibly, it seems to work. I have good feelings.

In D25636#17842, @aklapper wrote:

Ideally this would be done via validateTransactions using ->setFormErrors($errors) on a PHUIObjectBoxView but all seems quite broken for badges anyway, see T15827.

Remove variable definition now unneeded outside of the if clause

Here's a revision which does not throw a red box via ->setFormErrors() at the user but at least it is displaying the Required text and turning it into bold red after clicking Award without having defined a recipient. So the line $errors[] = pht('Badge name is required.'); is currently never ever shown.

Thanks for the hints how to improve this! Appreciated.

Damn celerity. Thanks.

Damn celerity

That was a merged JS change so I should have also run ./bin/celerity map. Sorry. Followup patch in https://we.phorge.it/D25637

On a more meta level, Maniphest isn't well-suited to be an entry-form to be filled by a non-expert user; Nuance is/was intended for this use-case.

on the technical level, Herald can't block object creation - it runs after the fact, by the Daemons.

I don't believe in playing whack-a-mole on "could this be a password" but a use case I've been recently thinking of is "Do not allow task creation when task content/data is exactly the defaults provided by the Form used to create the task". Basically: You were supposed to fill in some stuff but you did not when creating your task.

I think the 404 is possibly better then "silently fail without error".

Uhm, seems I was somehow off by one line. I thought that this comes from escapeToken($repository->getCallsign()) being optional nowadays but seems to be triggered by escapeToken($repository->getRepositorySlug()) instead which indeed would be surprising. This might be a patch to abandon because might hide an underlying issue.

How can we end up with null here?

Rebase

I also faced this, tested @ D25623, and found out git format-patch was emitting that result which causes git apply to fail. See this git format-patch example.

Yeah, on my todo list for the weekend.

And my spam filter says: