Tested this with nearly all DataSources mentioned above before and after applying the patch in both a logged-in and a private browser window. Behaves as expected and no errors in the logs.

@jmeador Hi, what would be the Test Plan to get a "resulting query"? Going to /differential/query/advanced/, selecting the magnifier button for the Responsible Users field, and checking that after applying the patch only user accounts are listed, and no more projects or packages, I assume?

All in all, this looks ready to merge after removing two commas and fixing one BE spelling. I tested this locally and everything worked as expected.

I'd also prefer American English spelling for the sake of consistency, means: using catalog instead of catalogue.
cf https://we.phorge.it/source/arcanist/browse/master/src/workflow/ArcanistWorkflow.php$840 :P

I confirm that all other 21 definitions of function getNewUserBody() are in *Engine.php files/classes, except the one fixed/moved by this very patch.

Abiding by the law of triviality, after nine meetings the Working Group that I set up for this task came up with this proposal:

I remain unhappy with my code in D25546:

• Phorge lacks a method "give me all engines for this application".
• PhabricatorApplication offers nothing related to engines.
• PhabricatorEditEngine::getApplication() does what I want exactly the other way round: it returns the application for a given engine.
• PhabricatorEditEngine::getAllEditEngines() is confusingly named. It only returns EditEngine keys like calendar.export or maniphest.task but not actual engines or engine classes. ($engines = id(new PhabricatorEditEngineQuery())->setViewer($this->getViewer())->execute(); returns the actual engines, as already used by this code.)
• I cannot find some mapping between EditEngine keys (like maniphest.task) and either PhabricatorPHIDTypes (like ManiphestTaskPHIDType) or their TypeConstants (like TASK) either.
• getEngineClassName() exists but only in a SearchEngine/SearchQuery context, not in a EditEngine content (and I cannot find its constructor)

I remain unhappy with this code.

• Phorge lacks a method "give me all engines for this application".
• PhabricatorApplication offers nothing related to engines.
• PhabricatorEditEngine::getApplication() does what I want exactly the other way round: it returns the application for a given engine.
• PhabricatorEditEngine::getAllEditEngines() is confusingly named. It only returns EditEngine keys like calendar.export or maniphest.task but not actual engines or engine classes. ($engines = id(new PhabricatorEditEngineQuery())->setViewer($this->getViewer())->execute(); returns the actual engines, as already used by this code.)
• I cannot find some mapping between EditEngine keys (like maniphest.task) and either PhabricatorPHIDTypes (like ManiphestTaskPHIDType) or their TypeConstants (like TASK) either.
• getEngineClassName() exists but only in a SearchEngine/SearchQuery context, not in a EditEngine content (and I cannot find its constructor)

Use phid_get_type instead of substr as it does the same job

Okay I'll just re-arrange the chairs on the ship deck a bit then, double-swear!

Nah, appreciated if you think that there is a better / more correct way to fix this which also covers a bigger underlying issue that you found. :)
I guess I should abandon this patch?

In D25649#18446, @valerio.bozzolan wrote:

Just try to move the method in PhabricatorDashboardPanelSearchEngine as-is

In D25660#18437, @speck wrote:

Oh I see you did confirm it’s fixed upstream. Should we just update the version we’re using?

In D25669#18389, @avivey wrote:

Don't we have something like phutil_is_integer method somewhere?

No changes; merely trying to reset "Changes planned" in Differential

Obviously this is very WIP (but still works).

Admins of any Phorge installation are free to enable serious-business if they do not like such jokes and/or assume that users in their installation would happily follow such instructions...

Uh, Conduit also says Task IDs must be integer numbers. Nice. But how can I reset "Planned Changes"? Only by pushing another revision?

TODO: Check how Conduit reacts to this

Add PHPDoc; tested that return value is always plain string, also with custom logo

In D25668#18281, @avivey wrote:

need to also test the result of renderPhabricatorLogo() when no logo set, when a custom logo is set, and when a custom logo is set but hidden (maybe. Maybe the logo file should be Attached to something public, so this situation can't really happen?)

Move policy.allow-public check from method itself to calling the method

Note to myself: Still need to test resulting URI when a custom logo is set

Replace a call with a variable

This probably needs more work but seems to function locally.

Garr, I did not branch.

@20after4: Willing to share some code at some point that folks can poke or play with? :) TIA!

Valerio may have a point here :D

I'm stupid and should have really checked the commit history first. Sorry!

Uh thanks, I had no idea where the upstream is, good to know because there are a few more issues. :)