The build for Dyyyy should not fail. They do not fail in the upstream.

Related, the test console has a big if ($x instanceof ...) mess that should be pushed down into Adapters. A reasonable flow might be:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

We haven't seen other requests for this and I think putting administrators in a project and using "Pusher's projects ..." is a pretty reasonable workaround. This can also now reasonably be written as an extension.

We haven't seen other requests for this in a year, and our behavior is technically correct and I think it is broadly reasonable.

I don't think this is a good fit for the upstream: it's inherently a bit unreliable, can't be made reliable, and I don't think the use case described here is a particularly robust one even if it's reasonable for some organizations.

This doesn't describe a use case (per Contributing Feature Requests) except by reference to requiring projects (which is covered by T6030).

At HEAD, you can now edit this field via the owners.edit Conduit API method.

No clue how to reproduce. If you see it again, grab the field value too? My guess is that it's something like the reviewer PHID ending up as the project PHID instead of your PHID and "Reviewer" needing to be updated to "Reviewers" or similar.

I think it wasn't that bad thanks to a similar set of changes elsewhere from D14669, which I wrote yesterday.

Oh, I should have read that comment more carefully. You tested more thoroughly than I did.

Gah, details of the Herald transcript have already been garbage collected.

Who does the transcript show as the "Reviewer" for the change?

I don't want to introduce this level of complexity into Herald.

In T9766#144249, @eadler wrote:

A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).

A somewhat generic way to do this is to create the notion of a variable such as is_in_deployment and allow Herald rules to check to see if this is set/true/a specific value. If the API to expose the variable is exposed to conduit then also allows for far more interesting workflows (especially when combined with relying on other Herald rules).

@epriestley correct.. basically we have an external system (a Jenkins-like CI tool) that we're effectively using as a workflow engine. The timing isn't strictly defined, it's basically "when the user presses the button, do all these things".

Just to clarify, you would rather rely on an external script to activate and deactivate this rule every day instead of having a Herald condition like "Current time is between 5PM and 9AM"?

(I'd also like to be able to subscribe to Almanac devices/services/networks too)

We haven't seen further interest in this in several years.

The use case I'm trying to cover is to create notifications for open tasks that are past their Due Date (custom date field that we use).

You may also be interested in T9212 which explains a bit better why "free support" is increasing burdensome for the upstream.

More specifically we'd prefer if people:

We prefer people follow our posted guidelines on filing feature requests. We don't take feature requests that don't state a problem. Specifically "feature does not exist" does not satisfy our criteria for requesting features.

Sorry, I don't understand, why you closed this. The problem is:

• You can block commits, for example, if you don't want to see private data there
  • But if you want to block private data, you need to put in that data in a global herald rule, which is public visible
    • But if you don't use regex, you can block private data, yes, but everyone who can access herald, can see the data, so this feature is not very useful at the moment.

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

I suspect T9132 will address this use case.

I don't think there's any way we can reasonably run pre-receive hooks from the test console in the general case. The pre-receive pipeline reads state directly from the underlying VCS, and much of that state is transient (e.g., we may read svn look --transaction <txnid> or whatever). If a user gives us a push log PHID to test later, we can't really rebuild most of the state.

Either is fine.

In T9700#142970, @epriestley wrote:

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

iirc, it's 3rd party tool (and it's herald) (SetTaskEditPolicyHeraldCustomAction and SetTaskViewPolicyHeraldCustomAction of libphutil-haskell @ Community Resources) that actually handles permission from wikimedia extension.

Hm, Wikimedia has custom code to change the policys. You got a custom field at each maniphest task there, and you can choose 4 options, the first is visible to all, the second is for software security bugs, herald changes the policys to the "security" project, suscribers and the author. The third is for confidential issues, (same policys, just visible for another project instead of security), and the fourth option creates a not visible blocking task for ops.

I want a policy that initially put tasks in a specific "safe" space, but allow overrides later.

Please read our feature request documentation if you have something you'd like to see in Phabricator. https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Would the above be considered a reasonable, and concrete enough, feature request?

In T9645#142391, @chad wrote:

Closing this out as Invalid. We have no means of taking hypothetical feature requests, please see our documentation for a better explanation:

(also see T4675 which is a similarly related task)

Closing this out as Invalid. We have no means of taking hypothetical feature requests, please see our documentation for a better explanation:

I'm also happy to fix up this patch myself, if anyone can give me some hints as to what I did wrong :)

I've attached D14359 which is running in our local phab instance and mostly works. While the rule works as intended, the status doesn't want to display properly. I don't expect anyone to accept this as-is, but I thought I'd share as a starting point for anyone who has the time and knowledge to do it The Right Way.

We don't build features for hypothetical scenarios. Do you have a real workflow problem you are running into now or are these requests just anticipatory?

Yeah, I know, that this exists. The current problem is, that this option changes restricts the abilty to change the policys and the abilty to change a space. (User which can't edit task policys can only change spaces via batch edit). So I think it would be better, to make different fields for it.

Can you describe the core problem you are having with Phabricator? What workflows are people getting hung up on and how often is it happening?

Ok, but the problem is, that you can't allow users to only change the space, there all always able to change visibilty and edit policys too (except they use batch edits to change the space, but I think this is not confortable). So I think it would be better to let administrators set different rules for editing spaces and task policys.

For example you have user, they should not change space/visibilty/edit policys

Please follow our feature request guide when asking for new features. https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

"Don't want to use arcanist" is basically T5000...

See T5000. I don't plan to implement this feature as described.

T9352 has an early approach for parameterizing builds via Herald which might let you collapse some of those rules.

Thanks for explanation!

This has been in stable for more than a month without any followup issues cropping up.

Yeah, T4026 seems like a reasonable path forward here in that there would exist a relation for "commit X addressed concerns raised in commit Y".

If the filter doesn't work, we will reopen this task.