avoid double unset(), just use or

In D25984#26354, @valerio.bozzolan wrote:

Should we phlog($e) in your opinion?

After a conversation with valerio, I probably had misunderstood the feature scope in my comment D25363#18825: When I tested if this also matches for a user who is not the user importing the event into the calendar.
As a note to myself, the commit message says:

WE DO NOT MATCH OTHER USERS BUT THE CALENDAR OWNER.

update inline doc, thanks aklapper

Seems to work locally.

Yeah, definately very useful. We have been able to integrate all our services with AWS SSO trhough SAML, except Phorge, so it would be great to keep all together.

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)

I am excited to announce that I personally watched @valerio.bozzolan crash Harbormaster's build and then load this awesome code into his PC computer machine and then repeat Harbormaster's build and then Harbormaster's build did not crash anymore. Therefore we decided that this awesome code is very good and as a courtesy to every Harbormaster out there will be made available for free, without any charge.

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)

Re "implement in php" - AFAICT, there's no built-in support for websockets in php, but I found at least 2 pure-php implementations out there that might work.

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

Thanks Andre who fixed all the sub-tasks and deserves all the glory here. I cannot imagine more things to be covered, so, boldly closing.

Thanks. We can update the "We didn't yet release a fix on Phorge" and the "We'll release" since D25967 it's now fixed in master 👍

In J6#66, @Cigaryno wrote:

Thanks for this! Is this any related to the security vulnerability warning I got with npm install last month, which prompted me to run npm audit fix?

Thanks for this! Is this any related to the security vulnerability warning I got with npm install last month, which prompted me to run npm audit fix?

Testing welcome.
Input from CSS folks welcome.

From a quick look it seems that clip: rect(0 0 0 0) is very much the same as clip: rect(1px, 1px, 1px, 1px) (make things invisible and only found by screenreaders), and clip-path: inset(50%) (covering each side by 50%) is very much the same outcome as clip-path: inset(100%).

In D25967#26245, @avivey wrote:

@aklapper want to land this?

Possible ways to reduce risk for future issues:

• add a Setup Check that runs npm audit
• remove node, use php-based websocket implementation

@aklapper want to land this?
I figure users need to just run npm audit fix to be safe, and then fix the mess it did on the git diff.

Ah...I may take another look (jmeador: Feel of course also very free to commandeer this back to you)

Ah sorry for maybe stepping on toes, and welcome back! :)

Seems @jmeador is AWOL thus updating per last comment

seems @jmeador is AWOL thus boldly commandeering

Digging a bit further, rP600a3e3b7c2de5d93644e0410cd354ea6752949d implies that methods and files should not be indexed at all and not show up in the results. See also T16045#21931.

A quick fix would be removing the single line $query->withIsDocumentable(true); in https://we.phorge.it/source/phorge/browse/master/src/applications/diviner/controller/DivinerFindController.php;85f51c54303fe50ebc09ee0b652033a8a9f29ab1$45
as that'll allow results for Methods.