Page MenuHomePhabricator

Readonly access to users
Closed, InvalidPublic


How can i restrict, users only readonly at the project level.

Related Objects

Event Timeline

kiran009 raised the priority of this task from to Needs Triage.
kiran009 updated the task description. (Show Details)
kiran009 added a project: Maniphest.
kiran009 added a subscriber: kiran009.

Can you explain your use case a little more? Why do you want to give users readonly access but not let them, e.g. make comments or subscribe to tasks? What kind of users are these?

btrahan claimed this task.
btrahan added a subscriber: btrahan.

Please do re-open this if / when you have time to answer @epriestley's questions. Also, check out

The reason I want to give readonly access to make them follow and not do any changes at the project level.

...we're really looking for as much information as you can possibly provide about what you're trying to do here. As a simply stated feature, the answer is "wontfix".

What is the role of these users in your organization who should have read only access but can not e.g. comment or subscribe to tasks? Can you generally describe how you're using Phabricator in this context and what the problem(s) are you are experiencing? These are just helper questions so please do the best you can to explain as much as you can about how you're using Phabricator such that you had this idea for a feature.


The user is an outsider to the project, but we want to give me access to tasks for viewing not even to comment.
Instead of categorizing as an user, I want him to be tied with a role.

How come the user shouldn't comment? What is the business value of letting someone read this information, but not interact with it further?

We're building collaboration tools and generally think the user SHOULD be able to comment, so its important to explain how come this specific form of limited collaboration is valuable. I think right now you are just re-stating your request over and over without giving us any understanding of the deeper business problem you are trying to solve.

Might not be a strong use case, but we stumbled on this while talking internally about it. In our environment we've got many developers using phabricator, and an external 'manager' that basically just wants to see activity, but none of the developers want that manger to have direct interaction with their objects.

It manifests due to broken collaboration meta-environments, we are running many projects through phabricator but ultimately the developer to manager 'collab' environment is email.

I'll be honest, its kind of a shit use-case.

This is sort of exceptionally stupid and probably fairly broken until T10769 is further along, but we have a cluster read-only mode now (used when the master database is lost in a cluster configuration). Rather than using it as a disaster recovery / availability mechanism, you could force users into read-only mode explicitly, by doing something like this:

diff --git a/src/applications/auth/engine/PhabricatorAuthSessionEngine.php b/src/applications/auth/engine/PhabricatorAuthSessionEngine.php
index e7d5c94..42b9b2c 100644
--- a/src/applications/auth/engine/PhabricatorAuthSessionEngine.php
+++ b/src/applications/auth/engine/PhabricatorAuthSessionEngine.php
@@ -837,6 +837,10 @@ final class PhabricatorAuthSessionEngine extends Phobject {
     // Switch to the user's translation.
+    if ($user->getUsername() == 'sneakymcsneakface') {
+      PhabricatorEnv::setReadOnly(true, PhabricatorEnv::READONLY_CONFIG);
+    }

This would immediately force untrustworthy external user @sneakymcsneakface into read-only mode.

Note that this mode is primarily a disaster recovery mechanism, and is strictly read-only: the user won't be able to execute any operations which perform database writes. So they can't leave comments, can't mark notifications as read, can't set flags, can't change their settings, etc. But maybe that's fine.

(At the current time, I still don't anticipate us ever bringing any version of this feature upstream.)

Awesome response, also fair that this won't be primary functionality. I feel our case is extremely edge due to poor environmental composition, which phabricator shouldn't be attempting to solve for us.