See also T13068, which suggests rendering mentions in a special style when the user has muted the object.

I'm going to close this in favor of T13602, which has a more cohesive/modern discussion of the issue. Broadly:

• When rendering a "no view permission" hovercard, it would be nice to annotate it with an explicit "The user can't see this object" piece of context information.

• Context objects don't make it into timeline rendering engines.
• Context objects don't make it into comment previews.

Leftover Raw Members

Probably related: According to https://phabricator.wikimedia.org/T261642, it seems that when leaving a project, phabricator leaves behind some cruft in the form of materialized memberships for milestones of that project.

Spaces have been working great for my install. The only real place where they're lacking I think arises from their coarseness/mutual-exclusivity.

In T13493, PhabricatorExternalAccountIdentifier could also benefit from this null policy behavior.

We materialize some members into the milestone? This causes no real problems, but we shouldn't materialize members into milestones.

We predict the wrong set of members for the milestone when testing policies: we predict "no members", but should predict "exactly the same as the members of the parent project"?

We check the wrong edit policy when testing if you can create a milestone: we check the default application policy, but should check the parent project policy?

Here's the fate of the various issues discussed here:

This should be reworked some day (perhaps partly here) into some more cohesive API, perhaps newLink().

One other thing is that PhabricatorApplicationPolicyChangeTransaction->renderApplicationPolicy() has unconventional behaviors which are not very helpful and not consistent with normal CAN_EDIT / CAN_VIEW transactions. This is somewhat perplexing because ModularTransactions has renderPolicy() already, which has better behavior. I think it didn't exist yet when Applications modularized in D17757, and when it was introduced in D19829 I just overlooked the opportunity to update it.

In Applications → (Pick Something), if an application policy is set to "Custom Policy", the policy is not linked.

A related issue is that when object A returns object B as an extended policy check and the user fails the extended policy check, the "PolicyException" dialog is misleading. It reads like this:

See also T13317.

Although I'm not entirely confident that 100% of objects which should implement ExtendedPolicyInterface actually do today, I think we've gotten pretty much all of them. This approach also seems stable.

To summarize the state of the world here:

This appears to be stable and working properly. D19897 removes a straggling guardrail.

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

"Disable User", specifically, is now granular.

Pushing the requireCapabilities() change out one more week since I had some stuff crop up early this week and it didn't get a chance to soak.

I'm going to push this out to next week since D19586 probably has a few minor issues with it and it's close to the release cut. It adds a lot of new policy checks which weren't explicit before, so I'd guess it may cause a few improper policy errors on things which are actually allowed. I caught a bunch of them (like "Mute Thread") but probably didn't get every single one.

These are actually removed in 2018 Week 33. See T13186 for a small amount of followup and discussion, although there isn't too much new information beyond what's here.

As a possible workaround, a trivial diff which might "fix" this problem is to change the dialog to tell users that they may get more access while they wait by logging out:

Thanks for the great explanation and the pointers!

(I suppose "wontfix" is a more appropriate resolution.)

It's intentional that unapproved accounts have less access than logged-out accounts in some configurations.

I suppose the approach proposed above gets a questionable result here:

After actually looking at the code, it looks like null can already be returned and works, it's just kind of wrong for some objects (like Dashboards) because they really do have a default policy -- it's just hard-coded.

I'm going to tentatively put this (the Phriction rule, specifically) into T13130 for this week although I'm not sure how much work getting getDefaultPolicyForObject() to return the root document policy is and maybe that's Unbelievably Difficult. Let me take a quick look at that and you can either run with it or I can pick it up if it's some kind of weird arcana.