1. 29 Mar, 2020 10 commits
  2. 10 Dec, 2019 1 commit
  3. 22 Aug, 2019 1 commit
  4. 31 Jul, 2019 2 commits
  5. 30 Jul, 2019 1 commit
    • epriestley's avatar
      When a task card is edited, emit update events for old boards and parent boards · 7d415350
      epriestley authored
      Summary:
      Ref T4900. When a card is edited, we currently emit an update notification for all the projects the task is tagged with. This isn't quite the right set:
      
        - We want to emit notifications for projects the task //was previously// tagged with, so it can be removed from boards it should no longer be part of.
        - We want to emit notifications for ancestors of projects the task is or was tagged with, so parent project boards can be updated.
        - However, we don't need to emit notifications for projects that don't actually have workboards.
      
      Adjust the notification set to align better to these rules.
      
      Test Plan:
        - Removal of Parent Project: Edited a task on board "A > B", removing the "B" project tag. Saw board A update in another window.
        - Normal Update: Edited a task title on board X, saw board X update in another window.
        - Used `bin/aphlict debug` to inspect the notification set, saw generally sensible-seeming data going over the wire.
      
      Reviewers: amckinley
      
      Maniphest Tasks: T4900
      
      Differential Revision: https://secure.phabricator.com/D20680
      7d415350
  6. 18 Jul, 2019 1 commit
    • epriestley's avatar
      Make workboard real-time updates mostly work · 17caecdd
      epriestley authored
      Summary:
      Depends on D20654. Ref T4900. When a task is edited, emit a "workboards" event for all boards it appears on (in a future change, this should also include all boards it //previously// appeared on, and all parents of both sets of boards -- but I'm just getting things working for now).
      
      When we receive a "workboards" event, check if the visible board should be updated.
      
      Aphlict has a complicated intra-window leader/follower election system which could let us process this update event exactly once no matter how many windows a user has open with the same workboard. I'm not trying to do any of this since it seems fairly rare. It makes sense for events like "you have new notifications" where we don't want to generate 100 Ajax calls if the user has 100 windows open, but very few users seem likely to have 100 copies of the same workboard open.
      
      Test Plan:
        - Ran `bin/aphlict debug`.
        - Opened workboard A in two windows, X and Y.
        - Edited and moved tasks in window X.
        - Saw "workboards" messages in the Aphlict log.
        - Saw window Y update in nearly-real-time (locally, this is fast enough that it feels instantaneous).
      
      Then:
      
        - Stopped the Aphlcit server.
        - Edited a task.
        - Started the Aphlict server.
        - Saw window Y update after a few moments (i.e., update in response to a reconnect).
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T4900
      
      Differential Revision: https://secure.phabricator.com/D20656
      17caecdd
  7. 17 Jul, 2019 1 commit
    • epriestley's avatar
      Move "BoardResponseEngine" toward a more comprehensive update model · 1ee6ecf3
      epriestley authored
      Summary:
      Depends on D20639. Ref T4900. Currently, "BoardResponseEngine" has a `setObjectPHID()` method. This is called after edit operations to mean "we just edited object X, so we know it needs to be updated".
      
      Move toward `setUpdatePHIDs(...)` in all cases, with `setUpdatePHIDs(array(the-object-we-just-edited))` as a special case of that. After this change, callers pass:
      
        - An optional list of PHIDs they know need to be updated on the client. Today, this is always be a card we just edited (on edit/move flows), or a sort of made-up list of PHIDs for the moment (when you press "R"). In the future, the "R" endpoint will do a better job of figuring out a more realistic update set.
        - An optional list of PHIDs currently visible on the client. This is used to update ordering details and mark cards for removal. This is currently passed by edit/move, but not by pressing "R" (it will be in the future).
        - An optional list of objects. The "R" workflow has to load these anyway, so we can save a couple queries by letting callers pass them. For now, the edit/move flows still rely on the engine to figure out what it needs to load.
      
      This does very little to actually change client behavior, it mostly just paves the way for the next update to the "R" workflow to make it handle add/remove cases properly.
      
      Test Plan:
        - Edited and moved cards on a workboard.
        - Pressed "R" to reload a workboard.
      
      Neither of these operations seem any worse off than they were before. They still don't fully work:
      
        - When you edit a card and delete the current workboard project from it, it remains visible. This is also the behavior on `master`. This is sort of intentional since we don't necessarily want to make these cards suddenly disappear? Ideally, we would probably have some kind of "tombstone" state where the card can still be edited but can't be dragged, and the next explicit user interaction would clean up old tombstones. This interaction is very rare and I don't think it's particularly important to specialize.
        - When a card is removed from the board, "R" can't currently figure out that it should be removed from the client. This is because the client does not yet pass a "visiblePHIDs" state. It will in an upcoming change.
        - The "R" flow always sends a full set of card updates, and can not yet detect that some cards have not changed.
        - There's a TODO, but some ordering stuff isn't handled yet.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T4900
      
      Differential Revision: https://secure.phabricator.com/D20652
      1ee6ecf3
  8. 18 Jun, 2019 1 commit
  9. 30 May, 2019 1 commit
    • epriestley's avatar
      Add a "View Task" button to HTML mail from Maniphest · 9a32a563
      epriestley authored
      Summary:
      See downstream <https://phabricator.wikimedia.org/T1050>. Some time ago, we added a "View Revision" button to Differential mail. This hasn't created any problems and generally seems good / desirable.
      
      It isn't trivial to just add everywhere since we need a translation string in each case, but at least add it to Maniphest for now. Going forward, we can fill in more applications as they come up.
      
      Test Plan:
      Used `bin/mail show-outbound --id <x> --dump-html`:
      
      {F6470461}
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Differential Revision: https://secure.phabricator.com/D20561
      9a32a563
  10. 27 Mar, 2019 1 commit
    • epriestley's avatar
      On workboards, link ancestor project breadcrumbs to their workboards · ee54e71b
      epriestley authored
      Summary:
      Ref T13269. Currently, if you're on a milestone workboard like this:
      
      > Projects > Parent > Milestone > Workboard
      
      The "Parent" link goes to the parent profile. More often, I want it to go to the parent workboard. Try doing that? This is kind of one-off but I suspect it's a better rule.
      
      Also, consolidate one billion manual constructions of "/board/" URIs.
      
      Test Plan: Viewed a milestone workboard, clicked the parent link, ended up on the parent workboard.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13269
      
      Differential Revision: https://secure.phabricator.com/D20331
      ee54e71b
  11. 26 Mar, 2019 1 commit
    • epriestley's avatar
      When moving cards on workboards, treat before/after cards as optional hints,... · 6138e509
      epriestley authored
      When moving cards on workboards, treat before/after cards as optional hints, not strict requirements
      
      Summary:
      Depends on D20320. Ref T12175. Ref T13074. Currently, when you move a card between columns, the internal transaction takes exactly one `afterPHID` or `beforePHID` and moves the card before or after the specified card.
      
      This is a fairly strict interpretation and causes a number of practical issues, mostly because the user/client view of the board may be out of date and the card they're dragging before or after may no longer exist: another user might have moved or hidden it between the last client update and the current time.
      
      In T13074, we also run into a more subtle issue where a card that incorrectly appears in multiple columns fatals when dropped before or after itself.
      
      In all cases, a better behavior is just to complete the move and accept that the position may not end up exactly like the user specified. We could prompt the user instead:
      
      > You tried to drop this card after card X, but that card has moved since you last loaded the board. Reload the board and try again.
      
      ...but this is pretty hostile and probably rarely/never what the user wants.
      
      Instead, accept a list of before/after PHIDs and just try them until we find one that works, or accept a default position if none work. In essentially all cases, this means that the move "just works" like users expect it to instead of fataling in a confusing/disruptive/undesirable (but "technically correct") way.
      
      (A followup will make the client JS send more beforePHIDs/afterPHIDs so this works more often.)
      
      We could eventually add a "strict" mode in the API or something if there's some bot/API use case for precise behavior here, but I suspect none exist today or are (ever?) likely to exist in the future.
      
      Test Plan:
        - (T13074) Inserted two conflicting rows to put a card on two columns on the same board. Dropped one version of it underneath the other version. Before: confusing fatal. After: cards merge sensibly into one consistent card.
        - (T12175) Opened two views of a board. Moved card A to a different column on the first view. On the second view, dropped card B under card A (still showing in the old column). Before: confusing fatal. After: card ended up in the right column in approximately the right place, very reasonably.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13074, T12175
      
      Differential Revision: https://secure.phabricator.com/D20321
      6138e509
  12. 18 Mar, 2019 1 commit
    • epriestley's avatar
      When performing complex edits, pause sub-editors before they publish to... · a6fd8f04
      epriestley authored
      When performing complex edits, pause sub-editors before they publish to propagate "Must Encrypt" and other state
      
      Summary:
      See PHI1134. Previously, see T13082 and D19969 for some sort-of-related stuff.
      
      Currently, edits work roughly like this:
      
        - Suppose we're editing object X, and we're also going to edit some other object, Y, because X mentioned Y or the edit is making X a child or parent of Y, or unblocking Y.
        - Do the actual edit to X, including inverse edits ("alice mentioned Y on X.", "alice added a child revision: X", etc) which apply to Y.
        - Run Herald rules on X.
        - Publish the edit to X.
      
      The "inverse edits" currently do this whole process inline, in a sub-editor. So the flow expands like this:
      
        - Begin editing X.
        - Update properties on X.
          - Begin inverse-edge editing Y.
          - Update properties on Y.
          - Run (actually, skip) Herald rules on Y.
          - Publish edits to Y.
        - Run Herald rules on X.
        - Publish edits to X.
      
      Notably, the "Y" stuff publishes before the "X" Herald rules run. This creates potential problems:
      
        - Herald rules may change the name or visibility policy of "X", but we'll publish mail about it via the edits to Y before those edits apply. This is a problem only in theory, we don't ship any upstream rules like this today.
        - Herald rules may "Require Secure Mail", but we won't know that at the time we're building mail about the indirect change to "Y". This is a problem in practice.
      
      Instead, switch to this new flow, where we stop the sub-editors before they publish, then publish everything at the very end once all the edits are complete:
      
        - Begin editing X.
        - Update properties on X.
          - Begin inverse-edge editing Y.
          - Update properties on Y.
          - Skip Herald on Y.
        - Run Herald rules on X.
        - Publish X.
          - Publish all child-editors of X.
            - Publish Y.
      
      Test Plan:
        - Created "Must Encrypt" Herald rules for Tasks and Revisions.
        - Edited object "A", an object which the rules applied to directly, and set object "B" (a different object which the rules did not hit) as its parent/child and/or unblocked it.
        - In `bin/mail list-outbound`, saw:
          - Mail about object "A" all flagged as "Must Encrypt".
          - Normal mail from object B not flagged "Must Encrypt".
          - Mail from object B about changing relationships to object A flagged as "Must Encrypt".
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Differential Revision: https://secure.phabricator.com/D20283
      a6fd8f04
  13. 12 Mar, 2019 2 commits
    • epriestley's avatar
      When creating or editing a card on a sorted/grouped workboard, adjust headers appropriately · 21dd79b3
      epriestley authored
      Summary:
      Depends on D20270. Ref T10333. If you create a task with a new owner, or edit a task and change the priority/owner, we want to move it (and possibly create a new header) when the response comes back.
      
      Make sure the response includes the appropriate details about the object's header and position.
      
      Test Plan:
        - Grouped by Owner.
        - Created a new task with a new owner, saw the header appear.
        - Edited a task and changed it to give it a new owner, saw the header appear.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333
      
      Differential Revision: https://secure.phabricator.com/D20271
      21dd79b3
    • epriestley's avatar
      Remove all readers/writers for task "subpriority" · 4bad6bc4
      epriestley authored
      Summary:
      Depends on D20265. Ref T10333. Now that neither task lists nor workboards use subpriority, we can remove all the readers and writers.
      
      I'm not actually getting rid of the column data yet, but anticipate doing that in a future change.
      
      Note that the subpriority algorithm (removed here) is possibly better than the "natural order" algorithm still in use. It's a bit more clever, and likely performs far fewer writes. I might make the "natural order" code use an algorithm more similar to the "subpriority" algorithm in the future.
      
      Test Plan: Grepped for `subpriority`.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333
      
      Differential Revision: https://secure.phabricator.com/D20266
      4bad6bc4
  14. 16 Feb, 2019 1 commit
    • epriestley's avatar
      Allow task statuses to specify that either "comments" or "edits" are "locked" · 3058cae4
      epriestley authored
      Summary:
      Ref T13249. See PHI1059. This allows "locked" in `maniphest.statuses` to specify that either "comments" are locked (current behavior, advisory, overridable by users with edit permission, e.g. for calming discussion on a contentious issue or putting a guard rail on things); or "edits" are locked (hard lock, only task owner can edit things).
      
      Roughly, "comments" is a soft/advisory lock. "edits" is a hard/strict lock. (I think both types of locks have reasonable use cases, which is why I'm not just making locks stronger across the board.)
      
      When "edits" are locked:
      
        - The edit policy looks like "no one" to normal callers.
        - In one special case, we sneak the real value through a back channel using PolicyCodex in the specific narrow case that you're editing the object. Otherwise, the policy selector control incorrectly switches to "No One".
        - We also have to do a little more validation around applying a mixture of status + owner transactions that could leave the task uneditable.
      
      For now, I'm allowing you to reassign a hard-locked task to someone else. If you get this wrong, we can end up in a state where no one can edit the task. If this is an issue, we could respond in various ways: prevent these edits; prevent assigning to disabled users; provide a `bin/task reassign`; uh maybe have a quorum convene?
      
      Test Plan:
        - Defined "Soft Locked" and "Hard Locked" statues.
        - "Hard Locked" a task, hit errors (trying to unassign myself, trying to hard lock an unassigned task).
        - Saw nice new policy guidance icon in header.
      
      {F6210362}
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13249
      
      Differential Revision: https://secure.phabricator.com/D20165
      3058cae4
  15. 18 Jan, 2019 1 commit
    • epriestley's avatar
      Remove "metamta.*.subject-prefix" options · c125ab7a
      epriestley authored
      Summary:
      In ~2012, the first of these options was added because someone who hates dogs and works at Asana also hated `[Differential]` in the subject line. The use case there was actually //removing// the text, not changing it, but I made the prefix editable since it seemed like slightly less of a one-off.
      
      These options are among the dumbest and most useless config options we have and very rarely used, see T11760. A very small number of instances have configured one of these options.
      
      Newer applications stopped providing these options and no one has complained.
      
      You can get the same effect with `translation.override`. Although I'm not sure we'll keep that around forever, it's a reasonable replacement today. I'll call out an example in the changelog to help installs that want to preserve this option.
      
      If we did want to provide this, it should just be in {nav Applications > Settings} for each application, but I think it's wildly-low-value and "hack via translations" or "local patch" are entirely reasonable if you really want to change these strings.
      
      Test Plan: Grepped for `subject-prefix`.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Differential Revision: https://secure.phabricator.com/D19993
      c125ab7a
  16. 12 Dec, 2018 1 commit
  17. 05 Dec, 2018 1 commit
  18. 28 Nov, 2018 1 commit
    • epriestley's avatar
      Allow "Change Subtype" to be selected from the comment action stack · 2f11001f
      epriestley authored
      Summary:
      Ref T13222. See PHI683. Currently, you can "Change subtype..." via Conduit and the bulk editor, but not via the comment action stack or edit forms.
      
      In PHI683 an install is doing this often enough that they'd like it to become a first-class action. I've generally been cautious about pushing this action to become a first-class action (there are some inevitable rough edges and I don't want to add too much complexity if there isn't a use case for it) but since we have evidence that users would find it useful and nothing has exploded yet, I'm comfortable taking another step forward.
      
      Currently, `EditEngine` has this sort of weird `setIsConduitOnly()` method. This actually means more like "this doesn't show up on forms". Make it better align with that. In particular, a "conduit only" field can already show up in the bulk editor, which is goofy. Change this to `setIsFormField()` and convert/simplify existing callsites.
      
      Test Plan:
      There are a lot of ways to reach EditEngine so this probably isn't entirely exhaustive, but I think I got pretty much anything which is likely to break:
      
      - Searched for `setIsConduitOnly()` and `getIsConduitOnly()`, converted all callsites to `setIsFormField()`.
      - Searched for `setIsLockable()`, `setIsReorderable()` and `setIsDefaultable()` and aligned these calls to intent where applicable.
      - Created an Almanac binding.
      - Edited an Almanac binding.
      - Created an Almanac service.
      - Edited an Almanac service.
      - Edited a binding property.
      - Deleted a binding property.
      - Created and edited a badge.
      - Awarded and revoked a badge.
      - Created and edited an event.
      - Made an event recurring.
      - Created and edited a Conpherence thread.
      - Edited and updated the diff for a revision.
      - Created and edited a repository.
      - Created and disabled repository URIs.
      - Created and edited a blueprint.
      - Created and edited tasks.
      - Created a paste, edited/archived a paste.
      - Created/edited/archived a package.
      - Created/edited a project.
      - Made comments.
      - Moved tasks on workboards via comment action stack.
      - Changed task subtype via comment action stack.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13222
      
      Differential Revision: https://secure.phabricator.com/D19842
      2f11001f
  19. 15 Nov, 2018 1 commit
  20. 13 Nov, 2018 1 commit
    • epriestley's avatar
      Update PhabricatorLiskDAO::chunkSQL() for new %Q semantics · da40f807
      epriestley authored
      Summary:
      Ref T13217. This method is slightly tricky:
      
        - We can't safely return a string: return an array instead.
        - It no longer makes sense to accept glue. All callers use `', '` as glue anyway, so hard-code that.
      
      Then convert all callsites.
      
      Test Plan: Browsed around, saw fewer "unsafe" errors in error log.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13217
      
      Differential Revision: https://secure.phabricator.com/D19784
      da40f807
  21. 05 Nov, 2018 1 commit
  22. 16 Aug, 2018 1 commit
    • epriestley's avatar
      Remove deprecated Maniphest "Can Edit <Specific Property>" capabilities · 296bf046
      epriestley authored
      Summary:
      Depends on D19579. Fixes T10003. These have been deprecated with a setup warning about their impending removal for about two and a half years.
      
      Ref T13164. See PHI642. My overall goal here is to simplify how we handle transactions which have special policy behaviors. In particular, I'm hoping to replace `ApplicationTransactionEditor->requireCapabilities()` with a new, more clear policy check.
      
      A problem with `requireCapabilities()` is that it doesn't actually enforce any policies in almost all cases: the default is "nothing", not CAN_EDIT. So it ends up looking like it's the right place to specialize policy checks, but it usually isn't.
      
      For "Disable", I need to be able to weaken the check selectively (you can disable users if you have the permission, even if you can't edit them otherwise). We have a handful of other edits which work like this (notably, leaving and joining projects) but they're very rare.
      
      Test Plan: Grepped for all removed classes. Edited a Maniphest task.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13164, T10003
      
      Differential Revision: https://secure.phabricator.com/D19581
      296bf046
  23. 08 Feb, 2018 2 commits
    • epriestley's avatar
      Remove all "originalTitle"/"originalName" fields from objects · aa74af19
      epriestley authored
      Summary:
      Depends on D19012. Ref T13053. In D19012, I've changed "Thread-Topic" to always use PHIDs.
      
      This change drops the selective on-object storage we have to track the original, human-readable title for objects.
      
      Even if we end up backing out the "Thread-Topic" change, we'd be better off storing this in a table in the Mail app which just has `<objectPHID, first subject we used when sending mail for that object>`, since then we get the right behavior without needing every object to have this separate field.
      
      Test Plan: Grepped for `original`, `originalName`, `originalTitle`, etc.
      
      Reviewers: amckinley
      
      Maniphest Tasks: T13053
      
      Differential Revision: https://secure.phabricator.com/D19013
      aa74af19
    • epriestley's avatar
      Use object PHIDs for "Thread-Topic" headers in mail · f090fa74
      epriestley authored
      Summary:
      Depends on D19009. Ref T13053. For "Must Encrypt" mail, we must currently strip the "Thread-Topic" header because it sometimes contains sensitive information about the object.
      
      I don't actually know if this header is useful or anyting uses it. My understanding is that it's an Outlook/Exchange thing, but we also implement "Thread-Index" which I think is what Outlook/Exchange actually look at. This header may have done something before we implemented "Thread-Index", or maybe never done anything. Or maybe older versions of Excel/Outlook did something with it and newer versions don't, or do less. So it's possible that an even better fix here would be to simply remove this, but I wasn't able to convince myself of that after Googling for 10 minutes and I don't think it's worth hours of installing Exchange/Outlook to figure out. Instead, I'm just trying to simplify our handling of this header for now, and maybe some day we'll learn more about Exchange/Outlook and can remove it.
      
      In a number of cases we already use the object monogram or PHID as a "Thread-Topic" without users ever complaining, so I think that if this header is useful it probably isn't shown to users, or isn't shown very often (e.g., only in a specific "conversation" sub-view?). Just use the object PHID (which should be unique and stable) as a thread-topic, everywhere, automatically.
      
      Then allow this header through for "Must Encrypt" mail.
      
      Test Plan: Processed some local mail, saw object PHIDs for "Thread-Topic" headers.
      
      Reviewers: amckinley
      
      Maniphest Tasks: T13053
      
      Differential Revision: https://secure.phabricator.com/D19012
      f090fa74
  24. 31 Jan, 2018 1 commit
  25. 22 Jan, 2018 1 commit
  26. 19 Jan, 2018 3 commits
    • epriestley's avatar
      Support "Assign To" in Maniphest bulk editor · 91a78db9
      epriestley authored
      Summary:
      Ref T13025. See PHI173. This supports the "Assign to" field in the new editor.
      
      This is very slightly funky: to unassign tasks, you need to leave the field blank. I have half a diff to fix this, but the way the `none()` token works in the default datasource is odd so it needs a separate datasource. I'm punting on this for now since it works, at least, and isn't //completely// unreasonable.
      
      This also simplifies some EditEngine stuff a little. Notably:
      
        - I reorganized EditType construction slightly so subclasses can copy/paste a little bit less.
        - EditType had `field` and `editField` properties which had the same values. I canonicalized on `editField` and made this value set a little more automatically.
      
      Test Plan: Used bulk editor to reassign some tasks. By leaving the field blank, unassigned tasks.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13025
      
      Differential Revision: https://secure.phabricator.com/D18874
      91a78db9
    • epriestley's avatar
      Restore bulk edit support for remarkup fields (description, add comment) · 687fada5
      epriestley authored
      Summary:
      Depends on D18866. Ref T13025. Fixes T12415. This makes the old "Add Comment" action work, and adds support for a new "Set description to" action (possibly, I could imagine "append description" being useful some day, maybe).
      
      The implementation is just a `<textarea />`, not a whole fancy remarkup box with `[Bold] [Italic] ...` buttons, preview, typeaheads, etc. It would be nice to enrich this eventually but doing the rendering in pure JS is currently very involved.
      
      This requires a little bit of gymnastics to get the transaction populated properly, and adds some extra validation since we need some code there anyway.
      
      Test Plan:
        - Changed the description of a task via bulk editor.
        - Added a comment to a task via bulk editor.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13025, T12415
      
      Differential Revision: https://secure.phabricator.com/D18867
      687fada5
    • epriestley's avatar
      Support "select" types in bulk editor (status, priority) · bf1ac701
      epriestley authored
      Summary: Depends on D18864. Ref T13025. Adds bulk edit support back for "status" and "priority" using `<select />` controls.
      
      Test Plan:
      Used bulk editor to change status and priority for tasks.
      
      {F5374436}
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13025
      
      Differential Revision: https://secure.phabricator.com/D18866
      bf1ac701