This was resolved by the introduction of PhabricatorExtendedPolicyInterface. Older cases with missing policy proxies occasionally crop up, but I believe most of them are resolved at HEAD of master. These errors always fail closed (deny access which should be acceptable), never fail open (allow impermissible access) so there's no urgency to hunting them down.

Thanks, I wasn't able to puzzle out the reproduction instructions on the original report since they didn't mention actually making any policy changes.

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Not all applications have full policy support yet, usually because it's blocked by something or they're beta.

I'm unable to close this, but I believe this to be resolved (or at least my specific repro of flags via herald no longer applies I believe).

hi

Somewhat related, if you have a disabled "Home" as your top item, we still show that regardless of the active dashboard below it.

T12956 has another situation where letting MenuItem generate 2+ items may be bad: we want to let a menu item steal the selection, but it's muddy to implement if each MenuItem can return several actual views.

@hach-que, did you end up implementing a solution for this?

That use case doesn't strike me as compelling enough to justify a separate field or a behavioral change so I don't plan to adjust our behavior here.

In T12900#228746, @epriestley wrote:

Only you and users who have permission to edit <Blog Name> can see this draft until it is published. Use "Publish" to publish this post.

...would that resolve things in your case? Or does the rule we actually implement not work as well as "only the author" in your use case?

You must be able to view a post's blog to view the post, so the rule is effectively "view and edit".

Don't most places consider "Can Edit" to be weaker than "Can View"?

For private reasons affecting the reporting install, this no longer has customer impact.

Isn't that a dup of T8611?

@stettberger: If there is anything missing from the WMF policy API extension, please feel free to file tasks under https://phabricator.wikimedia.org/tag/wikimedia_phabricator_extensions/ or open a differential revision against https://phabricator.wikimedia.org/source/phab-extensions/. I will be glad to review patches, I can't make any promises about feature requests but reasonable changes will be considered.

Then, I will use the WMF extension for now. I understand that you won't prioritize this. Just for future reference, I will document the structure we have come up with : I currently employ already a more hierarchical project/subproject structure that can be use over several semesters and makes it possible for me to reference all students at once:

Some workarounds in the short term:

D17452 marks this as resolved and makes these changes:

We would also like this behaviour, and currently use a workaround to accomplish it (which is why we never came here looking for a fix). We created a custom Create Task form that sets the default view policy to include subscribers.

Voila.

You can also safely cherry-pick that to test if it resolves things, it doesn't interact with anything else.

That is: rP65c1c758ed261f65c8164d200ce01373ae5b822c

If you upgrade past 65c1c758ed261f65c8164d200ce01373ae5b822c (both stable and master have this change), does it reproduce?

(And again, to emphasize, I'm happy to drop this if y'all aren't interested. I have my solution and am happy ignoring this, but just thought it might be something you guys would want to check out.)

Head as of my Dec. 17 post in this thread. Can roll forward, but was hoping to wait till the edit engine migration settled a bit.

What version of Phabricator are you currently running?

@epriestley any suggestions?

I did some further digging and made a little progress

I wasn't able to reproduce this earlier so I'm not sure how to move forward, but feel free to follow up if you have more information.

I've been playing with it for maybe half an hour, and couldn't reproduce:

• Made revision public
• stopped the daemons
• mention a user
• updated the revision to a new diff
• made the revision not-visible to that user (visible only to the acting user)
• start daemons and let them finish the queue

Thanks for the advice. That yields the trace below. My understanding is that it was a diff with policy set to subscribers which had an author plus a single subscriber. That subscriber was added by herald upon the diff's creation, so there's certainly grounds for something going on there. I had trouble divining the exact issue, but tinkering with the permissions for the object ended up letting the emails go through.

We used to have a tool to show a task's data, but it must have gotten lost in some refactoring.

• In Daemons, find the task ID in the leftmost column of "Leased Tasks".
• Run bin/worker execute --id <id> --trace to execute the task in the foreground.

That will give you a more detailed error information which you can paste here.

Just updated to head and am seeing the same issues.

At least in this use case, I believe things turned out alright without this policy.

(Feel free to follow up with reproduction steps once you've sorted everything out)

You have to be up to date and you must provide reproduction information in order to file a bug report. Please use Ponder otherwise. Thanks!

Hmm, I'm having trouble reproducing this. Here's what I did:

@vanmeeuwen couldn't you use custom forms to lock/hide the policy controls on the maniphest task submission / edit forms? That's how we handled it at Wikimedia's Phabricator. As mentioned above, Custom Forms is the general way forward for controlling default task policies.

T6706 was the IP-address specific task.

We haven't seen other requests for this in nearly two years, and it can likely be implemented as an extension, except possibly for the weird cases mentioned above.

This has promoted to stable and doesn't seem like a contentious change so I don't currently anticipate any need to keep this open or revisit it.

Personal Herald rules do not run for disabled users, so disabling a user will disable all of their personal rules.

In my personal opinion adding a CC that cannot see the task is an error and like this should be treated, meaning ux should just report as error when try to save it. It is important that ux reports it since it can be overlooked by the person changing the task.

Thank you for exhaustive description. One more question:

Primarily, global rules bypass access control policies. They can also apply different actions.

Great and very helpful change, thank you!