Page MenuHomePhabricator

Temporary Guide to Edit Forms / ApplicationEditor Chatter
Closed, ResolvedPublic

Description

Here's a quick rundown of what I've done with edit forms on this install, which describes a couple of use cases.

I have three edit forms for Maniphest:

  • "New Bug Report"
  • "New Feature Request"
  • "New Advanced Task"

The "Advanced Task" form is the default form with all the fields available. This is only visible to members of Community. Normal users can not access this form, and can only use one of the other forms to submit tasks.

The other two forms are very similar:

  • They have a header pointing at the relevant documentation.
  • They hide most of the fields on the form.
  • They hide "Projects", and provide a default "Feature Request" or "Bug Report" value. The user can't edit these, and new tasks always have the corresponding project.
  • They hide "Edit Policy", and provide a default of "Members of Community + Task Author". The user can't edit this policy.

Once users get through task creation, ApplicationEditor isn't fully integrated so users can edit all the fields after submitting a task.

A particular use case is creating a "Report Security Issue" form. One version of this might look like:

  • Default "Visible To" to "Security Team + Subscribers" and lock it.
  • Default "Editable By" to "Security Team + Task Author" or similar.
  • Default "Projects" to "Security" and lock it.
  • Hide most of the other fields if you want.
  • Optionally, provide instructions or links to documentation, etc.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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.

robla added a comment.Dec 5 2015, 5:29 PM

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?

robla added a subscriber: 20after4.Dec 5 2015, 10:37 PM

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.

epriestley added a comment.EditedDec 7 2015, 5:57 PM

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.

chad added a comment.Dec 12 2015, 12:55 AM

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.

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.
chad added a comment.Dec 13 2015, 8:30 PM

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

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.

chad added a comment.Dec 13 2015, 8:37 PM

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?

chad added a comment.Dec 13 2015, 8:38 PM

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.

chad added a subscriber: aleb.

T9986 is reproducible:

  • Click "Create Task" in Maniphest, get told to log in.
  • Log in (as non community member)
  • Get redirected to the generic edit form with no permissions.
aleb removed a subscriber: aleb.Dec 15 2015, 4:50 PM
chad added a comment.EditedDec 16 2015, 5:18 PM

Confirmed via IRC:

  • Set "Can Edit Task Status" to Administrators
  • Have non-admins try to create a task
  • Get Sad panda no permissions dialog
epriestley closed this task as Resolved.Dec 16 2015, 7:04 PM
epriestley claimed this task.

The "Can Edit Task Status" thing is now covered in T10003. I'm going to spin the remaining errata out into a followup since most of this chatter is now obsolete.

urzds added a subscriber: urzds.Jul 12 2017, 11:11 AM