Page MenuHomePhabricator

Unapproved users should be allowed to view objects just like anonymous users.
Closed, WontfixPublic

Description

When users register for an account on a phabricator instance which requires user approval they may have degraded permissions for a period of time prior to approval. In particular if the policy of an object permits "anyone" to view or interact with it they are instead shown a "please be patient" screen. This leads to user confusion or at least user annoyance (the need to log out until approved).

Unapproved users should act like anonymous users with respect to policy.

Event Timeline

eadler raised the priority of this task from to Wishlist.
eadler updated the task description. (Show Details)
eadler added projects: Policy, FreeBSD.
eadler added subscribers: eadler, emaste.
eadler renamed this task from Unapproved users should be allowed to view objects just like anonymous. to Unapproved users should be allowed to view objects just like anonymous users..May 23 2015, 4:10 AM
chad raised the priority of this task from Wishlist to Needs Triage.May 23 2015, 4:56 AM
epriestley claimed this task.
epriestley added a subscriber: epriestley.

Disabled users, unapproved users, and users who have not verified their email addresses may be able to increase their effective permissions by logging out. In some cases, normal users can do this too (if policies have been written which deny them access to resources, but permit public users access).

In the general case, this is intentional and inevitable.

In the specific case of unapproved users it isn't inevitable, but the amount of work required to change it isn't worth the small, temporary benefit to a small number of users on a tiny number of installs. Although I'm not sure, I suspect you may run the only production install in the world which is public/open-registration and also requires registration approvals.

It is vaguely possible that we may specialize the checks we perform against general user state in connection with either T1205 or T4571 (both of which interact with "logged-in" users who are not eligible to perform standard writes) and might adjust this behavior after that if it was straightforward to do so, but I don't specifically intend to change this behavior outside of other related work.