Cool. Let us know if you're still having issues.

It is always English (US).

You can use bin/policy unlock <object> to open up the policies on an object. For example, bin/policy unlock rXYZ.

Walking through some use cases, roughly in increasing order of complexity, and general behaviors -- this is all me just imagining things, not necessarily the best way forward:

Does this fix it?

If you type this:

This is the task for it.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

Okay, can you file a separate issue for that and I'll try to reproduce it? That's bad and not the expected queue behavior.

Would roles be able to have a list of default Projects (or Space?) which members of the role are added to? Or should we expect to migrate to role-based permissions?

commits without UTF8 data in them effectively block the queue.

there could be info in saved searches

Is this really a case of information being useful to an attacker?

To address two things immediately:

This one is a bit magical and needs some adjustments after changes from T8726.

(I did so.)

That change doesn't fix things retroactively. I can delete draft 315073 if you really don't like that specific bubble.

Can you construct a plausible scenario where this information is substantially useful to an attacker?

I would argue that showing stuff to users that cannot be used is a UX bug.

(I haven't tried to reproduce this.)

There is no way to do this right now. T4103 will provide a way.

Repro instructions are:

For my own reference:

(or posting, I tried just submitting and it wouldn't let me)

Specifically, I would expect the comment to appear in the preview at the bottom of the page, but not be visible inline in the diff itself.

It looks like you have an unsubmitted inline on line 70 of PhabricatorBadgesRemoveRecipientsController.php with this text:

If you scroll to the bottom of the screen, is there a saved value for "Action"?

This reproduces locally for me.

I didn't get as far as implementing this, but my intention was to make clicking the token eventually take you to the object's page (for example, the project's detail page or the user's profile page), not select the token.

Based on context (in T8906) and previous discussion, my guess is that you're trying to make the "Projects" field required. I'm going to merge this into T6030, which discusses solving that root issue (among other related issues).

We'd prefer to solve this by letting you make the "Projects" field required, since that's the actual root issue. I'm going to merge this into T6030, which is the general blocker for that.

I haven't seen any reports of actual users experiencing real confusion. If and when we do, I'd prefer to tailor any solution here to their actual confusion (e.g., what were they expecting to see, what were they trying to do, why did they find this confusing), and imagine that hiding these applications is probably not the best solution (offhand, another solution might be marking these applications as admin-only instead). In legal jargon, this issue isn't "ripe".

This isn't quite the same as T7804, see T7804#127310 for discussion.

These aren't quite the same. One is a new condition/field, which would let you write rules like this ("mail me about all zebra stuff, except if I took the action"):

In any case, is it expected that line numbers are being copied in the unified diff case?

Do you have an example where copying the right side of a diff currently does not work like you expect/want it to?

When copying from Phriction and transaction diffs (for example, the diff shown in "Show Details" on a transaction like "alincoln edited the description for this task."), you're also copying out of a diff which we've inserted artificial linebreaks into. These linebreaks are inserted prior to diffing, and these diffs are generally of very low quality. There's some discussion in T3353 of improving these diffs to be word-based instead of character-based, which is likely to substantially mitigate issues around linebreaks and the generally low quality of these diffs.

In 1-up, there's no ambiguity and we can improve this behavior.

No, it's enabled for your accounts only.

I destroyed F641702 and F641705.

We aren't going to ship with the Phriction content.

Reasonable defaults are set by default.

That change adds a "safe mode" for specific accounts, which prevents them from using the console to disable instances and instructs them to contact support instead:

However, here's another suggestion: don't allow people to disable instance outside of Phacility conservative work hours. This way it's guaranteed that in case of a mistake, one can reach support immediately.

I don't know what the reasoning is to prevent people from doing this, but

Restart Apache or PHP-FPM, according to the upgrade guide:

That isn't a great solution - it should be possible to set a max ram used, rather than max percent free

Shouldn't we do something similar by default?

This is the dialog you had trouble with, right?

Then we'd need serious + non-serious locales in every language.

Just to make sure, this is the dialog you confirmed your way through by accident?

I'll try to make this more clear after T8726.

Note that in this case and in the T8863 case, mail recipients must now be able to see objects (e.g., revisions and repositories) to receive email about them. It's possible that that's the source of this issue.

I can't reproduce this. Here's a rule I wrote:

I think this scenario would be better handled with a "Skip" or "Pass" build step than treating disabled plans as automatic passes. That behavior seems very unintuitive to me.

We already have such a mechanism.

You can click "Edit Project" to figure out what the policy is (it will either show you or tell you). This request doesn't really describe a problem.

Use --autoscale-reserve to prevent them from autoscaling past some amount of memory. For example, this will prevent autoscaling if less than 25% of RAM is free: