1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-11 16:16:14 +01:00
Commit graph

184 commits

Author SHA1 Message Date
epriestley
2218caee0f Reduce the amount of boilerplate that implementing FerretInterface requires
Summary:
See brief discussion in D18554. All the index tables are the same for every application (and, at this point, seem unlikely to change) and we never actually pass these objects around (they're only used internally).

In some other cases (like Transactions) not every application has the same tables (for example, Differential has extra field for inline comments), and/or we pass the objects around (lots of stuff uses `$xactions` directly).

However, in this case, and in Edges, we don't interact with any representation of the database state directly in much of the code, and it doesn't change from application to application.

Just automatically define document, field, and ngram tables for anything which implements `FerretInterface`. This makes the query and index logic a tiny bit messier but lets us delete a ton of boilerplate classes.

Test Plan: Indexed objects, searched for objects. Same results as before with much less code. Ran `bin/storage upgrade`, got a clean bill of health.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T12819

Differential Revision: https://secure.phabricator.com/D18559
2017-09-07 13:23:31 -07:00
epriestley
f97157e7ed Build a prototype fulltext engine ("Ferret") using only basic MySQL primitives
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
2017-08-28 14:52:59 -07:00
epriestley
474d528c3b Allow numeric constants to act as aliases for task priorities in the web UI <select />
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
2017-06-19 14:06:34 -07:00
Austin McKinley
8008ade9af Use keywords instead of ints to update task priority in ManiphestEditEngine
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
2017-06-14 14:43:03 -07:00
epriestley
995c1503e7 Hide "X created Y, a subtask of P." feed stories again
Summary: Fixes T12787. Modular Transactions don't actually support `shouldHideForFeed()`. I'll add some discussion to the task.

Test Plan: Created a subtask, saw no more "X reopened Y, a subtask of P" feed story.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T12787

Differential Revision: https://secure.phabricator.com/D18058
2017-06-01 08:08:24 -07:00
epriestley
742c3a834f Provide UI hints about task subtypes
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
2017-05-26 13:58:41 -07:00
Chad Little
d6a620be45 Update Maniphest for modular transactions
Summary: Ref T12671. This modernized Maniphest transactions to modular transactions.

Test Plan:
- Create Task
- Edit Task
- Raise Priority
- Change Status
- Merge as a duplicate
- Create Subtask
- Claim Task
- Assign Project
- Move on Workboard
- Set a cover image
- Assign story points
- Change story points
- Generate lots via lipsum
- Bulk edit tasks
- Leave comments
- Award Token

I'm sure I'm missing something.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: hazelyang, Korvin

Maniphest Tasks: T12671

Differential Revision: https://secure.phabricator.com/D17844
2017-05-15 10:29:06 -07:00
epriestley
3a3626834e Replace Remarkup calls to PhabricatorHash::digest() with SHA256
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
2017-04-06 15:43:18 -07:00
epriestley
009aff1a23 Return task descriptions from "maniphest.search"
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
2017-04-02 17:44:22 -07:00
epriestley
d0c648dfa5 Make "Can Interact" and logged-out users interact more gracefully
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
2017-03-09 08:50:57 -08:00
epriestley
0e7a5623e3 Allow task statuses to "lock" them, preventing additional comments and interactions
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
2017-03-02 16:57:10 -08:00
epriestley
4a061b1def When an object which supports subtypes is created, set its subtype to the creating form's subtype
Summary:
Ref T12314. If you set a form to have the "plant" subtype, then create a task with it, save "plant" as the task subtype.

For Conduit, the default subtype is used by default, but a new "subtype" transaction is exposed. You can apply this transaction at create time to create an object of a certain subtype, or at any later time to change the subtype of an object.

This still doesn't do anything particularly useful or interesting.

Test Plan:
  - Created a non-subtyped object (a Paste).
  - Created "task" and "plant" tasks via different forms.
  - Created "default" and "plant" tasks via Conduit.
  - Changed the subtype of a task via Conduit.
  - Tried to set a bad subtype.

{F3492061}

{F3492066}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T12314

Differential Revision: https://secure.phabricator.com/D17443
2017-03-02 04:18:23 -08:00
epriestley
b9d60d2653 Allow EditEngine forms for objects which support subtyping to have a subtype configured
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
2017-03-02 04:18:06 -08:00
epriestley
dc7ecf5875 Add "subtype" storage to Maniphest tasks
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
2017-03-02 04:17:47 -08:00
epriestley
7448cb0c3a Replace exciting fantasy word "subtasktask" with plain old "subtask"
Summary: Fixes T12284. This isn't actually a word.

Test Plan: Read carefully.

Reviewers: chad, avivey

Reviewed By: avivey

Maniphest Tasks: T12284

Differential Revision: https://secure.phabricator.com/D17373
2017-02-17 06:08:55 -08:00
epriestley
ad3745c801 Add a "columns" attachment to the maniphest.search API method
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
2017-01-08 13:18:01 -08:00
epriestley
0a132e468f Render parent and child tasks in Maniphest with a graph trace
Summary: Ref T4788. This seems reasonable locally, but not sure how it will feel on real data. Might need some tweaks, or might just be a terrible idea.

Test Plan: {F1708059}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4788

Differential Revision: https://secure.phabricator.com/D16214
2016-07-01 10:41:07 -07:00
epriestley
2cb779575d Split "Edit Blocking Tasks" into "Edit Parent Tasks" and "Edit Subtasks"
Summary:
Ref T11179. This splits "Edit Blocking Tasks" into two options now that we have more room ("Edit Parent Tasks", "Edit Subtasks").

This also renames "Blocking" tasks to "Subtasks", and "Blocked" tasks to "Parent" tasks. My goals here are:

  - Make the relationship direction more clear: it's more clear which way is up with "parent" and "subtask" at a glance than with "blocking" and "blocked" or "dependent" and "dependency".
  - Align language with "Create Subtask".
  - To some small degree, use more flexible/general-purpose language, although I haven't seen any real confusion here.

Fixes T6815. I think I narrowed this down to two issues:

  - Just throwing a bare exeception (we now return a dialog explicitly).
  - Not killing open transactions when the cyclec check fails (we now kill them).

Test Plan:
  - Edited parent tasks.
  - Edited subtasks.
  - Tried to introduce graph cycles, got a nice error dialog.

{F1697087}

{F1697088}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6815, T11179

Differential Revision: https://secure.phabricator.com/D16166
2016-06-22 11:20:38 -07:00
epriestley
65634781b4 Don't re-mention users for comment edits
Summary:
Ref T11035. This only fixes half of the issue: comment editing has been fixed, but normal transactions which edit things like descriptions haven't yet.

The normal edits aren't fixed because the "oldValues" are populated too late. The code should start working once they get populated sooner, but I don't want to jump the gun on that since it'll probably have some spooky effects. I have some other transaction changes coming down the pipe which should provide a better context for testing "oldValue" population order.

Test Plan:
  - Mentioned `@dog` in a comment.
  - Removed `@dog` as a subscriber.
  - Edited the comment, adding some unrelated text at the end (e.g., fixing a typo).
    - Before change: `@dog` re-added as subscriber.
    - After change: no re-add.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T11035

Differential Revision: https://secure.phabricator.com/D16108
2016-06-13 13:57:59 -07:00
epriestley
86b08514ab Merge TYPE_PROJECT_COLUMNS and TYPE_COLUMN transactions into a more general TYPE_COLUMNS transaction
Summary:
Ref T6027. We currently have two different transaction types:

  - `TYPE_PROJECT_COLUMNS` does most of the work, but has a sort of weird structure and isn't really suitable for API use.
  - `TYPE_COLUMN` is this weird, junk transaction which mostly just creates the other transaction.

Merge them into a single higher-level `TYPE_COLUMNS` transaction which works properly and has a sensible structure and comprehensive error checking.

Remaining work here:

  - I've removed the old rendering logic, but not yet added new logic. I need to migrate the old transaction types and add new rendering logic.
  - Although the internal representation is now //suitable// for use in the API, it isn't properly exposed yet.

Test Plan:
  - Created tasks into a column.
  - Ran unit tests.
  - Moved tasks between columns.
  - Will perform additional testing in followups.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6027

Differential Revision: https://secure.phabricator.com/D15634
2016-04-06 09:13:31 -07:00
epriestley
47dedfb152 Introduce "bridged" objects
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
2016-03-22 15:06:57 -07:00
epriestley
99bc1b05d7 Use more explicit language for unassigning tasks
Summary:
Ref T10493.

  - Call this action "Unassigned" instead of "Up For Grabs", since the latter implies that it's OK for anyone to grab it, which is a social/context thing that we probably shouldn't assume.
  - Show who a task was previously assigned to in the transaction.

The text is a little clunky, yell if you've got a better wording? Or maybe I'll come up with something.

Test Plan: {F1166299}

Reviewers: chad

Reviewed By: chad

Subscribers: cburroughs

Maniphest Tasks: T10493

Differential Revision: https://secure.phabricator.com/D15454
2016-03-10 17:39:06 -08:00
epriestley
abb4c03b47 Remove shouldShowSubscribersProperty() from SubscribableInterface
Summary:
Every caller returns `true`. This was added a long time ago for Projects, but projects are no longer subscribable.

I don't anticipate needing this in the future.

Test Plan: Grepped for this method.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15409
2016-03-06 06:01:36 -08:00
epriestley
12f131c064 Expose task point counts in maniphest.search
Summary: Ref T4427.

Test Plan: {F1104631}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4427

Differential Revision: https://secure.phabricator.com/D15244
2016-02-11 11:26:17 -08:00
epriestley
968ac76453 Don't adjust task priority after a workboard drag unless we need to
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
2016-02-10 16:03:31 -08:00
epriestley
1fb76655df Restore column point counts to workboards
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
2016-02-10 14:01:28 -08:00
epriestley
0bf3519045 Rewrite workboards to have way more bugs
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
2016-02-10 13:08:38 -08:00
epriestley
735b722cb2 Fix a bad parameter in a parent::shouldHideForMail() call in Maniphest
Fixes T10303.

Auditors: chad
2016-02-09 04:17:35 -08:00
epriestley
f84130f9cd Support enabling a formal points field in Maniphest
Summary:
Ref T4427.

  - New config option for labels, enabling, etc., but no UI/niceness yet.
  - When enabled, add a field.
  - Allow nonnegative values, including fractional values.
  - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code.

Test Plan:
  - Edited points via "Edit".
  - Edited points via Conduit.
  - Edited points via stacked actions.
  - Tried to set "zebra" points.
  - Tried to set -1 points.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4427

Differential Revision: https://secure.phabricator.com/D15220
2016-02-08 18:14:44 -08:00
epriestley
e9f3807cf5 Add a "points" field to tasks
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
2016-02-08 15:28:00 -08:00
epriestley
32225d1dd0 Remove three ancient columns from Maniphest tasks: attached, projectPHIDs, ccPHIDs
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
2016-02-08 14:10:02 -08:00
epriestley
78c248d330 Support drag-and-drop to set cover images on workboard cards
Summary: This was slightly more complex than I believed, but not too terrible.

Test Plan:
{F1096126}

  - Also used some normal file uploaders to make sure I didn't break that.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15202
2016-02-06 15:58:43 -08:00
epriestley
b6a38b403c Add storage and read logic for workboard card cover photos
Summary:
No way to set photos yet, but if you magic them in they work.

Primarily, this consolidates rendering logic so the move + edit + view controllers all run the same code to do tags / cover photos.

Test Plan: {F1095870}

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15201
2016-02-06 15:34:41 -08:00
epriestley
5c2e49a812 Allow any user to watch any project they can see
Summary:
Ref T6183. Ref T10054. Historically, only members could watch projects because there were some weird special cases with policies. These policy issues have been resolved and Herald is generally powerful enough to do equivalent watches on most objects anyway.

Also puts a "Watch Project" button on the feed panel to make the behavior and meaning more obvious.

Test Plan:
  - Watched a project I was not a member of.
  - Clicked the feed watch/unwatch button.

{F1064909}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6183, T10054

Differential Revision: https://secure.phabricator.com/D15063
2016-01-19 19:38:30 -08:00
epriestley
57909a705c Improve strings for creating blocking subtasks
Summary:
Ref T6884. Ref T10004. For various reasons we previously didn't publish these transactions, but now do. This is probably a better behavior overall, but we didn't have reasonable strings for them.

Parent tasks now show "alice created blocking task Txxx.".

Feed now shows nothing, since "alice created task Txxx." is right next to any story we would show and showing them both seems silly.

Test Plan:
  - Created subtasks.
  - Viewed parent tasks.
  - Viewed feed.
  - Saw pretty reasonable strings/stories.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6884, T10004

Differential Revision: https://secure.phabricator.com/D14849
2015-12-21 17:35:09 -08:00
epriestley
99c9df96b4 Convert all "DocumentIndexers" into "FulltextEngines"
Summary: Ref T9979. This simplifies/standardizes the code a bit, but mostly gives us more consistent class names and structure.

Test Plan:
  - Used `bin/search index --type ...` to index documents of every indexable type.
  - Searched for documents by unique text, found them.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 17:25:23 -08:00
epriestley
5cb0de1efc Restore "Create" transactions
Summary:
Ref T10004. This restores "alice created this task." transactions, but in a generic way so we don't have to special case one of the other edits with an old `null` value.

In most cases, creating an object now shows only an "alice created this thing." transaction, unless nonempty defaults (usually, policy or spaces) were adjusted.

Test Plan: Created pastes, tasks, blogs, packages, and forms. Saw a single "alice created this thing." transaction.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14820
2015-12-18 11:56:03 -08:00
epriestley
eb8835b15e Provide more API information about Maniphest task statuses and priorities
Summary: Ref T9964. Priorities and statuses have metadata (colors, names, etc) which we can reasonably just return from API callers. This is so ligthweight that I think it doesn't really make sense to put in an attachment. We also use this information in `arc tasks`.

Test Plan: Called API, got sensible looking status and priority data back.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14777
2015-12-14 11:54:48 -08:00
epriestley
0a50219f1b Formalize custom Conduit fields on objects
Summary: Ref T9964. This just adds more structure to application fields, to make it harder to make typos and easier to validate them later.

Test Plan: Viewed APIs, called some APIs, saw good documentation and correct results.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14776
2015-12-14 11:54:13 -08:00
epriestley
3db175f79d Add a "content" attachment for Pastes for Conduit API
Summary: Ref T9964. Builds on D14772. Allows callers to get the raw content of pastes as an attachment.

Test Plan:
  - Read docs.
  - Executed attachment query.
  - Saw raw paste content.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14774
2015-12-14 11:53:32 -08:00
epriestley
f3b57990bf Add "maniphest.search" Conduit API endpoint
Summary: Ref T9964. This is a basic implementation of the new "maniphest.search" endpoint.

Test Plan: Clicked the button in the web UI, got meaningful results back.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14760
2015-12-14 04:08:57 -08:00
epriestley
eef2572508 Replace workboard task creation with EditEngine
Summary: Ref T9908. This is the last of the things that need to swap over.

Test Plan:
  - Created tasks from a workboard.
  - Created tasks in different columns.
  - Edited tasks.
  - Used `?parent=..`.
  - Verified that default edit form config now affects comment actions.
  - No more weird comment thing on forms, at least for now.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14715
2015-12-08 17:56:11 -08:00
epriestley
d53187e10a Make "Create Subtask" work properly in EditEngine
Summary: Ref T9908. This fixes "Create Subtask" so it works with the new stuff. Mostly straightforward.

Test Plan: Created some subtasks.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14706
2015-12-08 14:29:58 -08:00
epriestley
52f7446eea Remove "Create Empty Task" workflow callouts and some other clutter
Summary:
Ref T9908. This removes the "Create Another Empty Task", "Create A Similar Task" and "Create Another Subtask of Same Parent Task" workflow callouts on the task detail page, which are actions that show up after creating a task or creating a subtask.

  - I think "Create Empty" isn't relevant now that we have "Create Task" nearby and the quick create menu?
  - I'm not sure if "Create Similar" is worth keeping. If we do want to retain it, I'd maybe like to find a way to do it generically.
  - I'm likewise not sure if "Create another subtask" is worth keeping.

Overall, these actions are weird/unusual and I'm not sure how valuable they are. I'm open to keeping "Similar" and/or "Subtask" but I'd like to verify that they're still valuable and make sure we have a reasonable design for them if we retain them.

For example, if we want to retain "Similar", maybe a better approach is just to add "Create Similar Object" to every action menu (which is now possible for EditEngine applications)? There's at least some interest in "Create Similar Repository" in Diffusion.

Also removes a very very old piece of "attached files" code.

Test Plan: Created and viewed some tasks.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14705
2015-12-08 13:01:09 -08:00
Joshua Spence
a1737ef9c7 Fix a translation
Summary: Fixes T9763.

Test Plan: Merged tasks, saw translations.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin

Maniphest Tasks: T9763

Differential Revision: https://secure.phabricator.com/D14473
2015-11-13 07:04:48 +11:00
Joshua Spence
c35b564f4d Various translation improvements
Summary: Depends on D14070.

Test Plan: Eyeball it.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D14073
2015-11-03 07:02:46 +11:00
epriestley
1c45a7d8e2 Revert "Allow search results to be snippeted, roughly"
Summary:
This reverts commit 1583738842.

See T8646 for discussion. This version of the feature feels terrible on real data.

Test Plan: Strict revert.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14097
2015-09-10 20:57:26 -07:00
epriestley
1583738842 Allow search results to be snippeted, roughly
Summary:
Ref T8646. This is fairly rough:

This interface is very niche, and not really flexible enough to accommodate other result customization (but I don't think we have any plans here)?

I'm just //summarizing// the content of documents, basically showing the first paragraph of their content, summary, etc. This isn't what Google does: it shows snippets surrounding the actual search terms. However, this is more involved and might be less useful in structured data: for example, I'd imagine that the first line of most phriciton documents, maniphest tasks and Differential revisions really might be the best machine-generatable summary of them. The actual contextual snippeting in Google doesn't often seem hugely useful to me. But this might also not be very useful.

There's not much design, not sure if you had any ideas.

I only implemented this for tasks, revisions and the wiki since those seem most useful.

I'm generally on the fence about this, but it's not a ton of work to swap out for something else later. Maybe we can see how it feels? But happy to toss it or rethink the approach.

Test Plan: {F788026}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T8646

Differential Revision: https://secure.phabricator.com/D14095
2015-09-10 19:06:36 -07:00
epriestley
0bc8382dfd Support Spaces in ApplicationEmail
Summary:
Ref T8498. Allow ApplicationEmail addresses to be put into spaces:

  - You can only see and send to addresses in Spaces you have access to.
  - Objects are created into the same space their address is associated with.

Test Plan:
  - Used `bin/mail receive-test` to send mail to various `xyz-bugs@...` addresses.
  - Saw objects created in the proper space.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8498

Differential Revision: https://secure.phabricator.com/D13247
2015-06-11 10:23:56 -07:00
epriestley
d118800d37 Support Spaces in Maniphest
Summary:
Ref T8493. Tricks:

  - "Create Similar Task" and "Create Subtask" should copy the parent's Space.
  - Normal list view + workboard card view.

Test Plan:
  - Created a task, edited space, etc.
  - Viewed tasks with different users.
  - Created a "Similar Task" (saw proper Space).
  - Created a subtask (saw proper Space).
  - Viewed workboard.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8493

Differential Revision: https://secure.phabricator.com/D13232
2015-06-10 15:53:04 -07:00