This came up when @Qgil was testing permissions in fab, I forget the solution but I think indeed the split is confusing at the outset

On looking default edit is all users. Any user should be able to submit, unless them not being able to set triage only fields is messing with the whole thing.

@Qgil, I recall this happened during the testing in fab I think. Essentially, the workflow for creating tickets internally to phab is the same as editing them. If you can't edit, you can't create, and vice versa. So non triagers and non-admins are hosed on ticket creation with the breakdown of permissions you would like for the the triagers group (as I understand it).

I tried to scale it back to see what would work, and I came up with this. Essentially, the only thing you can realistically hide from users is the prioritizing. The tickets then all come in as 'needs triage'.

This is the state of permissions now:

Previously assigning and managing state were triagers only.

I tried to see where the threshold was and if I make 'can edit task status' all users, I can actually create a ticket, but then I get the drop downs for 'changing status', but when I try to select one I get:

That seems way more confusing that just being able to actually manage the state of tasks.

I opened things up for now, because the alternative is to for everything to be broken for any non-triager.

Assigning to @Qgil so you can tweak in phab-01 or reassess how you want to handle this.

FWIW, I don't think having the two extra fields is going to be super confusing for people? But maybe it is, really not sure, just had no choice but to change it for now.

This maybe proves everyone joined triagers until Spage to have issue rights :)

If we want to hide something for the sake of form simplicity then we should look into simply hiding it rather than adjusting permissions based on project. I could surely come up with a fairly simple way to streamline the default form while leaving the permissions untouched and also leaving the edit form alone for advanced users to poke at.

Have you tried to reproduce? I have, and found no problems creating tasks. See T581 and T582, both created by a user not member of Triagers, the first one assigning the task to someone, the second to nobody.

The problematic side effect that I'm aware of is the creation of subtasks, because they carry the priority of the mother task, and this is seen as Phabricator as an attempt to change priority, which is a policy currently limited to Triagers.

I still think that Triagers is beneficial, even if the current sample of users in Phabricator (99% advanced users) might think otherwise. We can discuss this point in an own task if you wish.

Tested in phab-01:

1. Created Triagers project
2. Changed Maniphest policies "Can Edit Task Policies" and "Can Prioritize Tasks", setting them to Triagers.
3. Created tasks and subtasks T25, T26, and T27 with a user not in Triagers, without any problem.
4. Changed "Can Edit Task Policies" to Administrators, leaving "Can Prioritize Tasks" to Triagers, and was able to create T28.
5. Reverted changes of policies, adding back "All Users".

Here we have a different policy, though. "Can Prioritize Tasks" is set to "custom policy" and I have no access to it. What is in there? Same question for "Can Bulk Edit Tasks" and "Can Edit Task Policies" out of curiosity, although these shouldn't affect whatever problem @Spage has found.

Maybe related? @Spage managed to create a task with "0" priority, and I don't know how you can do this. See T574#9428