1. 22 Jun, 2020 2 commits
    • Ana Rute Mendes's avatar
      CCU: display RAG indicator and progress bar in task card · edf4171f
      Ana Rute Mendes authored
      Based on the custom field `std:maniphest:collabora:rag-status`
      display the RAG indicator in the task card as well as a progress
      bar that exposes the task children points.
      edf4171f
    • Daniel Stone's avatar
      LOCAL/UI: Project: Show review/CI status on workboard · ecb1b12d
      Daniel Stone authored
      On project workboard cards, also show the status of linked code reviews;
      both the review itself, and any attached Harbormaster CI buildables.
      
      This is already taken care of in the task-detail view by 45c740ac,
      and extends it to the workboard view. It should probably share more code
      with the task-detail view.
      
      It will not be accepted upstream in its current form; it was felt in
      https://secure.phabricator.com/T7076 discussion that performing multiple
      queries for each revision to get the current state was too much. This
      makes it exceedingly unlikely that doing the same number of queries for
      every task in a workboard would be acceptable.
      
      There was discussion of how to fix that, but it was essentially
      impossible, and explicitly discouraged for anyone to even try.
      ecb1b12d
  2. 19 Nov, 2019 1 commit
  3. 12 Sep, 2019 1 commit
    • epriestley's avatar
      Support "Subtype" in Herald · 3e601280
      epriestley authored
      Summary: See PHI1434. For objects that support subtypes and have subtypes configured, allow Herald rules to act on subtypes.
      
      Test Plan:
        - Configured task and project subtypes, wrote Herald rules, saw "Subtypes" as an option, saw appropriate typeahead values and detail page rendering.
        - Unconfigured project subtypes, saw field vanish from UI for new rules.
        - Wrote a "subtype"-depenent rule that added a comment, interacted with tasks of that subtype and a different subtype. Saw Herald act only on tasks with the correct subtype.
      
      Differential Revision: https://secure.phabricator.com/D20809
      3e601280
  4. 12 Mar, 2019 3 commits
    • epriestley's avatar
      Modularize workboard column orders · 9a8019d4
      epriestley authored
      Summary:
      Depends on D20267. Depends on D20268. Ref T10333. Currently, we support "Natural" and "Priority" orders, but a lot of the particulars are pretty hard-coded, including some logic in `ManiphestTask`.
      
      Although it's not clear that we'll ever put other types of objects on workboards, it seems generally bad that you need to modify `ManiphestTask` to get a new ordering.
      
      Pull the ordering logic out into a `ProjectColumnOrder` hierarchy instead, and let each ordering define the things it needs to work (name, icon, what headers look like, how different objects are sorted, and how to apply an edit when you drop an object under a header).
      
      Then move the existing "Natural" and "Priority" orders into this new hierarchy.
      
      This has a minor bug where using the "Edit" workflow to change a card's priority on a priority-ordered board doesn't fully refresh card/header order since the response isn't ordering-aware. I'll fix that in an upcoming change.
      
      Test Plan: Grouped workboards by "Natural" and "Priority", dragged stuff around within and between columns, grepped for all touched symbols.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333
      
      Differential Revision: https://secure.phabricator.com/D20269
      9a8019d4
    • 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
    • epriestley's avatar
      On Workboards, sort groups by "natural order", not subpriority · 46ed8d4a
      epriestley authored
      Summary:
      Depends on D20263. Ref T10333. I want to add groups like "Assignee" to workboards. This means you may have several tasks grouped under, say, "Alice".
      
      When you drag the bottom-most task under "Alice" to the top, what does that mean?
      
      Today, the only grouping is "Priority", and it means "change the task's secret/hidden global subpriority". However, this seems to generally be a somewhat-bad answer, and is quite complex. It also doesn't make much sense for an author grouping, since one task can't really be "more assigned" to Alice than another task.
      
      Users likely intend this operation to mean "move it, visually, with no other effects" -- that is, user intent is to shuffle sticky notes around on a board, not edit anything substantive. The meaning is probably something like "this is similar to other nearby tasks" or "maybe this is a good place to start", which we can't really capture with any top-level attribute.
      
      We could extend "subpriority" and give tasks a secret/hidden "sub-assignment strength" and so on, but this seems like a bad road to walk down. We'll also run into trouble later when subproject columns may appear on the board, and a user could want to put a task in different positions on different subprojects, conceivably.
      
      In the "Natural" order view, we already have what is probably a generally better approach for this: a task display order particular to the column, that just remembers where you put the sticky notes.
      
      Move away from "subpriority", and toward a world where we mostly keep sticky notes where you stuck them and move them around only when we have to. With no grouping, we still sort by "natural" order, as before. With priority grouping, we now sort by `<priority, natural>`. When you drag stuff around inside a priority group, we update the natural order.
      
      This means that moving cards around on a "priority" board will also move them around on a "natural" board, at least somewhat. I think this is okay. If it's not intuitive, we could give every ordering its own separate "natural" view, so we remember where you stuck stuff on the "priority" board but that doesn't affect the "Natural" board. But I suspect we won't need to.
      
      Test Plan:
        - Viewed and dragged a natural board.
        - Viewed and dragged a priority board.
        - Dragged within and between groups of 0, 1, and multiple items.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333
      
      Differential Revision: https://secure.phabricator.com/D20265
      46ed8d4a
  5. 09 Mar, 2019 2 commits
    • epriestley's avatar
      Make drag-and-drop on workboards interact with priority column headers · 40af472f
      epriestley authored
      Summary:
      Ref T10333. Ref T8135. Depends on D20247. Allow users to drag-and-drop cards on a priority-sorted workboard under headers, even if the header has no other cards.
      
      As of D20247, headers show up but they aren't really interactive. Now, you can drag cards directly underneath a header (instead of only between other cards). For example, if a column has only one "Wishlist" task, you may drag it under the "High", "Normal", or "Low" priority headers to select a specific priority.
      
      (Some of this code still feels a little rough, but I think it will generalize once other types of sorting are available.)
      
      Test Plan: Dragged cards within and between priority groups, saw appropriate priority edits applied in every case I could come up with.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333, T8135
      
      Differential Revision: https://secure.phabricator.com/D20248
      40af472f
    • epriestley's avatar
      Add priority group headers to workboard columns (display only) · 14a433c7
      epriestley authored
      Summary:
      Ref T10333. When workboards are ordered (for example, by priority), add headers to the various groups. Major goals are:
      
        - Allow users to drag-and-drop to set values that no cards currently have: for example, you can change a card priority to "normal" by dragging it under the "normal" header, even if no other cards in the column are currently "Normal".
        - Make future orderings more useful, particularly "order by assignee". We don't really have room to put the username on every card and it would create a fair amount of clutter, but we can put usernames in these headers and then reference them with just the profile picture. This also allows you to assign to users who are not currently assigned anything in a given column.
        - Make the drag-and-drop behavior more obvious by showing what it will do more clearly (see T8135).
        - Make things a little easier to scan in general: because space on cards is limited, some information isn't conveyed very clearly (for example, priority information is currently conveyed //only// through color, which can be hard to pick out visually and is probably not functional for users who need vision accommodations).
        - Maybe do "swimlanes": this is pretty much a "swimlanes" UI if we add whitespace at the bottom of each group so that the headers line up across all the columns (e.g., "Normal" is at the same y-axis position in every column as you scroll down the page). Not sold on this being useful, but it's just a UI adjustment if we do want to try it.
      
      NOTE: This only makes these headers work for display.
      
      They aren't yet recognized as targets by the drag list UI, so you can't drag cards into an empty group. I'll tackle that in a followup.
      
      Test Plan: {F6257686}
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T10333
      
      Differential Revision: https://secure.phabricator.com/D20247
      14a433c7
  6. 07 Mar, 2019 1 commit
  7. 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
  8. 28 Dec, 2018 1 commit
    • epriestley's avatar
      Allow objects to be put in an "MFA required for all interactions" mode, and... · d3c325c4
      epriestley authored
      Allow objects to be put in an "MFA required for all interactions" mode, and support "MFA required" statuses in Maniphest
      
      Summary:
      Depends on D19898. Ref T13222. See PHI873. Allow objects to opt into an "MFA is required for all edits" mode.
      
      Put tasks in this mode if they're in a status that specifies it is an `mfa` status.
      
      This is still a little rough for now:
      
        - There's no UI hint that you'll have to MFA. I'll likely add some hinting in a followup.
        - All edits currently require MFA, even subscribe/unsubscribe. We could maybe relax this if it's an issue.
      
      Test Plan:
        - Edited an MFA-required object via comments, edit forms, and most/all of the extensions. These prompted for MFA, then worked correctly.
        - Tried to edit via Conduit, failed with a reasonably comprehensible error.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13222
      
      Differential Revision: https://secure.phabricator.com/D19899
      d3c325c4
  9. 20 Dec, 2018 2 commits
    • epriestley's avatar
      Remove "getApplicationTransactionObject()" from ApplicationTransactionInterface · 11cf8f05
      epriestley authored
      Summary:
      Depends on D19919. Ref T11351. This method appeared in D8802 (note that "get...Object" was renamed to "get...Transaction" there, so this method was actually "new" even though a method of the same name had existed before).
      
      The goal at the time was to let Harbormaster post build results to Diffs and have them end up on Revisions, but this eventually got a better implementation (see below) where the Harbormaster-specific code can just specify a "publishable object" where build results should go.
      
      The new `get...Object` semantics ultimately broke some stuff, and the actual implementation in Differential was removed in D10911, so this method hasn't really served a purpose since December 2014. I think that broke the Harbormaster thing by accident and we just lived with it for a bit, then Harbormaster got some more work and D17139 introduced "publishable" objects which was a better approach. This was later refined by D19281.
      
      So: the original problem (sending build results to the right place) has a good solution now, this method hasn't done anything for 4 years, and it was probably a bad idea in the first place since it's pretty weird/surprising/fragile.
      
      Note that `Comment` objects still have an unrelated method with the same name. In that case, the method ties the `Comment` storage object to the related `Transaction` storage object.
      
      Test Plan: Grepped for `getApplicationTransactionObject`, verified that all remaining callsites are related to `Comment` objects.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T11351
      
      Differential Revision: https://secure.phabricator.com/D19920
      11cf8f05
    • epriestley's avatar
      Remove obsolete, no-op implementations of "willRenderTimeline()" · 937e88c3
      epriestley authored
      Summary:
      Depends on D19918. Ref T11351. In D19918, I removed all calls to this method. Now, remove all implementations.
      
      All of these implementations just `return $timeline`, only the three sites in D19918 did anything interesting.
      
      Test Plan: Used `grep willRenderTimeline` to find callsites, found none.
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T11351
      
      Differential Revision: https://secure.phabricator.com/D19919
      937e88c3
  10. 10 Dec, 2018 1 commit
    • epriestley's avatar
      Replace the informal "array" subtype map with a more formal "SubtypeMap" object · f0eefdd0
      epriestley authored
      Summary: Ref T13222. Ref T12588. See PHI683. To make "Create Subtask..." fancier, we need slightly more logic around subtype maps. Upgrade the plain old array into a proper object so it can have relevant methods, notably "get a list of valid child subtypes for some parent subtype".
      
      Test Plan: Created and edited tasks, changed task subtypes. Grepped for affected symbols (`newEditEngineSubtypeMap`, `newSubtypeMap`).
      
      Reviewers: amckinley
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T13222, T12588
      
      Differential Revision: https://secure.phabricator.com/D19852
      f0eefdd0
  11. 08 Feb, 2018 3 commits
    • epriestley's avatar
      Provide task closed date via Conduit API, data export pipeline, and in list UI · 4c4707e4
      epriestley authored
      Summary:
      Depends on D19037. Ref T4434. Adds closed date to `maniphest.search` and "Export Data".
      
      When a task has been closed, show the closed date with a checkmark in the UI instead of the modified date.
      
      Test Plan:
        - Exported data to CSV, saw close information.
        - Saw close information in `/maniphest/`.
        - Queried for close information via `maniphest.search`.
      
      Maniphest Tasks: T4434
      
      Differential Revision: https://secure.phabricator.com/D19038
      4c4707e4
    • epriestley's avatar
      Track closed date and closing user for tasks explicitly · f028aa6f
      epriestley authored
      Summary:
      Ref T4434. Although some of the use cases for this data are better fits for Facts, this data is reasonable to track separately.
      
      I have an approximate view of it already ("closed, ordered by date modified") that's useful to review things that were fixed recently. This lets us make that view more effective.
      
      This just adds (and populates) the storage. Followups will add Conduit, Export, Search, and UI support.
      
      This is slightly tricky because merges work oddly (see T13020).
      
      Test Plan:
        - Ran migration, checked database for sensible results.
        - Created a task in open/closed status, got the right database values.
        - Modified a task to close/open it, got the right values.
        - Merged an open task, got updates.
      
      Maniphest Tasks: T4434
      
      Differential Revision: https://secure.phabricator.com/D19037
      f028aa6f
    • 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
  12. 28 Aug, 2017 1 commit
    • epriestley's avatar
      Build a prototype fulltext engine ("Ferret") using only basic MySQL primitives · f97157e7
      epriestley authored
      Summary:
      Ref T12819. I gave this stuff a sweet code name because all the terms related to "fulltext" and "search" already mean 5 different things. It, uh, ferrets out documents for you?
      
      I'm building this to work a lot like the existing ngram index, which seems to work pretty well. If this sticks, it will auto-resolve the join issue (in T12443) by letting us do the entire thing locally in a JOIN and thus dodge a lot of mess.
      
      This index gets built alongside other indexes, but only shows up in the UI if you have prototypes enabled. If you do, it appears under the existing fulltext field in Maniphest. No existing functionality is affected or disrupted.
      
      NOTE: The query engine half of this is still EXTREMELY primitive, and this probably performs worse than the existing field for now. If this doesn't show obvious signs of being awful on `secure` I'll improve that in followup changes.
      
      Test Plan:
      Indexed my tasks, ran some simple queries, got the results I wanted, even for queries "ko", "k", "v0.1".
      
      {F5147746}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12819, T12443
      
      Differential Revision: https://secure.phabricator.com/D18484
      f97157e7
  13. 19 Jun, 2017 1 commit
    • epriestley's avatar
      Allow numeric constants to act as aliases for task priorities in the web UI <select /> · 474d528c
      epriestley authored
      Summary:
      Ref T12124. This is a fairly narrow fix for existing saved EditEngine forms with a default priority value.
      
      These saved forms have a numeric (or probably "string-numeric") default value, like "50". They lost their meaning after D18111, when "50" no longer appears in the dropdown. Instead, these forms all select the highest available priority.
      
      At time of writing, this form was broken on this install, for example:
      
      > https://secure.phabricator.com/transactions/editengine/maniphest.task/view/13/
      
      Additionally, `/task/edit/form/123/?priority=...` (for templating forms) stopped working with `priority=50`. This isn't nearly as important, but a larger and more sudden compatiblity break than we need to make.
      
      Add support for an "alias map" on `<select />` controls, so if the value comes in with something we don't recognize we'll treat it like some other value. Then alias all the numeric constants -- and other keywords -- to the right constants.
      
      This ended up only affecting the `<select />` control in the web UI.
      
      Test Plan:
        - On `stable`, created a form with "Priority: Low".
        - Before patch: form has "Priority: Unbreak Now!" on `master`.
        - After patch: form has "Priority: Low" again.
        - Used `?priority=25`, `?priority=wish`, `?priority=wishlist` to template forms: all forms worked.
      
      Reviewers: amckinley, chad
      
      Reviewed By: amckinley
      
      Maniphest Tasks: T12124
      
      Differential Revision: https://secure.phabricator.com/D18134
      474d528c
  14. 14 Jun, 2017 1 commit
    • Austin McKinley's avatar
      Use keywords instead of ints to update task priority in ManiphestEditEngine · 8008ade9
      Austin McKinley authored
      Summary: Fixes T12124. Changes `ManiphestEditEngine` to populate the select using priority keywords instead of the integer value. Marks `maniphest.querystatuses` as frozen. Adds a new Conduit method for fetching potential task statuses.
      
      Test Plan: Created tasks and changed their priorities, observed that transactions in the DB still have the same type (integers as strings). Invoked `maniphest.update` with `priority => '90'` and observed that it still works. Invoked `maniphest.edit` with `priority => 'unbreak'` and observed that it now works.
      
      Reviewers: #blessed_reviewers, epriestley
      
      Reviewed By: #blessed_reviewers, epriestley
      
      Subscribers: Korvin, epriestley
      
      Maniphest Tasks: T12124
      
      Differential Revision: https://secure.phabricator.com/D18111
      8008ade9
  15. 26 May, 2017 1 commit
    • epriestley's avatar
      Provide UI hints about task subtypes · 742c3a83
      epriestley authored
      Summary:
      Ref T12314. Open to counterdiffs / iterating / suggestions / skipping most or all of this, mostly just throwing this out there as a maybe-reasonable first pass.
      
      When a task has a subtype (like "Plant" or "Animal"), provide some hints on the task list, workboards, and task detail.
      
      To make these hints more useful, allow subtypes to have icons and colors.
      
      Also use these icons and colors in the typeahead tokens.
      
      The current rule is that we show the subtype if it's not the default subtype. Another rule we could use is "show the subtype if there's more than one subtype defined", but my guess is that most installs will mostly have something like "normal task" as the default subtype.
      
      Test Plan:
      The interfaces this affects are: task detail view, task list view, workboard cards, subtype typeahead.
      
      {F3539128}
      
      {F3539144}
      
      {F3539167}
      
      {F3539185}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Subscribers: johnny-bit, bbrdaric, benwick, fooishbar
      
      Maniphest Tasks: T12314
      
      Differential Revision: https://secure.phabricator.com/D17451
      742c3a83
  16. 06 Apr, 2017 1 commit
    • epriestley's avatar
      Replace Remarkup calls to `PhabricatorHash::digest()` with SHA256 · 3a362683
      epriestley authored
      Summary:
      Ref T12509. Many of the calls to HMAC+SHA1 are just to compute cachekeys for remarkup objects.
      
      Make these use HMAC+SHA256 instead. There is no downside to swapping these since they just cause a cache miss in the worst case.
      
      I also plan to get rid of `PhabricatorMarkupInterface` eventually, but this doesn't go that far.
      
      Test Plan: Browsed some different types of documents (tasks, legalpad documents, phame blogs / posts, pholio mocks, etc).
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12509
      
      Differential Revision: https://secure.phabricator.com/D17631
      3a362683
  17. 03 Apr, 2017 1 commit
    • epriestley's avatar
      Return task descriptions from "maniphest.search" · 009aff1a
      epriestley authored
      Summary:
      Fixes T12461. This returns the field as a dictionary with a `"raw"` value, so we could eventually do this if we want without breaking the API:
      
      ```
      {
        "type": "remarkup",
        "raw": "**raw**",
        "html": "<strong>raw</strong>",
        "text": "raw"
      }
      ```
      
      Test Plan: Called `maniphest.search`, reviewed output.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12461
      
      Differential Revision: https://secure.phabricator.com/D17603
      009aff1a
  18. 09 Mar, 2017 1 commit
    • epriestley's avatar
      Make "Can Interact" and logged-out users interact more gracefully · d0c648df
      epriestley authored
      Summary:
      Fixes T12378. Two minor issues here:
      
        - CAN_INTERACT on tasks uses "USER", but should just use the view policy, which may be more permissive ("PUBLIC").
        - CAN_INTERACT is currently prevented from being "PUBLIC" by additional safeguards. Define an explicit capability object for the permission which returns `true` from `shouldAllowPublicPolicySetting()`.
      
      Test Plan:
        - Viewed an unlocked task as a logged-out user, saw "login to comment" instead of "locked".
        - Viewed a locked task as a logged-out user, saw "locked".
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12378
      
      Differential Revision: https://secure.phabricator.com/D17485
      d0c648df
  19. 03 Mar, 2017 1 commit
    • epriestley's avatar
      Allow task statuses to "lock" them, preventing additional comments and interactions · 0e7a5623
      epriestley authored
      Summary:
      Ref T12335. See that task for discussion. Here are the behavioral changes:
      
        - Statuses can be flagged with `locked`, which means that tasks in that status are locked to further discussion and interaction.
        - A new "CAN_INTERACT" permission facilitates this. For most objects, "CAN_INTERACT" is just the same as "CAN_VIEW".
        - For tasks, "CAN_INTERACT" is everyone if the status is a normal status, and no one if the status is a locked status.
        - If a user doesn't have "Interact" permission:
          - They can not submit the comment form.
          - The comment form is replaced with text indicating "This thing is locked.".
          - The "Edit" workflow prompts them.
      
      This is a mixture of advisory and hard policy checks but sholuld represent a reasonable starting point.
      
      Test Plan: Created a new "Locked" status, locked a task. Couldn't comment, saw lock warning, saw lock prompt on edit. Unlocked a task.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12335
      
      Differential Revision: https://secure.phabricator.com/D17453
      0e7a5623
  20. 02 Mar, 2017 2 commits
    • epriestley's avatar
      Allow EditEngine forms for objects which support subtyping to have a subtype configured · b9d60d26
      epriestley authored
      Summary:
      Ref T12314. This adds a "Change Form Subtype" workflow to the EditEngine form configuration screen, for forms that edit/create objects which support subtyping (for now, only tasks).
      
      For example, this allows you to switch a form from being a "task" form to a "plant" or "animal" form.
      
      Doing this doesn't yet do anything useful or interesting. I'm also not showing it in the UI yet since I'm not sure what we should make that look like (presumably, we should just echo whatever UI we end up with on tasks).
      
      Test Plan:
        - Changed the subtype of a task form.
        - Verified that the "Change Subtype" action doesn't appear on other forms (for example, those for Pastes).
      
      {F3491374}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12314
      
      Differential Revision: https://secure.phabricator.com/D17442
      b9d60d26
    • epriestley's avatar
      Add "subtype" storage to Maniphest tasks · dc7ecf58
      epriestley authored
      Summary: Ref T12314. Provides a field on tasks for storing subtypes. Does nothing interesting yet.
      
      Test Plan:
        - Ran storage upgrade.
        - Created some tasks.
        - Looked in the database.
        - Used Conduit to query some tasks.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12314
      
      Differential Revision: https://secure.phabricator.com/D17441
      dc7ecf58
  21. 08 Jan, 2017 1 commit
    • epriestley's avatar
      Add a "columns" attachment to the maniphest.search API method · ad3745c8
      epriestley authored
      Summary:
      Ref T12074. This allows callers to identify which columns an object appears in (currently, always tasks).
      
      There are a few major cases:
      
        - Object is in a normal column: we return column information.
        - Object is in a proxy column (subproject or milestone). For example, when you look at the board for "Some Parent Project", the task might show up in a milestone column. I've chosen to not return anything in this case: you can figure out that the task is there by looking at the project structure, and this is kind of an internal artifact of the implementation and probably not useful to callers.
        - Project does not have a workboard: we return nothing.
      
      These seem fairly reasonable, I think?
      
      Test Plan:
        - Queried for tasks, using the "columns" attachment.
        - Dragged a task across a board, querying it repeatedly. Got expected results for normal column (the column), subprojects with no board (nothing), milestones with no board (nothing) and mielstones/subprojects with a board (the column on //that// board, only, not the proxy column on the parent).
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T12074
      
      Differential Revision: https://secure.phabricator.com/D17156
      ad3745c8
  22. 01 Jul, 2016 1 commit
  23. 22 Mar, 2016 1 commit
    • epriestley's avatar
      Introduce "bridged" objects · 47dedfb1
      epriestley authored
      Summary:
      Ref T10537. These are objects which are bound to some external object, like a Maniphest task which is a representation of a GitHub issue.
      
      This doesn't do much yet and may change, but my thinking is:
      
        - I'm putting these on-object instead of on edges because I think we want to actively change the UI for them (e.g., clearly call out that the object is bridged) but don't want every page to need to do extra queries in the common case where zero bridged objects exist anywhere in the system.
        - I'm making these one-to-one, more or less: an issue can't be bridged to a bunch of tasks, nor can a bunch of tasks be bridged to a single issue. Pretty sure this makes sense? I can't come up with any reasonable, realistic cases where you want a single GitHub issue to publish to multiple different tasks in Maniphest.
        - Technically, one type of each bridgable object could be bridged, but I expect this to never actually occur. Hopefully.
      
      Test Plan: Ran storage upgrade, loaded some pages.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Subscribers: Luke081515.2
      
      Maniphest Tasks: T10537
      
      Differential Revision: https://secure.phabricator.com/D15502
      47dedfb1
  24. 06 Mar, 2016 1 commit
  25. 11 Feb, 2016 2 commits
    • epriestley's avatar
      Expose task point counts in `maniphest.search` · 12f131c0
      epriestley authored
      Summary: Ref T4427.
      
      Test Plan: {F1104631}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T4427
      
      Differential Revision: https://secure.phabricator.com/D15244
      12f131c0
    • epriestley's avatar
      Don't adjust task priority after a workboard drag unless we need to · 968ac764
      epriestley authored
      Summary:
      Fixes T8197. Currently, if you priority-sort a workboard and drag a card to the top or bottom, we change the priority even if we do not need to.
      
      For example, if the lowest priority in a column is "Low", and you drag a "Wishlist" task underneath it, we incorrectly increase the priority of the task to "Low", when we do not actually need to touch it. This is bad/confusing.
      
      A similar thing happens when dragging a "High" priority task to the top of a column where the highest priority is currently "Normal".
      
      Test Plan:
        - Create a column with a "Normal" task.
        - Sort workboard by Priority.
        - Drag a "High" task above it. After patch: task still "High".
        - Drag a "Wishlist" task below it. After patch: task still "Wishlist".
      
      Also dragged a ton of tasks into the middle of other tasks.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T8197
      
      Differential Revision: https://secure.phabricator.com/D15240
      968ac764
  26. 10 Feb, 2016 2 commits
    • epriestley's avatar
      Restore column point counts to workboards · 1fb76655
      epriestley authored
      Summary: Ref T4427.
      
      Test Plan:
        - Dragged a 17 XP task from "Hunting" to "Slain".
        - Saw 17 XP move.
        - Level up!
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T4427
      
      Differential Revision: https://secure.phabricator.com/D15237
      1fb76655
    • epriestley's avatar
      Rewrite workboards to have way more bugs · 0bf35190
      epriestley authored
      Summary:
      Ref T4900. Briefly:
      
        - Much more layout and rendering is now done in Javascript.
        - This should otherwise be identical to the behavior at HEAD, except that:
          - editing a task and removing the current board from it no longer removes the task; and
          - points still don't work.
      
      However, this can now plausibly support realtime workboard updates and other complex state-based behaviors like points calculations in a future change.
      
      Test Plan:
        - Changed card covers.
        - Moved cards.
        - Sorted board by priority and natural.
        - Added new cards.
        - Edited cards in place.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T4900
      
      Differential Revision: https://secure.phabricator.com/D15234
      0bf35190
  27. 08 Feb, 2016 2 commits
    • epriestley's avatar
      Add a "points" field to tasks · e9f3807c
      epriestley authored
      Summary:
      Currently never read or written.
      
      Supports fractions.
      
      There's no such thing as an unsigned double so this also supports negative values, technically, although I'll eventually prevent this in the UI.
      
      Test Plan: `bin/storage upgrade`, then created and edited a task. Nothing was different.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Differential Revision: https://secure.phabricator.com/D15218
      e9f3807c
    • epriestley's avatar
      Remove three ancient columns from Maniphest tasks: attached, projectPHIDs, ccPHIDs · 32225d1d
      epriestley authored
      Summary:
      Before edges, we stored some of this stuff directly on tasks.
      
        - `attached` was migrated to edges in Jan 2013.
        - `projectPHIDs` was never used, as far as I can tell?
        - `ccPHIDs` was migrated away and dropped more than a year ago.
      
      None of these columns are used in modern code (instead, modern code uses edges).
      
      Test Plan: `grep`, browsed around, `bin/storage upgrade`, unit tests.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Differential Revision: https://secure.phabricator.com/D15216
      32225d1d
  28. 06 Feb, 2016 2 commits