See T7962 and T8054 for previous requests to describe problems.

We also talked about forcing people to use 'story cards' for requests. So it'd be something like:

(Reviewing Wiki Pages seems reasonable at some point).

@eadler the main problem with filing feature request solutions, then trying to justify it with problems is it makes our job significantly harder, that we have to reject multiple things or try to formulate long reasoned answers for each item. When you just file a problem, we're much more easily able to manage and group it with other (similar) problems. The solutions might change, but we're a very small team and when we solve problems, we try to group them to satisfy the most use cases. Just trust us with your problems.

I updated the task description hopefully better describing the problem

Please file feature requests only describing your problem, not your solution.

I worked around the update issue by using

git fetch
git reset --hard 6be53bd9160807fb7c829b72b23025d233f7072c

(as suggested on the IRC)

Pretty sure this is fixed now, let me know if you're still seeing it at HEAD.

Oh, yes the "Herald" as the actor is incorrect.

This is displaying as intended. That is, if there is no image available, we still outline the actor space for consistency.

In T4887#127996, @epriestley wrote:

It sounds like you actually want T731.

It sounds like you actually want T731.

Our team would greatly benefit from this feature.

Was it easier if you turned your phone to landscape?

We don't have plans to build onboarding tools for the foreseeable future. Our expectation is installs will handle these needs on their own through documentation and other means (programatic enforcement, code review via owners, direct mentorship, IRC, Conpherence, etc).

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

Those problems can be solved with general documentation, it's not something that needs to exist in Herald.

there are other use cases that we'd like to use it for. For example

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.

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"):

Probably T5162 is what you're thinking of, you've mentioned both these features before.

I think this is the correct merge, but maybe I am misreading this. Unmerge if wrong @epriestley.

Unfortunately we are on Phacility so that would not be an option.

I think FreeBSD made an extension for this: https://github.com/freebsd/phabricator/commit/8e442fc85d733ed6ec2890857ac245d86a61f1c0

FWIW I'd find this generally useful: allow Herald to add comments to any object. One use case I'd really love to use it for is to "welcome and inform" new users on their first diff letting them know that someone will look at it, common issues, etc.

Tested it again with c3e16e26c9fd7acdfa5c6a12d8c591ac46d7a85

still occurring when you have a field of type "user"
save anything in it.
Then edit again and clear the field, will result in this error, on ANY action after this.
(Workboard move, comment, status change, in fact anything that triggers herald to evaluate this again.)

Cool, thanks!

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

Ah, yeah, I believe that's the issue, I thought the mailing list user doesn't have to be given the read permission specifically. Thanks a lot for looking!

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:

For reference:
T8866 reported the PhutilJSONParserException

Finally found the cause in our system.
Looks like there is an error related to the "field-type" users.

I wish I had saved the logs, but alas.

Do we have any way to avoid this error?
It seems to have started with latest update,
is this any combination of rules/permissions we can avoid or is this a general problem with one of the hooks inside herald?
(Its currently disabling almost any herald function in our installation, however a few of them still seem to work, but cant see a pattern that we have to avoid.)

Do you still happen to have the original error message? That was unexpected, and the migration specifically accounted for the case of email collisions and I recall testing that case locally in detail, so I'm curious what I missed. The expected behavior is that that list wouldn't migrate (and would emit a message), but other lists would:

Glad to hear this.
Will keep an eye on this then. =)

This is almost certainly fixed by outstanding changes to Herald which are awaiting review. See also T8822.

Not sure the migration works as intended.

may be related to a combination of rules.

For easier use:

There are also a number of outstanding Herald Diffs awaiting review, so it's likely some of this is fallout from moderinzing Herald.

Yes, just made a fresh git-pull on it before sending this ticket.
Will PM you.

And maybe more specifics on how I can reproduce the issue, thanks!

I can't immediately reproduce this issue. Can you confirm you're at HEAD?

Additional information about the rule from MySQL;

AFAIK, DoorKeeper is a way to represent foreign objects and to interact with them; Here the remote object-like thing would be the chat channel?
This might be better served by:

• Fixing/improving chat-bot, or
• Use hipchat's write-only api with the feed.http-hooks (Might require extra steps), or
• A feed worker, like DoorkeeperFeedWorker, sans the Doorkeeper part.

This is likely fixed by further changes connected to T8726, which are currently out for review. I'll keep an eye on it.

• Here the transcript of the last test:
• I also tried to swap the actions.

Ok I updated to 26faa8f1f6b4872be3cf889551cb4a480dbb2678. Still the same situation.

I know you don't provide support for writing third party extensions, but is it possible to do what I am trying to do with Doorkeeper currently? Basically I guess I need to define conditions which define what is published and where it is published to.