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

Specifically:

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

This is T9132 or T8783, that is we'll let you create custom "New XYX" forms for data input to novice users.

With a herald rule, they can add a project for example, and herald set custom visibilty options.

We don't want to infer tagging something with Security makes it only visible to security. That is, rules could override each other and lead to unexpected results. T8783 and Spaces is the correct means to solve this. With Nuance, things go into a safe queue and get moved to the appropriate application and visibility. So a "Report Security Concern" Nuance queue could hold sensitive issues until it's decided they should move to the security team, or is just a feature.

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.

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?

"Who can change task policies" exists in Maniphest, if you haven't looked into it.

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.

For example: You have teams working at a problem, and a manager needs to control the teams (see tasks), but the teams have different spaces, so it would be better, if they can change the spaces on their own, but don't change the visibility, because in this situtation the manager can't see the task.

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?

(also see T4675 which is a similarly related task)

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:

So I've a very concrete workflow which is currently not implementable in Herald and which I think is part of what the bug reporter was asking here. (If not, please let me know, so that I can file a separate feature request.)

We have a produce whose tasks/bug reports should be, by default, visible only to a specific space (let's call it S2="members only").
I'd like to set a Herald rule that fires only the first time (easily doable) wherever a new tasks is associated to a given project (ditto). The action part of that rule should be "shift task to space S2". AFAICT this latter part of what I'm trying to do is currently not supported.

As mentioned in this bug report I can use the batch editor to shift a bunch of tasks to a given space, but that's completely unrelated, and useless for the safeguard security measure I'm trying to automate using Herald.

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

Many thanks for your work on Phabricator, it really is a great tool.
Cheers.

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

I understand this is a different way to build software, but it's vital to us to understand core problems users are having with Phabricator, then we will help you find a solution. The issue here is this feature request has yet describe the day to day workflow / problem faced. When people prescribe a solution, they get hung up on it. We often need to generalize solutions to fit many other workflows, not just yours. Mostly, this sounds similar to T8434, but without details on what the exact workflow is, it's hard for us to know where to group this request to.

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/

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/

Thanks for the reference.

I'll try again to describe my problem, and I'll be specific with my work-flow, so that you can assess whether there is something worth generalizing it or not.

I want to avoid that bug reports against a specific product (which we track in Phabricator using a specific project) leak to the general public due to the mistake of not selecting the right space when initially entering the bug report into Maniphest. Still, I want to allow, after the initial submission, to open up bug reports to the general public.

Herald is my tool of choice for implementing workflows in Phabricator. Given it is possible to do various actions with it, and given that other parts of Phabricator allow me to do "shift to space" actions (most notably, the batch editor allows to do that), I was hoping Herald had a "shift to space" action. If it were there, I could've used it to implement my safeguard. But it's not. Maybe there are other ways in Phabricator to implement what I need (describe above to the best of my ability), but I haven't found them yet.

I've skimmed T8434, but it seems to me that it is more geared toward "hard boundaries", which is not what I need. I want a policy that initially put tasks in a specific "safe" space, but allow overrides later.

Does that make more sense now?

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

Our intention is to solve this with Nuance, which is essentially a "help desk" tool. It sits before Maniphest and allows you to act and move things before they end up there (or other applications).

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.

If you select the option, when you create the task, it's not herald which change the policys:

Maniphest changed the visibility from "Public (No Login Required)" to "Custom Policy". Via Old World · Aug 29 2015, 00:01

If you change that field later, this rule changes the visibilty. But I agree, I think Nuance could useful for that too.

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.

@revi This third party tool no longer exists, the two links are broken and the latest commit at https://github.com/haskell-infra/libphutil-haskell removed the changes:

commit 3b60b184772aa575e3834b003e87295daf0bd313

herald: Remove custom actions

They're broken with HEAD and need to be re-written.