Also related: T15025

I've filed T15908 for the "quick create from column to do what I mean".

(@arp - the images you pasted did not get Attached, so they are Private; Please set them manually to Public so they can be seen. We have an open ticket for that somewhere)

It's probably better to exclude ICS files from TXT in .arclint, or define their own section, rather then add hard-coded exceptions in here.

It's not "impossible" on the technical level, it's just not obviously the right solution.

...set it by default to the space that the project belongs to...

In T15903#18780, @pppery wrote:

Ideally strings not shown to the user would also not be wrapped in pht(...) at all to avoid wasting translator's time.

I did some digging:

This entire method looks very hacky to me. I guess at the bottom of every useful UI, there's a bunch of if statements that map icon names to code.

BTW - is something normalizing the header casing?

In T15750#18669, @CryingWolf wrote:

Is this feature meant to include displaying custom project fields in search results as well? (and possibly for other applications that allow custom field definitions)

I'm happy to log it, but I'm nos sure this counts as "fixes" the issue - it still requires an admin to monitor the logs.
But then maybe T15887 and its friends can be collected to a single common "more visibility for Herald errors" issue.

You didn't have Trusted Contributors membership, which provides access to the repo. Try now

👍👍

I think we're all aligned here...

The best way is probably to make an Extension:

• How to Write Extensions
• Phactory: Hosting Projects Here
• T15030: Support a Phorge Extensions ecosystem

these pages should have Macro disabled, probably. A user on the install can add more macros that would break the page in some other ways. Probably.

Once we remove this, we'll need to handle this edge-case:

• I've closed a ticket as "duplicate of T1", but I was wrong and want to mark it as "duplicate of T2" instead (and say it's not a dup of T1).

In D25709#19636, @valerio.bozzolan wrote:

OK.

@avivey what do you think about a new silly commodity method PhabricatorTransactions::findOneByType(array, string) ?

(BTW, in D25698 we started deprecating remarkup.diviner for RemarkupReferenceController)

what will this do?

I'm assuming you're talking about dropping a file in the text area when editing the page, right? Not just dropping it when viewing a wiki page?

Presumably resolved by D25134.

maybe just add if ($value === null) { continue; } somewhere before the this?

grep for PHUIDiffTableOfContentsItemView in the codebase to see where we might be using this class.

If we can't find the problem, that probably means we have some dead code here that should be removed.

Is there something that's not working here?

:shrug:

(re-opening, there's more work left here)

Do we still need the auto-complete feature? In modern times, the OS has the "insert emoji" feature built-in (at least, Windows and Android and KDE do).

Ok, this looks much better then what we have today, so yay.

Looks good! I want to play with it locally before accepting.

It also collected lots of commits, since May 2023.

In D25697#19176, @20after4 wrote:

I obviously failed to run ./bin/celerity map one more time before running arc diff.

There should really be some way to detect and prevent that mistake. It's one I've made probably 100 times before.

What's the current behavior for fallback from cs_CZ? Would it make sense to set the default to en_US in the base class?

What if $cdn has some evil characters? Do we have some escaping, or can it cause anything bad, or do we not care? Looks like we're including a bunch of other config as-is here, so maybe it's ok.

Looks good to me.

I still don't like the solution of using place-holder text for that; But this implementation also adds another DB access which I think is redundant.

Instead of this diff, can you add a modern endpoint that uses the EditEngine/transactions? e.g. maniphest.edit, badge.edit, etc.
That will need a different name (phriction.document.edit?), but will allow full editing capability.

So PHP, very wow

As T15224 suggest, this menu should have the same content as the side-menu on non-mobile view; And in most places, the framework handles that, by actually moving that menu.
So the "right" fix is to find what creates the current side-menu and make sure we call that, or figuring out why they're different here and normally the same.

There may be some room for extra clarity for users in complex organization setups, but this is a rare enough operation (outside of dev) that it's probably not worth worrying about.

Please add some negative tests - things that could trigger this thing, but shouldn't.

I think the EditEngine is what's used to create the actions form, and it has some sense of the object's status (see for example the available actions on Revisions - these change based on the revision's state).
Maybe it can get an additional "field" for this warning, and display it based on task status.

Very cool!