This isn't a priority, which means I don't want to spend time planning, reviewing, merging, or supporting it right now, not just developing it.

Yes, but "Project Members" is not the same as "Members of associated projects", and I think we are unlikely to implement that in the upstream. You can implement it as an extension if you want that behavior.

No, there's no overlap.

They're fairly recent (last couple of months).

It sounds like we could possibly resolve this by letting you change application edit policies instead, which I intend to do eventually. That said, I don't think adding an enable/disable policy is necessarily unreasonable, and it's generally in the vein of other similar policies.

A similar policy elsewhere is the Conpherence "Room Participants" object policy:

The "Subscribers" object policy is PhabricatorSubscriptionsSubscribersPolicyRule, which adds this thing:

It's vaguely possible we may implement this eventually, but it's not going to happen any time soon and almost certainly not this year.

See T9022 / https://secure.phabricator.com/book/phabricator/article/prototypes/

I'm just going to close this and T9009 out under the "we know prototypes are super broken, wait until they unprototype before reporting bugs" rule, I think @lpriestley has a handle on it.

A couple of things offhand:

What specific administrator abilities are you concerned about them having?

The same thing happens when trying to select a different encoding.

I'd rather not. We have a lot of staff who manage access and most of them I don't want poking around as an admin.

Notably, with metamta.one-mail-per-recipient, "Reply All" is the same as "Reply" (other recipients are not included on the mail). This is the default setting, is more secure, better respects policies, and better respects user preferences. A large class of problems are intractable if this setting is disabled.

Can you just give more users admin permissions?

In any case, glad to hear this is working now! I think the UI should improve pretty soon (next week or two-ish) for this specific class of problem, at least. Let us know if you run into anything else.

Upcoming changes related to T5791 and T8726 should increase debug-ability, but giving web users access to mail is tricky while still respecting policies (e.g., administrators shouldn't be able to violate policies by just reading other users mail) and limiting the ability for an attacker to escalate access (e.g., an attacker who gets an admin account shouldn't have a blank check to access every other account by reading other users' "Welcome" or "Password Reset" mail).

What kind of files are you downloading? Are these PDFs? Text files? Something else?

Probably a getApplicationURI('phurl/x/') which should be getApplicationURI('x/').

char in Arcanist means "byte". If your linter works in UTF8-character offsets, you should convert them to byte offsets before passing messages up to Arcanist.

Specifically, you could get the behavior you want by changing the visibility policy of the task (so the user can see it) or adding the user to the project (so they satisfy the current visibility policy).

It looks like T1603 on your install has a project visibility policy (i.e., the task is visible to members of a specific project). However, I think the user customer_support_pagerduty is not a member of the project, so they can not see the task. (I'm just looking at the database here, so it's possible I got the WHERE clauses wrong.)

(And using only color to convey intent may create difficulty for users with low vision or colorblindness.)

Yeah, something generally in that vein seems like a good approach to me. It's much more flexible in terms of conveying intent (you can pick as many different emoji as your team needs/wants) and in terms of process (you don't need to explicitly fiddle with anything if your comment is unambiguous, like maybe pointing out a typo on a documentation change submitted by someone you know well and regularly work closely with).

Can you provide some more context, or examples of the kinds of comments that are ambiguous?

Here's why you didn't receive the mail:

I can't reproduce this. I made this rule:

(See D13739.)

Fixed in HEAD.

Yeah, I guess that works.

Ah yeah... I have self emails disabled. I dislike self-emails when creating a task through the web UI, but I would see value in having self-emails when I create a task via email (because otherwise I have no idea if it actually worked)

Yeah, here's an example email I receive when sending mail to bugs@phabricator.com:

(Removing Security since this isn't a security vulnerability.)

We should probably just get hovercards activating in more places; I think there's a task for that (or at least some discussion) somewhere. For example, they don't activate for "Author" / "Subscribers" here in Maniphest, but I think there's no technical reason they couldn't.

See some prior discussion in T3945.

hahaha

I think this should be fixed now, let me know if you're still seeing issues?

I cherry-picked this to stable and upgraded the cluster.

Do we have a "helpful bug report" badge?

This is a valid, compliant JSON-encoding of the string, which allows / to be escaped -- here's the grammar diagram from json.org:

Aha! That's a different error:

Okay, so suppose we decide this represents a flaw in the linter and a user does accidentally write two linters which are "flawed" by suggesting strictly conflicting patches. Maybe they just made a mistake, or maybe they enabled two different linters which they didn't realize have conflicting behaviors, or maybe they intuitively think the rules for deciding which message wins should be different (for example: use the stronger severity; or use the first message raised; or use the message from the first declared linter; or use the message with the shorter replacement text). Or we add a special priority field for this and both messages have the same priority. What should the behavior be?

Suppose the patches literally suggest changing "A" to "B":

When a linter emits two strictly conflicting patches ("Change A to B", "Change A to C"), what behavior do you expect as a user?

That would work but I guess.

See T7962 and T8054 for previous requests to describe problems.

Oh cool, I haz badge.

This was fixed in master, I just missed promoting it to stable since the release schedule has been out of whack recently. Should be fixed now.

Yeah, I don't think it's terrible since it should happen very rarely if we do "don't generate" too, and no matter how clever we are it's unavoidable in some cases (even if we policy filter, we might send down a "3", and then by the time the user actually opens the menu or clicks the bell they can no longer see one of them).