This is expected. You do not need "edit" permission to comment on a task, subscribe to it, award it tokens, or take other actions available in the action dropdown.

You can restrict the availability of these actions globally by configuring Custom Forms, as we have on this install.

We might change this behavior since it seems to be a recurring point of confusion, see also T11169.

Thanks for the quick reply.

I did in fact create a custom form, where i limit the fields to the user. That works nicely.

I understand your answer here, but I at least see one actual bug, because I am allowed to change board columns, but when I go to the board, I am not allowed because i don't have edit rights to the task

There are many situations where you can make an edit in one way but not in another. For example, you can't edit the subscribers for a task via "Edit Task" on the detail page, workboards, or task list, or via the API, or via mail commands but you can edit them via "Subscribe", "Unsubscribe", with Herald, by commenting with @username, or via the action dropdown.

In and of itself, being able to edit something one way but not another isn't a bug.

Alright, thanks for clearing it up, and sorry for calling it a bug :) I am new to phabricator, trying to see if I can configure it for my needs where permissions have a big role. Maybe I should explain what I am trying to do, so my request maybe makes more sense. You are of course welcome to close this task as wontfix, I just, as a new user, found it confusing that the edit policy wasn't strictly enforced around the application, view policy seems more strict though, which is nice :)

My scenario is: I am a freelancer you runs many projects for many customers. Currently all customers get a Trello board, where we run the project communication. Problem is I have no total overview, and this makes planning my time difficult.

With phabricator I am trying to solve this by: Creating a project for each customer project, and assigning the tasks to projects. I set the view policy to only members of the specific project. At one point, I accept the task request from the client, and I assign it also to my special planning project, where each column is a week name. I then set the edit policy to admins only, so the client can't move it on the planning board, and at this point I take over the progress on the task, and comments is all they need to do.

Maybe i should just trust my clients not planning on my behalf :D main point is that view policy is enforced, so the clients won't see each others tasks.

So this is my use case, maybe you can use that for something, if not, thats also okay :) Thanks for taking your time, and you can close this task, if you don't feel this will spark any changes

D17452 marks this as resolved and makes these changes:

• Actions via the comment form now require edit permission by default.
• Actions are unavailable for selection via the comment form if they require edit permission and the viewer does not have it.
• Select actions (such as commenting itself) are whitelisted as not requiring edit permission.

In practice, users who can view a Maniphest task but can not edit it now have no available actions, regardless of form settings. In other applications (like Differential), they have a limited set of available actions (like "Accept Revision": you do not need to have edit permission to perform review).

There still exist some grey areas, many of which seem like they are probably correct (for example, you can still add subscribers to a task you can not edit by @mention'ing users in a comment, and you can award tokens to a task you can not edit), but this should make the darkest grey area in this class of interactions more consistent with expectations.