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

Also adding some on-platform documentation would be nice.

Screenshot taken at 702 x 495

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

I guess I should abandon this patch?

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?

No, limit is working fine as it is.

Sorry again for the confusion, I don't want to create extra work. I will create another patch as clarification. Unfortunate legacy situation.

Yup. I noticed that probably the method getNewUserBody() should be just moved from PhabricatorDashboardPanelListController to PhabricatorDashboardPanelSearchEngine. Additional details in T15844.

In D25649#18446, @valerio.bozzolan wrote:

Just try to move the method in PhabricatorDashboardPanelSearchEngine as-is

The test plan should be:

Just try to move the method in PhabricatorDashboardPanelSearchEngine as-is

Wow, this was super-interesting

In D25660#18437, @speck wrote:

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

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

Since this is a third-party dependency can we check if this was fixed upstream, and that an update to phpmailer would fix this?

Swear I’ve come across this before… it might be fixed in our forked branch so I’ll take a look. Does $limit also need same treatment?

Nice!

restore newline

Thanks for the upstream link

In D25669#18389, @avivey wrote:

Don't we have something like phutil_is_integer method somewhere?

Very cool!

Don't we have something like phutil_is_integer method somewhere?

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

https://www.reddit.com/r/ProgrammerHumor/comments/9xat04/the_ancient_code/

Obviously this is very WIP (but still works).

In D25671#18362, @speck wrote:

In D25671#18360, @speck wrote:

Agree the current non-serious language needs updated.

Though, I’d guess Phab/Phorge will actually reject these short passwords.

In D25671#18360, @speck wrote:

Agree the current non-serious language needs updated.

Agree the current non-serious language needs updated. Maybe something like,

Change commit message to reference spelling

"And complained on WMF, where this feature is disabled?" is true but misleading IMO - there was nowhere better to complain than WMF's instance since this took place after Phabricator was abandoned but before Phorge's initial release, and WMF's instance has received numerous other reports of Phabricator translation problems that were later redirected here or to old upstream.

Well, I understand why this patch completely removes that joke.

This is spelling, not formatting.

Using a password in 2024 is a bad advice in general.

And yes, I did read https://we.phorge.it/book/phorge/article/tone/ before filing this patch. You are welcome to berate me (and by extension Verdy_p on translatewiki.net, although they've been blocked there so the chance of them seeing anything you say is low) anyway.

Sorry, this isn't an upstream problem. It's an instance of the general "Phabricator lacks message documentation" problem, since nav is a bit of remarkup that niether Verdy_p on the translatewiki side nor I am familiar with. But I can handle that on the translatewiki.net side and there's nothing for upstream to do.

I upstreamed this as a largely procedural action (go through all requests for source message changes in translatewiki.net that haven't been resolved and move them up to Phorge so they can be evaluated properly rather than ignored).

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...

Read the originally requested changes more carefully

@mturdus Can you spare some time to review this diff?