This stuff is now in HEAD, and HEAD no longer loads (or even contains) HeraldCustomAction.

I've deployed this to this server, let me know if anyone catches anything suspicious with Herald.

See also T7819.

For the original issue: when a change is blocked, we do not send email about it. There is no way to be alerted to blocked pushes right now, and I generally don't think this is useful enough to include in the upstream. This interaction could possibly be more clear, but feels like something we just stick in the documentation to me.

Just to follow up on this, the transcript will show this at HEAD once T8726 lands:

This has been in the update notes for a while, but just for completeness: T8726 is changing this substantially. After those change land, you must extend HeraldAction instead of HeraldCustomAction. The API is similar, but doesn't directly map to the old class.

This should wait for T8726 since the API for actions is completely changed in unlanded work.

See some discussion in D13777.

Sorry, I made a mistake and didn't update my local copy properly before trying to reproduce this. This is an error on our side.

I can't reproduce this. When I follow these steps, the workflow completes successfully.

I can't reproduce this (resetting my own password works fine), and this report doesn't include enough information to allow us to help you.

Currently nowhere. However I've created custom code

This might be sort of a copy of T7617.

I can't reproduce this issue. For example, here's an index of this task:

Looks like this is in good shape now.

Ah, perfect. Yeah, either contact@ or support@ will work fine. Thanks!

Cool, I'll get this importing. Do you want to shoot us an email at support@phacility.com to coordinate the rest of the import? There might be some private questions later on in the process about data specifics in case we run into any issues.

When they occasionally break people complain, so I think some users find them useful.

They're supposed to show open tasks.

Improve the error message and provide a button to close the audit

I do this routinely (roughly every day) without encountering this problem, so I'm surprised by this behavior.

Specifically: empty commits and commits which strictly undo some of the work on a branch (e.g., revert HEAD, or revert HEAD + the prior commit, etc) produce a new commit with the same tree hash as an older commit.

See also T4411, although I expect to get to this before that.

"Mark All Read" should remove them, but only if you have another newer notification than any of the phantom notifications.

It's not difficult to implement.

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.

What specific administrator abilities are you concerned about them having?

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, 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.