Thanks for looking into it!
Cool trick with web.archive - very useful!

P.S. welcome in the family of Trusted Contributors and feel free to escalate this question as a new task under Bug Reports and by marking this question as obsolete in case - thanks again

Thanks for the question. I will follow answers. BTW I've found the nuked link:

@speck if you think this thing works properly, you can either resign or click on Accept Revision, because when @valerio.bozzolan accepted the revision, it still appeared as Needs Revision.

• Improved comment

Looks good to me. Feel free to land. Thanks for the patch!

@speck: Hi, would you be willing to land this? Thanks in advance!

Thanksss

Fix a typo

This is a great proposal. Did anyone think of showing two separate queries on Tasks: Assigned and Authored. In my opinion, it just makes it harder to scroll down to authored tasks which is why it makes more sense to have separate Assigned Tasks and Authored Tasks views on the profile menu.

make linter happier

Add some more stuff (final change; moving on to other code areas for now)

Make funtion private now that it's all in the same class; fix a doc typo

Directly put the text of the previous milestone into the description field and display additional info about this new behavior. Less code complexity, less manual user actions.

I do not think changes are necessarily needed, because it already says "With rare exceptions".
Regarding the proposal, I do not believe that "prototype applications [...] are often subject to significant changes" either.

@Cigaryno: That only works in Phorge itself. See:

as rich text and/or in common markup formats

@Tgr you want something like this?: T16008: Provide an easy way to link to a Phorge task in a user-friendly way
If so, just enclose the task ID in {} (ie {T16008}

(Downstream task: https://phabricator.wikimedia.org/T388243 )

I've created T16007: Discuss the policy for contributing to prototype applications.

In the meanwhile I paste here a proposed alternative that may better reflect the current situation (no need to update the patch - since I guess this phrase will attract more changes):

I agree on discussing the removal of this phrase. I will wait the task, but my opinion is that it's a legacy phrase from a company that had better to do than fixing weird workflows based on Prototypes (and it had sense). But now it's a community and we already work on best effort on everything, including prototypes. Moreover that phrase does not reflect the current situation, since we triaged and fixed 6 bugs on the Calendar prototype Calendar (even if it should be un-prototyped one day) - and probably more evident already-reviewed patches.

@Cigaryno please create a task under Discussion Needed for this - I'm not sure we want to make this policy change.

Fix the typo in line 167

In D25881#24406, @Cigaryno wrote:

In D25881#24380, @aklapper wrote:

Thanks. I'm personally fine with bug fixes for prototype apps.

Me too. Maybe this section should be removed?

In D25881#24380, @aklapper wrote:

Thanks. I'm personally fine with bug fixes for prototype apps.

In D25904#24401, @valerio.bozzolan wrote:

@Cigaryno does it work also applying this D25535 ? Thanks Cigaryno

That's a good question. In general in Phorge/Phabricator any archived thing is editable. So I would say no, that archiving a chat still allows to write a message. But maybe it should not generate notifications.

Do we have a task to remove this file from source-control?

@Cigaryno does it work also applying this D25535 ? Thanks Cigaryno

Would sending messages be pevented on archived rooms and would all participants be removed (unless Can Edit is set to Room Participants)?

In T15237#14300, @valerio.bozzolan wrote:

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.

Rip out more unused ancient code like unneeded expensive database queries

It seems that there is even more code to rip out here

Thanks. I'm personally fine with bug fixes for prototype apps.

(Premising that I'm affected by T15985 lol - unrelated)

@speck @valerio.bozzolan @bekay Would you like to review this revision?

In D25897#24262, @aklapper wrote:

Thanks, I can confirm that this works as expected. :)
I agree biggest question is where to put this. In my opinion the UX is already slightly inconsistent (given their are also concepts like "Related tasks" in Pholio or "Referenced Files" in tasks).
In Differential it feels a bit like a stretch to put this into a box called Revision Contents.
In Maniphest the same "Mentions" tab is in the Related Objects box; there is nothing similar in Differential which already has numerous boxes (also Details and Diff Detail but none of those have tabs).

• Updates after review to wording and dropped the placeholders

In D25898#24255, @avivey wrote:

Also, I think that visually, the instructions are too close to the next field and too far from their own field, but that's far out-of-scope for this one.

In D25881#24322, @aklapper wrote:

@Cigaryno: Please provide references when you quote something from somewhere so others don't have to guess where to find things. Thanks!

I think this is the upstream bug report lol

Per comments in T16006 this is rather workaround (ignore) instead of a fix (make it work).

Did some digging using the Network monitor. When using the dialog, Phorge sends this:

__csrf__: B@jqccc7335f3e341bab747f2a
__form__: 1
__dialog__: 1
tokenPHID: PHID-TOKN-emoji-7
__wflow__: true
__ajax__: true
__metablock__: 4

but using the direct URL, it sends this:

__csrf__: B@2rdakjrtaeed9a29351d9a9c
__form__: 1
__dialog__: 1

Unfortunately, all I can gleam is that the JavaScript doesn't trigger correctly when clicking on a token, and never sends the tokenPHID key-value pair as a result. It's clearly not handling the separate form correctly, because disabling JavaScript results in a proper experience.

I haven't the foggiest how this transaction is supposed to use its stub variant; attempting to create a document at /w/parent/child causes an error about /w/parent/ being required.

Replace renderHandleLink() with renderHandle() and not renderObject(), as rightfully pointed out by mainframe98

Ah, thanks, that makes more sense, indeed. (I dislike changes that have an unclear reproduction path.)