I'm triaging as "wishlist" for now, but realistically - I don't believe will ever reach a point where we'll try to fix this -- see https://secure.phabricator.com/T13154 for discussion.

can confirm, https://we.phorge.it/D25342?id=1111 does show an error for me in an incognito window.

Probably, something should "Attach" these files by default to that Diff, during the upload phase.

A workaround is to make all files as "Public". I fixed for example the diff D25079: Trigger: Add Sound "Coin" by setting the audio file F1271256 as public.

Old upstream WONTFIXed this in https://secure.phabricator.com/T13154

Note that at least for Phame, http://phorge.localhost/J1 seems to always redirect to http://phorge.localhost/phame/post/view/1/blogpost/ instead of keeping the monogram in the URI.
So the baseURI is already wrong (not being http://phorge.localhost/ only) before concatenating the $ref (monogram and anchor).
As an ugly workardound, could probably make "Quote Comment" work by calling getObjectNamePrefix() in PhamePostRemarkupRule and LegalpadDocumentRemarkupRule and then use them in a preg_match to remove the monogram from the $ref but function is protected and... still ugly.

Can you try changing this line in your local install?

can't repro anymore, looks like the regression regressed

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

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.

Interestingly I was able to reproduce the issue with this nonsense patch, in the hope to emulate an email plain-text generation, even if it's not the case:

For interesting reasons, I cannot, in any way, get an email about somebody renaming a single Mockup photo. And, my email preferences are like "email me for everything from every application" and email delivery is "email me about myself".

Initially, the task is in the project's default column:

MariaDB [phabricator_project]> SELECT cp.id, p.name AS projectName, cp.boardPHID, c.name AS columnName, cp.columnPHID FROM project_columnposition cp INNER JOIN project_column c ON cp.columnPHID = c.phid INNER JOIN phabricator_project.project p ON cp.boardPHID = p.phid WHERE objectPHID ="PHID-TASK-f6ri2kdpcvtb3yncho2n";
+-----+----------------+--------------------------------+------------+--------------------------------+
| id  | projectName    | boardPHID                      | columnName | columnPHID                     |
+-----+----------------+--------------------------------+------------+--------------------------------+
| 509 | T139396-parent | PHID-PROJ-yt43plz2cxlidyu4dlia | Backloggg  | PHID-PCOL-no7jbin6vngwkrghrmrk |
+-----+----------------+--------------------------------+------------+--------------------------------+

In T15653#13929, @valerio.bozzolan wrote:

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

What if it were possible to intentionally remove a tag by passing the tag prepended with - to signify removal? like ?tags=-ABCDE to remove a tag but otherwise the behavior would be to just append. I realize this doesn't have the same compatibility advantages but it does offer slightly more flexibility for use in ad-hoc workflows.

Thanks for reporting.

I've probably understood what is going on here

Triaging to "Unbreak Now!" so to be kindly shown in the homepage :)

In theory this could be a two-liner: Changing the last character of the $prefix, and in PhabricatorCursorPagedPolicyAwareQuery.php

- $map[$field->getFieldKey()] = $field->getValueForStorage();
+ $map[$field->getModernFieldKey()] = $field->getValueForStorage();

In practice that leads to: Unhandled Exception ("PhutilTypeExtraParametersException") - Got unexpected parameters: customfield, customfield.index.table, customfield.index.key

<tl;dr>: This is a mismatch between legacy field keys still used for paging, versus modern field keys.

Sorry, I mean this link:

I absolutely don't know what we are doing here since I don't know the supposed "Phabricator way" to interact with the DOM via JavaScript using its library.

@valerio.bozzolan I found the js section where with the listener for open/close the persistent chat. From there I can get element somehow (by ID I don't think it would be good, because it seems to be auto-generated (UQ3_0)) and remove the class "core-menu-item" and the invisible gear icon will no longer be clickable. If the chat is not minimized, we add the class back so we can see it and click it.

This is very probably a recent regression since I cannot reproduce on Wikimedia Phabricator.

This happens also with the Upload File dialog

Ah! I can reproduce exactly in this comment!

Got it! Nice catch!

In T15626#13393, @valerio.bozzolan wrote:

Thanks I'm trying to reproduce. Can you please help me in understanding "click to the left next to the up arrow icon"? I probably don't get "click the left"

Thanks I'm trying to reproduce. Can you please help me in understanding "click to the left next to the up arrow icon"? I probably don't get "click the left"

sometimes i can not reproduce the issue

Chrome 109 on Windows 7
No JS errors in console

Does not reproduce to me.
Which browser are you using? Are there any javascript errors?

FYI I proposed a partial patch in D25415 which makes the issue more contained at least.

I'm 99% sure that this only affects Phame and Legalpad. I tested in Audit, Maniphest, Paste, Pholio and Files without issues.

This situation could be improved even more doing:

I'm not able to reproduce anymore.