/config/edit/translation.override/ then add the string, and what you want it to say instead. That's the quickest path here. Merging into the other request.

Can you be more specific here? If you just want to rename "LDAP Login" you can already do that with the translation framework.

For (1), it's currently expected, yes. We don't create branches for dependencies in Git either, currently. I don't think this is terribly unreasonable, but I'm also not sure it's terribly useful (does it just help you keep track of which commits are part of the leaf?) and it makes cleanup more difficult by creating more total branch/bookmark artifacts in the local working copy.

For (1), it is expected to not apply bookmarks to dependency changesets that are applied as part of the patch issued? When patched one-by-one they would each obtain their bookmark.

Sorry, I should have led with a screenshot! I'm the biggest nitpicker, I know.

Some of the (3), (2), (1) stuff is that we're trying to pick a single behavior which addresses most use cases reasonably well. For example, if we use "natural" bookmark names that will tend to make things much worse for users in bucket (3).

Thanks, that's much more clear than the original description!

No they're not. I know it's a tiny difference, but look at this closely (left is my proposal, right is the current state):

I'm confused here -- the icons are already struck in every browser on my system (Safari, Firefox, Chrome):

See also T10005 (bulk editors for all applications) and T6722.

Just to clarify, Phacility is the paid hosted version of Phabricator. If you installed Phabricator locally, we cannot help you with this request via Phacility. You'll need to follow Support Resources for your self-hosted installation.

Great! Please mail support at support@phacility.com and identify which instance you're paying us for, then we're happy to help you. We won't help you here, since this isn't the right way for customers to get support.

Yes,we are Phacility customer And I deployed it on a Ubuntu server,Thank you.

If you're a Phacility customer, please mail support at support@phacility.com (and identify your instance).

haha

I was going to wait with updating this task until I'm finished but I'm stuck on GoCD side for some time. The extension for Phabricator is 99% ready so anyone interested may give it a try:
https://github.com/kszatan/harbormaster-gocd-buildstep
It's enough to be able to schedule a pipeline in GoCD but nothing more. This issue hampers my progress with notifying Harbormaster about pipeline status. I'll update this task when all is working as planned.

done! cheers

Milestones works great for this, but you still have to manually create the workboard (just going into workboard and clicking create - milestones show up).

I'm not totally sure about how/why users are expecting the behavior in the third case.

I'm not particularly strongly opposed to adding more options here, I just want to avoid the dropdown becoming this:

For the compliance case, you should already be able to trigger this stronger rule ("always add the package as a reviewer, even if an owner authored it") with Herald, by writing this rule:

As more of a point of philosophy of code review also, I (and, I think, my teammates) would say that diffs should be reviewed by someone who both:

1. Understands the relevant code
2. Did not write the code themselves

In other words, the combination of expertise + different perspective is of value beyond each component individually. If you believe that, then B or C should review A's diff in this case.

When you put it that way, it does seem backwards.

The use case in this task's description does not make sense to me.

We're interested in this option, since we find that users are often surprised by the existing behaviour. I think this would make sense as a per-package setting, rather than a global one.

It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.

We do something similar ourselves for technical interviews, but I just related all the tasks by embedding them in the description of a central task:

I think this use case is a reasonable one.

Just discovered I could use the Milestones feature to do that. Will try this out.

Set new action

Two questions pick at me:

1. Which editor did the user use to add the ZWS in? Any editor I remember does something to warn you about it.
2. Why are there Unicode characters for "goat" (🐐) and for "cooked rice" (🍚)?

On a purely personal/aesthetic level, the box-drawing character block is total garbage and master ASCII artisans would never use it in serious work. A true connoisseur of the craft should accept nothing more than single-byte ASCII range in their collection.

See some related discussion in T12822. In particular:

me too but not everyone is on our level

FWIW I only code via copy/paste.

• T2495: Improve whitespace expansion of tab literals is somewhat adjacent here.
• T11632: Display invisible characters on erroneous user input is a little related: if we generate canonical lists of "invisible" characters in UTF8, they should probably be shared by all three of: the code that detects when input in forms is invalid because of invisibles; the future UTF8-aware invisible mode; and the UTF8 text linting mode described in T11150.

Per above, these are already detected by the Text linter:

I think that ArcanistTextLinter actually checks for ASCII right now, so it should be easy to enable for this case. See also D6050, which discusses selecting encoding for it.

well script-and-regex is NOT anything complex... or you can try and add zero-widht-space as a rule to arcanist Text linter or make own linter extension... anything is good ;)

Anything programmatically detectable should be raised through lint. Asking humans to detect it is still likely to not solve the core problem since they'll always be less reliable. .

Arc supports auto-deleting the remote branch as well as the local one

Great! I was hoping this could be done with some kind of a plugin/extension. I'll look into it and let you know when I have a working solution.

To set expectations, this is an exceedingly low priority for the upstream and these tasks basically only move forward when an existing customer requests integrations.

This is now available in HEAD. See M1476 for a mock. The actual feature doesn't quite look like that yet since the buttons use generic styles, but should soon (see also T12688).

Noted, OK. We'll proceed by adding our own local ./bin/storage endpoint for it.

Yes. (That is, I'm adverse to upstreaming this.)

Would you be adverse to accepting a patch that does this?

"Wait for T12681, then pay us a lot of money." See also T12778.

This is now deployed here, to secure.

Please see Contributing Feature Requests for instructions on how to file a constructive feature request.

In T12144#226158, @epriestley wrote:

Why would you want to set those up as milestones instead of subprojects?

It doesn't help that GH/GL Milestones are loose tags with a target date.

We could also let you collapse/expand columns like your mock in T6642. None of this hide/show/filter/collapse/expand stuff is hard -- T11036 and T4900/T10336 are the only really involved JS changes in queue for workboards, I think. It's largely just not clear to me which subset of the proposed tools is most useful, and it feel like major overkill to implement all of them.

But it's mostly moot until T11036 I think. T5024 is vaguely related ("filter to just one column"). T6642 might be related ("save collections of columns") but my recollection is that task was a bit muddy? I haven't re-read it recently.

That's very easy, just a question of whether we want to add the buttons/menu items for it.

Yeah there are some UI tweaks I can do to dissuade accidental milestone creation.