The interaction between Maniphest "Can Edit X" fields and the new form stuff is also currently quite bad. I've restored 'Can Prioritize Tasks' to "All Users" on this install, since users otherwise can not create tasks with the new forms.

In T9908#147036, @epriestley wrote:

Maniphest currently has field-level edit permissions (e.g., "Can Edit Task Status", "Can Assign Tasks"). My belief is that these are essentially always used to hide fields in order to simplify interfaces, not as real policy controls to prevent changes, per se. I would like to remove them entirely: I think they add a lot of complexity and are very difficult to explain to the user, particularly on the email and Herald flows. Broadly, I don't want to move toward a future where every field in every application has a per-field edit policy.

The overall goal seems admirable. The clarification I would make is that complicated permissions are a workaround on public issue trackers with high participation. There you need to worry about the behavior of the 0.1% worst people, because it only takes 1,000 participants for it to become a persistent problem (especially when the most active cohort of 1,000 people this month is a slightly different cohort than the 1,000 last month). Think Eternal September. It can even be a problem if the user base exceeds Dunbar's number.

So, what we need solutions for is:

1. Defining permissions for newbies that may be distinct from the "got the hang of it" crowd
2. Easy ways of graduating people from newbie to "got the hang of it"
3. Easy ways for project leads to do speedy, bulk reversion of problems created by newbies with stupidity indistinguishable from malice. This holds especially true when the "newbies" have automation.
4. Proper guardrails/fences/walls to make it so that the system doesn't need policing/patrol to enforce workflow norms

So, I say "clarify" because you said these fields are to "simplify interfaces". That is true. It's not just simplifying the interface for the newbie making the change, but the "got the hang of it" participants who get disrupted by a newbie. Let's not naively aim toward a future where "usability" == "newbie usability", but one where we make life better for everyone using the system to collaborate.

Defining permissions for newbies that may be distinct from the "got the hang of it" crowd

To clarify, it's critical to you that newbies not be able to, e.g., change the priorities of tasks they filed by making Conduit API calls?

In T9908#147085, @epriestley wrote:

To clarify, it's critical to you that newbies not be able to, e.g., change the priorities of tasks they filed by making Conduit API calls?

I'll have to think about the word "critical" here. I admittedly don't know the exact scope of what you're planning to do and I'm not sure I have time to get my head around it fully. There are certain policies where a nudge is all that's needed (e.g. "velvet ropes" in a queue at most commercial airports) and there are some where we'll probably want something stricter (e.g. the actual security checkpoint).

In your example (person X changing priorities of tasks that person X filed making Conduit API calls, which are assigned to team Y), a nudge is nice, but probably not required. What is critical is team Y having the tools to deal with a zealous newbie who insists on departing from norms, because person X is sure he/she is right, by God, and the people in charge of priorities are clearly haters incapable of seeing the truth. It can be demoralizing for team Y to get into an issue triage meeting (frequently involving many people) and have to repeatedly deal with an issue because person X can't take "not now" for an answer. That said, it seems survivable. So, not critical for this example.

Looking at the problem more generally, beware of accidentally creating hacktivism exploits by allowing for asymmetric disruption. If Phabricator makes it easy for person X to demoralize or subvert team Y by doing something that is easy for person X to do, but hard for anyone on team Y to undo, that will make team Y loathe using Phabricator on a public instance. For example, will the change you're proposing remove the ability to give "got the hang of it" people the ability to change priorities on all issues, without giving newbies that ability? Do you think anything you're thinking of removing creates any other hactivism opportunity?

I arrived here via keeping an eye on T9860, but I shouldn't be treated as an authority about what @20after4 or my employer wants.

From elsewhere:

since T9908: Temporary Guide to Edit Forms / ApplicationEditor Chatter, noone except the two core devs and a small (5 iirc) amounts of "special guests" can answering someone else manifest task when created with the bug form.

This reproduces for me but is not intended.

Ah, oki. Was it not because comment are hidden field on new application form so if you can't edit the task, you can't edit the comment too.

(small joke) This being said, it forces users to asks question in ponder, which isn't that bad.

Notes for me / the curious:

• Subscribers should default to task creator. (I just made this implicit instead.)
• Comments incorrectly require edit permission.
• Editing with no form specified in the URI might not require view permission?
• Allow claim on closed tasks now that we have stacked actions.
• Copy should work, in a technical sense.
• Copy should work on actual Maniphest workflows.
• Ajax stuff should work.
• Fix quick create menu.
• Order of fields is a little funky, particularly stacked actions.

Hrrm, double header in the quick create menu is a little weird. Maybe I'll just drop the first header completely, I think it's fairly easy to figure out what the menu is doing.

Additional errata:

• Global haunt mode? (See T9920)
• "Quick Create" sub-items should be indented? Sort of confusing right now on this install.
• Document possible future "Switch Edit Forms" mode?
• Document possible future "Allow form to create tasks the user can not edit" mode?
• Document possible "choose a create form for this workboard"?
• Fully remove the policies once that's communicated sufficiently.
• Update arc for new API (e.g., arc todo).
• Deprecate old API stuff (maniphest.update, etc).

Wording on this feed story isn't quite right, not sure if that's new or not:

I noticed a few minor issues after deploying this on our install.

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

Also, I find it slightly misleading that the submit button always says "Add Comment", even when there is no text in the comment box.

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I can't reproduce this. Does it reproduce for you on this install?

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

I can't immediately reproduce this in Safari -- what browser / OS are you using?

Also, I find it slightly misleading that the submit button always says "Add Comment", even when there is no text in the comment box.

I suppose we can make this more generic.

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

This doesn't reproduce for me, can you provide more details? It just goes down the select list (and I have to hit <enter> to make it trigger)

In T9908#148608, @chad wrote:

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

This doesn't reproduce for me, can you provide more details? It just goes down the select list (and I have to hit <enter> to make it trigger)

I'm on mobile at the moment but will try to reproduce again when I get home later today.

In T9908#148607, @epriestley wrote:

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I can't reproduce this. Does it reproduce for you on this install?

I have a feeling that it was a server-side issue... Let me check the error logs later today.

In T9908#148608, @chad wrote:

A minor usability issue as well... If you click on the "Add Action" drop down and continually press the down key then you end up adding every action. Maybe we can just disable this behavior?

This doesn't reproduce for me, can you provide more details? It just goes down the select list (and I have to hit <enter> to make it trigger)

OK, just pulled the latest version and can confirm that this is still an issue. Steps to reproduce (I am on Chrome 47.0.2526.80):

1. Click into the "Add Action..." dropdown such that the dropbox expands.
2. Click out of the "Add Action..." dropdown by clicking anywhere else on the page.
3. Press the down key multiple times.

Doesn't reproduce for me on Mac at least, should I be testing something more specific?

In T9908#148607, @epriestley wrote:

It doesn't seem to work properly if I try to comment and also change the status of a task. The comment appears but the task status remains unchanged.

I can't reproduce this. Does it reproduce for you on this install?

Yep, reproduced on T9977. It seems like this issue only occurs if you select "Change Status" first and then write a comment. If you write a comment first then it appears to work just fine.

In T9908#148885, @chad wrote:

Doesn't reproduce for me on Mac at least, should I be testing something more specific?

No, I don't think so... FWIW, this doesn't reproduce for me on Firefox.

My question was more what OS should I be testing.

I can reproduce on Windows/Chrome: As long as the Actions field is in focus and not open, hitting "down arrow" adds an action.

In "normal" drop-boxes, that's a reasonable way of selecting a value (I can open it with Enter, but Enter sometimes submits the form).

Maybe Mac doesn't allow the field to be in focus and not open?

I can reproduce it on Windows 10 / Chrome, but not Mac / Chrome.

In T9908#148901, @chad wrote:

I can reproduce it on Windows 10 / Chrome, but not Mac / Chrome.

Oh, sorry... I'm on Ubuntu.

Confirmed via IRC:

• Set "Can Edit Task Status" to Administrators
• Have non-admins try to create a task
• Get Sad panda no permissions dialog