Nobody seems interested in my concern, so, hard approve :) Thanks

Thanks for your help @valerio.bozzolan, It appears I had missed that part!..oops...I'll give that a try over the weekend.

Translatewiki finally processed the rebrand a few days ago, as part of https://phabricator.wikimedia.org/T318763

I didn't give up on this one and, since I prefer using the dark theme on my day to day activity, I know there are a lot of work to be done to reach something nice.
I'll try to move forward on next weeks...

My steps to reproduce are wrong / unclear / not always happening.

This partially fixes the problem:

In D25374#10923, @Matthew wrote:

Please fix unit errors

In D25362#13135, @speck wrote:

Is the list of PHIDs referring to what types of objects that it creates? Is the expectation that each PHID type corresponds to exactly one Application? Maybe some additional text on that page to explain more what PHIDs mean in this context.

Probably this happens while creating a new project and doing that thing again 🤔

Can no longer replicate the fault.

I can no longer replicate the fault, so am going to scrap this one.

Great, I'm a little bit busy, professionally speaking but, I'll try to land it this week !

Nobody replied for months. I basically like the disclaimer and I basically trust your test in your production. Thanks.

I suggest to accept with "whatcouldgowrong" \o/

Thanks bob. Just to say that I care about your code proposals and sorry if this needed extra time.

(Indeed I agree we cannot bulk edit things - PHP 8.1 is a nightmare - see T15190)

Interestingly, Gerrit does similar things, and does not mention the problematic URI value in case it's somehow already clear:

Probably this was moved?

Cool. Two things:

(maybe this happens if you have just one provider and it's an OAuth)

Interestingly this cannot be reproduced in any public Phorge:

Other edges have probably been eliminated in the past. For example this one:

I sincerely thought that "Obsolete" was the good one semantically.

I think a dedicated policy for "Can send messages" would be better, to cover more cases. It would be strange that all participants must also be allowed to edit all settings.

Is this only related to the "Authored on ..." field, as far as you can see?

I cannot reproduce anymore. This does not happen anymore in latest master.

Sorry if I've found two additional interesting things:

From a product POV, I agree with @valerio.bozzolan - there is (sometimes) some information on commits that would be nice to index in a search engine - comments, mostly.

I don’t think revert I’d needed but the comment should probably be removed or updated. I’d like to understand why it was deemed hard to do but the solution here doesn’t seem that hard. Maybe it’s more difficult than it appears, or was robots.txt standard later updated in a way that makes this easier, or maybe Phab URLs changed in a way that made this easier but this was never updated, etc.

I'm not an important stakeholder, but I would like to share that in my installation https://gitpull.it I would like to have commits indexed as default as it happened as default and as it happens in GitHub and GitLab. So I'm now sincerely trying to understand how to restore the old behavior without keeping my own fork of Phorge if needed.

Thanks for the deep inspection! Tested and I agree

• Remove extra <tt> in bulk job dialog

In D25473#13673, @valerio.bozzolan wrote:

So this is the only blocking Test that is failing:

Visit /maniphest/, shift+click on at least 1 Task, click on Bulk Edit Selected, Continue, see the popup

If someone strongly feels that I should revert, please say so - thanks! :)

Valerio: Uhm, I'm sorry, I had not seen your comment here before I landed the patch (as I had checked my Differential page instead of my notifications).

Side note, we are introducing the possibility to share this kind of very creative and confusing URLs (that are safe from the point of view of XSS but) that could be an attracting point for lamers to generate confusing user messages inside Phorge itself, like:

Thanks for the additional debugging and finding steps to reproduce! In this case, I'd prefer not to log the issue and to only show a message to the user explaining what's the issue, including their requested bogus encoding.

Heh, very good catch! I can confirm, yes.

Thanks for landing!

This is something that may be not appreciated by some people.