@matmarex why are the gerritbot colors different in the "after" mockup?

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