Ouch. Indeed my last comment had no sense. I was meaning T15941 that should be kept opened.

Ops I've closed this by mistake. We closed just T15564 👍

P.S. - XACT exists, but it does not support the newObject():

Additionally, I don't know if we are able here to show the "supported types" in line 391 (that are less than the existing types, needed in the other if case).

In D25988#26522, @aklapper wrote:

Should ideally use the same error message as in https://we.phorge.it/source/phorge/browse/master/src/applications/transactions/conduit/TransactionSearchConduitAPIMethod.php;4862eada5cd05236b81487b261668f2a2d72fad7$382-387 so one string less to translate.

Ironically though, that existing message will list XACT used to trigger this issue:

Ops I've closed this by mistake. We closed just T15564 👍

Uploading the patch that works on my computer now®

Thanks for this patch that unfortunately it's revealing even more weird legacy ghosts.

Mark as "some comments"

Covered, thanks for review :3

I need to sleep

transaction.search: handle unmanaged exception when objectType is not supported

Thaanks. Can reproduce in latest master. Premising that uhmmmm probably it seems we are not using the API correctly as the correct usage seems with objectType=TASK. Example to get my transactions:

add more edge cases in unit tests

If you mean this kind of hardcoded CSS rules, yes, it's possible for local installs:

Yessss, I agree and we explored a bit the creation of new transactions as good long-term direction, unfortunately it seems still necessary a bit of CSS help from the backend to cover the legacy data (e.g. 10 years old bot-generated comments, with traditional comments)

Uhm... can we sleep with the very possible possibility of having "User Bot" possibly everywhere? 🌈

removed nonsense comment (last change.zip)

fix damn 81 lines lint

add destroy unit test for A > B > C and milestone (I love computers)

look mum, I'm learning English

improve comments (again) - thanks

avoid double unset(), just use or

update inline doc, thanks aklapper

I've tested this again in my production on gitpull.it (lol) and I cannot see whatsoever change in the resulting project report (and I'm sure that the page I'm testing is the one affected since I've introduced some logs in-code). So, approving 👍

I agree about the mystery in the test plan. Anyway, easily test-able by replacing $this->getMetadataValue('stub:create:phid') with a PHID lol. Thaaaanks all.

Should we phlog($e) in your opinion?

Obtained with:

(double-slam-accept)

Tested in my production 🤩 fail before, works after, thanks lol

(Plus, a domain 0 is nonsense, so the well-known PHP pitfall of if($something) is excluded here - double-slam-accept)

In D25694#19273, @aklapper wrote:

I'm not sure it matters for now as Phorge does not seem to accept non-ascii domains anyway (with a confusing error message):

[acko@fedora phorge (T15859preFetch *$|u+1)]$ ./bin/config set "security.alternate-file-domain" "https://苗条.example.com"
Usage Exception: Config option 'security.alternate-file-domain' is invalid. The URI must start with 'http://' or 'https://'.
[acko@fedora phorge (T15859preFetch *$|u+1)]$ ./bin/config set "security.alternate-file-domain" "https://áéexample.com"
Usage Exception: Config option 'security.alternate-file-domain' is invalid. The URI must start with 'http://' or 'https://'.

avoid to introduce a PHP 8 issue (thanks @mainframe98)

I've done my best to try to understand what we are talking about, so, I've created a nonsense X grid made in this way to catch changes:

Be bold Andre, feel free to land 🚀

(Damn Phorge that auto-claims also for wontfix)

Maybe we can wontfix this. The current "workaround" D25485 by @waldyrious is just great and effectively fixed the super-confusing root problem.