I forgot to invite the original author. This modification would not exist without aklapper. Eternal glory to aklapper.

Yeah sorry. That exception also occurred to me, before this change: https://we.phorge.it/transactions/detail/PHID-XACT-TASK-tuchgj42nb2ujtc/

Since 2023, Wikimedia Phabricator is really Phorge.

I'm not a fan of "if not nonempty". Can I swap?

Thanks avivey. Added this:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

I'm a little worried about this migration; Do we have garbage collector for this? it would be safer to let it run.

In D25472#13979:

is ArcanistPhpunitTestResultParser now learning to parse generic "junit style xml" format?

This seems reasonable but better to find a test plan. I also tried, without success :(

I cannot reproduce this. Can you?

Thanks Roberto. If you have not time to follow-up, no problem. We can help to re-patch.

Thanks \o/ Can reproduce.

Maybe unrelated. But after we fix PhabricatorCursorPagedPolicyAwareQuery, maybe we will find a crash test also for the first two lines:

Interestingly I was able to reproduce, but only creating 101+ tasks manually and going to the next page. So after that ?after=100 is introduced.

adopt PhabricatorEnv::isSelfURI()

Thanks. Premising I have only knowledge of traits, but not mapbuilder.

Interesting. I see. Maybe expanding its controller that should be this one:

OK I see. Indeed we should not put any similar button anywhere else.

I see. Maybe the root problem is that I'm in love with that Diffusion popup 🤔

Premising the user already have an Delete Document button.

I mean, we can maybe have a "Delete" button that just shows the related CLI command, like I've seen around (Diffusion maybe)

This feature request could also be expanded to:

(We cannot see screenshots like F1633808 - please set permissions to Visible To All Users - thanks)

(Marking as Resolved thanks to the mentioned patch - feel free to reopen and thanks)

Since Subversion allows to checkout just a sub-directory,

To quickly double-check the backend logic, to understand why it really likes an array:

Be more friendly against the backend logic, and with PhabricatorStandardCustomFieldLink

Uh. Yes, for example PhabricatorCustomField::ROLE_DEFAULT is maybe a good choice, just to be sure to obtain its definition whatever its "frontend role"

git rebase master again :) ready.

Tested again with git rebase master. Ready.

( Welcome in Phorge \o/ you are now a Trusted Contributors - feel free to escalate as Task under Phame with a copy-paste for additional visibility, since it seems a super-appreciated Feature Requests )

Awesome thanks

I’m not sure about Permalink being a top-level button. Maybe under the View Options menu?

ready for review, flagged the thing as side-effect

Maybe better to land this to help the author. The author cannot receive email notifications.

I'm a bit happy that:

keep the original optimization about $is_claim, defined only in case

Thanks again for this proposed solution. I have now a big picture and I partially agree on the approach: the fix is there, in touching the manually-set claim action, but maybe we can just mute that "non-effective manual transaction" instead of dropping it. And anyway, we can maybe recycle some code about finding that transaction.

avoid to touch line 327

Evaluate the suggested refactor just for readability reasons :) fine also without that.

I suggest to visit here:

Perhaps a single new sound is enough to change the world.

https://we.phorge.it/D25079#15506

Super important meme to be kept from backward compatibility. The entire site is probably held up by this meme. Do not remove. Imported from:

(Test plan contains "tbd - This is still WIP" - please mark as such)

Unfortunately this does not cleanly applies anymore 🤔

Nuke Diviner page \o/ add txt somewhere

I like the result. Do you also think that the phrase is probably a bit too much in serious business mode? 🤔 Any idea about how to make it a bit more soft?

Yeah enjoy this feature! Already part of our glorious 2023 Week 32