1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-11 09:22:40 +01:00
Commit graph

573 commits

Author SHA1 Message Date
epriestley
67629aab14 Implement a rough optgroup-based "Move on Workboard" stacked action
Summary:
Ref T6027. Try this out and see how it feels? Clear issues:

  - This definitely shouldn't be at the top.
  - You should probably be able to select it multiple times?
  - Some of the "which columns show up" rules might need adjustment?
  - Diamond marker maybe not great?

Not sure I love this but it doesn't feel //terrible//...

Test Plan: {F1207891}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6027

Differential Revision: https://secure.phabricator.com/D15638
2016-04-06 09:15:12 -07:00
epriestley
ecd4dd4e0b Expose column positions via maniphest.edit
Summary: Ref T5214. Fixes T10486. Ref T6027. This exposes the `TYPE_COLUMNS` transaction in a usable way via API, and fixes the interactions via prefilling.

Test Plan:
  - Created tasks directly into columns via API.
  - Moved tasks between columns via API.
  - Used `?column=...` to try to create a template task with valid and bogus column PHIDs.

Reviewers: chad

Reviewed By: chad

Subscribers: AmyLewis

Maniphest Tasks: T5214, T6027, T10486

Differential Revision: https://secure.phabricator.com/D15636
2016-04-06 09:14:14 -07:00
epriestley
222cf6862b Render new more-general move transactions in a human-readable way
Summary: Ref T6027. This adds human-readable rendering for the new `TYPE_COLUMNS` core transactions.

Test Plan: {F1207784}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6027

Differential Revision: https://secure.phabricator.com/D15635
2016-04-06 09:13: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
Chad Little
e2685a248b Update Conduit for new UI
Summary: View various conduit pages and update to new UI and add calls to newPage

Test Plan: View list, view method, make a call.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15613
2016-04-04 16:39:23 -07:00
Chad Little
a939bbc4fa Update EditEngine for two column
Summary: Cleans up EditEngine, adds new layout to EditEngine and descendents

Test Plan: Test creating a new form, reordering, marking and unmarking defaults. View new forms.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15531
2016-03-28 09:18:55 -07:00
epriestley
601aaa5a86 Modularize content sources
Summary:
Ref T10537. For Nuance, I want to introduce new sources (like "GitHub" or "GitHub via Nuance" or something) but this needs to modularize eventually.

Split ContentSource apart so applications can add new content sources.

Test Plan:
This change has huge surface area, so I'll hold it until post-release. I think it's fairly safe (and if it does break anything, the breaks should be fatals, not anything subtle or difficult to fix), there's just no reason not to hold it for a few hours.

- Viewed new module page.
- Grepped for all removed functions/constants.
- Viewed some transactions.
- Hovered over timestamps to get content source details.
- Added a comment via Conduit.
- Added a comment via web.
- Ran `bin/storage upgrade --namespace XXXXX --no-quickstart -f` to re-run all historic migrations.
- Generated some objects with `bin/lipsum`.
- Ran a bulk job on some tasks.
- Ran unit tests.

{F1190182}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10537

Differential Revision: https://secure.phabricator.com/D15521
2016-03-26 11:59:45 -07:00
epriestley
8a7c963908 Allow applications to test if a user could edit a certain field by clicking "Edit Thing"
Summary: See D15432. There, we can use this test to check if the user //could// reassign the task by using "Edit Form" or the stacked actions, so any dedicated "claim" element is consistent with the other permissions.

Test Plan:
  - Added a `var_dump($can_reassign)` after the call.
  - Saw `true`.
  - Edited the edit form, locked and disabled "Assigned To".
  - Saw `false`.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D15433
2016-03-08 10:29:34 -08:00
epriestley
0569919eab Fix some visibility issues with inline comments in Diffusion
Summary:
Fixes T10519. Two issues:

First, the acting user wasn't explicitly included in the mail. This usually didn't matter, but could matter if you unsubscribed and then interacted.

Second, we had some logic which tried to hide redundant "added inline comment" transactions, but could hide them inappropriately. In particular, if another action (like a subscribe) was present in the same group, we could hide the inlines because of that other transaction, then //also// hide the subscribe. This particular issue is likely an unintended consequence of hiding self-subscribes.

Instead of hiding inlines if //anything else// happened, hide them only if:

  - there is another "added a comment" transaction; or
  - there is another "added an inline comment" transaction.

This prevents the root issue in T10519 (incorrectly hiding every transaction, and thus not sending the mail) and should generally make behavior a little more consistent and future-proof.

Test Plan:
  - Submitted //only// an inline comment on a commit I had not previously interacted with.
  - Before patch: no mail was generated (entire mail was improperly hidden).
  - After patch: got some mail with my comment.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10519

Differential Revision: https://secure.phabricator.com/D15407
2016-03-05 14:18:49 -08:00
epriestley
1bdf988556 Convert DrydockBlueprints to EditEngine
Summary:
Ref T10457. Fixes T10024. This primarily just modernizes blueprints to use EditEngine.

This also fixes T10024, which was an issue with stored properties not being flagged correctly.

Also slightly improves typeaheads for blueprints (more information, disabled state).

Test Plan:
  - Created and edited various types of blueprints.
  - Set and removed limits.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10024, T10457

Differential Revision: https://secure.phabricator.com/D15390
2016-03-03 15:21:25 -08:00
Chad Little
e9f4ca6ca3 Redesign PonderQuestionView
Summary: Full new UI, testing some upcoming treatments for consideration in other View controllers. Small tweaks to allow PHUITwoColumnView to have fixed and fluid width, and let TransactionCommentView go fullWidth.

Test Plan:
Tested a number of Ponder cases, New Question, with and without summary, with and without answers, with and without comments. Mobile, Tablet, and Desktop layouts. Verify Project and Profile UI's still in tact.

{F1120961}

{F1120962}

{F1120963}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15315
2016-02-23 17:20:07 -08:00
epriestley
ab86523ac4 Allow Almanac properties to be deleted, use EditEngine instead of CustomField
Summary:
Fixes T10410. Immediate impact of this is that you can now actually delete properties from Almanac services, devices and bindings.

The meat of the change is switching from CustomField to EditEngine for most of the actual editing logic. CustomField creates a lot of problems with using EditEngine for everything else (D15326), and weird, hard-to-resolve bugs like this one (not being able to delete stuff).

Using EditEngine to do this stuff instead seems like it works out much better -- I did this in ProfilePanel first and am happy with how it looks.

This also makes the internal storage for properties JSON instead of raw text.

Test Plan:
  - Created, edited and deleted properties on services, devices and bindings.
  - Edited and reset builtin properties on repository services.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10410

Differential Revision: https://secure.phabricator.com/D15327
2016-02-22 11:28:26 -08:00
epriestley
af1fef242c Fix an issue with editing pre-space objects using a form with no visibility controls
Summary:
WMF ran into this after their update. Here's the setup:

  - When you enable Spaces, we leave all existing objects set to `null`, which means "these belong to the default space". This is so we don't have to go update a trillion objects.
  - New objects get set to the default space explicitly (`PHID-SPCE-...`) but older ones stay with `null`.
  - If you edit an older object (like a task) from the time before Spaces, //and// the form doesn't have a Visbility/Spaces control, we would incorrectly poplate the value with `null` when the effective value should be the default space PHID.
  - This caused a "You must choose a space." error in the UI.

Instead, populate the control with the effective value instead of the literal database value. This makes the edit go through cleanly.

Also add a note about this for future-me.

Test Plan:
  - Disabled "Visibility" control in task edit form.
  - Edited an old task which had `null` as a `spacePHID` in the database.
  - Before patch: UI error about selecting a Space.
  - After patch: edit goes through cleanly.

Reviewers: chad, 20after4

Reviewed By: chad, 20after4

Subscribers: 20after4, aklapper

Differential Revision: https://secure.phabricator.com/D15306
2016-02-18 11:15:40 -08:00
Alex Monk
f557fc9caa Return 404 instead of undefined variable error when trying to edit a non-existent form
Summary: E.g. https://phab-01.wmflabs.org/transactions/editengine/transactions.editengine.config/view/13/

Test Plan:
* Go to /transactions/editengine/transactions.editengine.config/view/1000000/
* Observe error
* Apply patch
* Observe 404

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D15307
2016-02-18 09:54:47 -08:00
Chad Little
f35509e30e Update to use PHUIRemarkupView everywhere possible
Summary: Moves all the one off object calls to PHUIRemarkupView, adds a "Document" call as well (future plans).

Test Plan: Visited most pages I could get access to, but may want extra careful eyes on this diff.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15281
2016-02-16 14:05:53 -08:00
epriestley
376c85a828 Make subproject/milestone watch rules work better
Summary:
Ref T10349. These got sort of half-weirded-up before I separated subscriptions and watching fully. New rules are:

  - You can watch whatever you want.
  - Watching a parent watches everything inside it.
  - If you're watching "Stonework" and go to "Stonework > Masonry", you'll see a "Watching Ancestor" hint to let you know you're already watching a parent or ancestor.

Test Plan:
  - Watched and unwatched "Stonework".
  - Watched and unwatched "Stonework > Iteration IV".
  - While watching "Stonework", visited "Iteration IV" and saw "Watching Ancestor" hint.
  - Created a task tagged "Stonework > Iteration IV". Got notified about it because I watch "Stonework".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10349

Differential Revision: https://secure.phabricator.com/D15280
2016-02-16 10:42:07 -08:00
epriestley
ca908d7cc4 Don't autoname milestones, but do show the previous milestone name as a hint
Summary: Fixes T10347. In the long run maybe we'll try to guess this better, but for now get rid of the "Milestone X" hardcode and just show what the last one was called.

Test Plan:
  - Created the first milestone for a project.
  - Created the nth milestone for a project.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10347

Differential Revision: https://secure.phabricator.com/D15262
2016-02-12 11:04:46 -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
268a9ced78 Implement subproject/milestone conflict resolution rules
Summary:
Ref T10010. When you try to add "Sprint 35" to a task, remove "Sprint 34", etc. Briefly:

  - A task can't be in Sprint 3 and Sprint 4.
  - A task can't be in "A" and "A > B" (but "A > B" and "A > C" are fine).
  - When a user makes an edit which would violate one of these rules, preserve the last tag in each group of conflicts.

Test Plan:
  - Added fairly comprehensive tests.
  - Added a bunch of different tags to things, saw them properly exclude conflicting tags.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10010

Differential Revision: https://secure.phabricator.com/D15167
2016-02-02 13:12:27 -08:00
Chad Little
fe5cd4ca2c Move FontIcon calls to Icon
Summary: Normalizes all `setFontIcon` calls to `setIcon`.

Test Plan: UIExamples, Almanac, Apps list, etc.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, hach-que, yelirekim

Differential Revision: https://secure.phabricator.com/D15129
2016-01-28 08:48:45 -08:00
Chad Little
36158dbdc0 Convert all calls to 'IconFont' to just 'Icon'
Summary: Mostly for consistency, we're not using other forms of icons and this makes all classes that use an icon call it in the same way.

Test Plan: tested uiexamples, lots of other random pages.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D15125
2016-01-27 20:59:27 -08:00
epriestley
9ae48d4026 Fix smushing of multiple values in Projects "Additional Hashtags" field
Summary: Ref T10168. When we render this control, we currently don't put commas into the value correctly if there are multiple alternative hashtags.

Test Plan: Edited a project with multiple alternate hashtags. Before change: they all got smushed together. After change: properly comma-separated.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10168

Differential Revision: https://secure.phabricator.com/D15045
2016-01-18 08:34:13 -08:00
epriestley
f24318f308 Make "profile menu" configuration mostly work
Summary:
Ref T10054. This does a big chunk of the legwork to let users reconfigure profile menus (currently, just project menus).

This includes:

  - Editing builtin items (e.g., you can rename the default items).
  - Creating new items (for now, only links are available).

This does not yet include:

  - Hiding items.
  - Reordering items.
  - Lots of fancy types of items (dashboards, etc).
  - Any UI changes.
  - Documentation (does feature: TODO link for documentation).

Test Plan:
{F1060695}

{F1060696}

{F1060697}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10054

Differential Revision: https://secure.phabricator.com/D15010
2016-01-13 11:45:31 -08:00
epriestley
add8333b98 Improve behavior of "owner" transaction in "maniphest.edit" endpoint
Summary:
Fixes T10117.

  - I accidentally broke setting `null` to unassign tasks at some point when I added richer validation.
  - Raise a better error if the user passes junk.

Test Plan:
  - Unassigned a task via API and web UI.
  - Reassigned a task via API and web UI.
  - Tried to do an invalid assign via API, got a sensible error.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10117

Differential Revision: https://secure.phabricator.com/D14992
2016-01-11 09:19:18 -08:00
epriestley
70053beeed Smooth out milestone creation workflow
Summary:
Ref T10010.

  - Default name to "Milestone X".
  - Remove policy controls, which have no effect.
  - Don't generate slugs for milestones since this is a big pain where they all generate as `#milestone_1` by default (you can add one if you want). I plan to add some kind of syntax like `#parent/32` to mean "Milestone 32 in Parent" later.
  - Don't require projects to have unique names (again, 900 copies of "Milestone X"). I think we can trust users to sort this out for themselves since modern Phabricator has "Can Create Projects" permission, etc.

Test Plan: Created some milestones, had a less awful experience.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10010

Differential Revision: https://secure.phabricator.com/D14909
2015-12-29 10:40:28 -08:00
epriestley
e0a97c88db Provide phame.post.edit Conduit API method
Summary:
Ref T9897. This one is a little more involved because of how getting a post on a blog works.

I also changed moving posts to be a real transaction (which shows up in history, now).

Test Plan: Created posts from web UI and conduit.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9897

Differential Revision: https://secure.phabricator.com/D14902
2015-12-28 06:55:35 -08:00
epriestley
6fe882e50a Convert projects to EditEngine
Summary: Ref T10010. This is pretty straightforward with a couple of very minor new behaviors, like the icon selector edit field.

Test Plan:
  - Created projects.
  - Edited projects.
  - Saw "Create Project" in quick create menu.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10010

Differential Revision: https://secure.phabricator.com/D14896
2015-12-27 15:42:50 -08:00
epriestley
aa2089ba68 Support field previews in EditEngine
Summary: Ref T10004. This primarily supports moving Phame to EditEngine.

Test Plan: {F1045166}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14887
2015-12-27 08:17:18 -08:00
epriestley
f5ff10fe28 Put inline previews in remarkup textareas
Summary:
Ref T3967. This gives us a reasonable baseline for doing remarkup previews inline in all contexts, and works in weird/constrained context including:

  - inline comments;
  - conpherence; and
  - custom fields.

It would be nicer to go beyond this in contexts like Phame posts, but this is a start, at least.

Test Plan:
{F1040877}

{F1040878}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T3967

Differential Revision: https://secure.phabricator.com/D14855
2015-12-22 12:18:28 -08:00
epriestley
536d3a2185 Don't show self-subscribes in feed or mail
Summary: These transactions (when a user subscribes or unsubscribes only themselves) are universally uninteresting.

Test Plan:
  - Subscribed/unsubscribed, saw transactions but no feed/mail.
  - Commented, got implicitly subscribed, saw only comment in feed/mail, saw both transasctions on task.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14853
2015-12-22 10:45:51 -08:00
epriestley
99bd12b98d Lift Conpherence indexing up out of the Fulltext index
Summary:
Ref T9979. There are currently some hacks around Conpherence indexing: it does not really use the fulltext index, but its own specialized index. However, it's kind of hacked up so it can get reindexed by the normal indexing pipeline.

Lift it up into IndexEngine, instead of FulltextEngine. Specifically, the new stuff is going to look like this:

  - IndexEngine: Rebuild all indexes.
    - ConpherenceIndexExtension: Rebuild thread indexes.
    - ProjectMemberIndexExtension: Rebuild project membership views.
    - NgramIndexExtension: Rebuild ngram indexes.
    - FulltextIndexExtension / FulltextEngine: Rebuild fulltext indexes, a special type of index.
      - FulltextCommentExtension: Rebuild comment fulltext indexes.
      - FulltextProjectExtension: Rebuild project fulltext indexes.
      - etc.

Most of this is at least sort-of-in-place as of this diff, although some of the part in the middle is still pretty rough.

Test Plan:
  - Made a unique comment in a Conpherence thread.
  - Used `bin/search index --force` to rebuild the index.
  - Searched for the comment.
  - Found the thread.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14841
2015-12-21 17:25:05 -08:00
epriestley
ecc3314a25 Modularize transaction/comment indexing in the FulltextEngine
Summary:
Ref T9979. This is currently hard-coded but can be done in a generic way.

This has one minor behavioral changes: answer text is no longer included in the question text index in Ponder. I'm not planning to accommodate that for now since I don't want to dig this hole any deeper than I already have. This behavior should be different anyway (e.g., index the answer, then show the question in the results or something).

Test Plan:
  - Put a unique word in a Maniphest comment.
  - Searched for the word.
  - Found the task.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14837
2015-12-21 17:24:40 -08:00
epriestley
2447d9bdf2 Begin improving modularity of IndexEngine, add locks
Summary:
Ref T9890. Ref T9979. Several adjacent goals:

  - The `SearchEngine` vs `ApplicationSearchEngine` thing is really confusing. There are also a bunch of confusing class names and class relationships within the fulltext indexing. I want to rename these classes to be more standard (`IndexEngine`, `IndexEngineExtension`, etc). Rename `SearchIndexer` to `IndexEngine`. A future change will rename `SearchEngine`.
  - Add the index locks described in T9890.
  - Structure things a little more normally so future diffs can do the "EngineExtension" thing more cleanly.

Test Plan:
Indexing:

  - Renamed a task to have a unique word in the title.
  - Ran `bin/search index Txxx`.
  - Searched for unique word.
  - Found task.

Locking:

  - Added a `sleep(10)` after the `lock()` call.
  - Ran `bin/search index Txxx` in two windows.
  - Saw first one lock, sleep 10 seconds, index.
  - Saw second one give up temporarily after failing to grab the lock.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9890, T9979

Differential Revision: https://secure.phabricator.com/D14834
2015-12-21 17:04:10 -08:00
epriestley
4bba3fd4c1 Fully modularize DestructionEngine
Summary: Ref T9979. Convert all DestructionEngine behaviors to extensions.

Test Plan:
{F1033244}

Destroyed an object, verifying:

  - Herald transcripts were destroyed;
  - edges were destroyed;
  - flags were destroyed;
  - tokens were destroyed;
  - transactions were destroyed;
  - worker tasks were cancelled.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14832
2015-12-21 17:03:44 -08:00
epriestley
674388ce6a Prepare DestructionEngine to be modularized
Summary:
Ref T9979. The general shape of "engine" code feels pretty good, and I plan to move indexing to be more in line with other modern engines, with the ultimate goal of supporting subprojects (T10010) and several intermediate goals.

Before moving indexing, clean up Destruction, since some of the new indexes will need destruction hooks and destruction currently has a lot of `instanceof` stuff that should be easy to fix by applying more modern approaches.

Test Plan:
  - Used `bin/remove destroy` to destory an Almanac device.
  - Verified that properties for the device were destroyed.
  - Viewed module panel in UI.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14831
2015-12-21 17:03:32 -08:00
epriestley
3f8e5c9620 Straighten out reorder permissions on form configurations
Summary:
Fixes T10012. The permissions here are little weird: you need edit permission on the //configurations//, not the //engines//. I was checking edit permission on the engines only.

I should possibly make this a bit more consistent, the engine edit permission is just very convenient to use to enforce object create permission right now. I'll likely clean this up after T9789.

Test Plan:
  - Tried to reorder forms as a less-privileged user, got proper policy errors.
  - Reordered forms normally as a regular user.

Reviewers: chad

Reviewed By: chad

Subscribers: Luke081515.2

Maniphest Tasks: T10012

Differential Revision: https://secure.phabricator.com/D14824
2015-12-19 07:36:00 -08:00
epriestley
a1a8b9ba65 Clean up "HTTP Parameters" view a bit for EditEngine forms
Summary: Ref T10004. This lost a couple of fields when I rearranged how descriptions work. Restore them.

Test Plan:
  - Viewed "Using HTTP Parameters".
  - Everything had nice descriptions.
  - No more weird phantom/misleading 'comment' transaction in UI.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14822
2015-12-18 12:00:38 -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
a3bdce9680 Indent multiple items from the same application in Quick Create menu
Summary: Ref T10004. Happy to take another approach here or just not bother, this just struck me as a little ambiguous/confusing.

Test Plan:
Before, not necessarily clear that the "Create Task" header only applies to the first few items.

{F1029126}

After, more clear:

{F1029127}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14815
2015-12-17 15:24:46 -08:00
epriestley
ed43b31cb1 Prevent "Spaces" field from being set to inconsistent values
Summary:
At least for now, the "Space" field is just a subfield of the "Visible To" field, so:

  - it doesn't get any separate settings; and
  - it always uses the "Visible To" settings.

Test Plan:
  - Created a form with a hidden view policy field.
  - Created stuff with no "you must pick a space" errors.
  - Created stuff with a normal form.
  - Prefilled "Space" on a noraml form.
  - Verified that trying to prefill "Space" on a form with "Visible To" hidden does nothing.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14812
2015-12-17 11:22:32 -08:00
epriestley
bd7981c750 Improve the clarity of transactions that affect policies and spaces during object creation
Summary:
Ref T10004. Fixes T9527. Currently, we render two kinds of bad policy/space transactions during object creation.

First, we render a transaction showing a change from the default policy/space to the selected policy/space:

> alice shifted this object from space S1 Default to space S2 Secret.

This is a //good transaction// (it's showing that the default was changed, which could be important for policy stuff!) but it's confusing because it makes it sound like the object briefly existed in space S1, when it did not.

Instead, render this:

> alice created this object in space S2 Secret.

This retains the value (show that the object was created in an unusual space) without the confusion.

Second, when you create a "New Bug Report", we render a transaction like this:

> alice changed the visibility of this task from "All Users" to "Community".

This is distracting and not useful, becasue it's a locked default of the form. This was essentially fixed by D14810. The new behavior is to show this, //only// if the value was changed from the form value:

> alice created this object with visibility "Administrators".

This should reduce confusion, reduce fluff in the default cases, and do a better job of calling out important changes (basically, unusual spaces/policies).

Test Plan:
  - Created an edit form with a default space and policies.
  - Used that form to create task with:
    - same values as form;
    - different values from form.

When I changed the form value, I got transactions. When I left it the same, I didn't.

The transactions rendered in the non-confusing "created with ..." variant.

Editing the values created normal transactions with "changed policy from X to Y".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9527, T10004

Differential Revision: https://secure.phabricator.com/D14811
2015-12-17 10:45:53 -08:00
epriestley
6146aefcd4 Show fewer useless transactions when creating objects, especially with EditEngine forms
Summary:
Fixes T7661. Ref T9527.

When you create a task, especially with an EditEngine form, you currently get more noise than is useful. For example:

> alice created this task.
> alice changed the edit policy from "All Users" to "Community (Project)".
> alice added projects: Feature Request, Differential.
> alice added a subscriber: alice.

Transaction (1) is a little useful, since it saves us from a weird empty state and shows the object creation time.

Transaction (2) is totally useless (and even misleading) because that's the default policy for the form.

Transaction (3) isn't //completely// useless but isn't very interesting, and probably not worth the real-estate.

Transaction (4) is totally useless.

(These transactions are uniquely useless when creating objects -- when editing them later, they're fine.)

This adds two new rules to hide transactions:

  - Hide transactions from object creation if the old value is empty (e.g., set title, set projects, set subscribers).
  - Hide transactions from object creation if the old value is the same as the form default value (e.g., set policy to default, set priorities to default, set status to default).

NOTE: These rules also hide the "created this object" transaction, since it's really one of those transaction types in all cases. I want to keep that around in the long term, but just have it be a separate `TYPE_CREATE` action -- currently, it is this weird, inconsistent action where we pick some required field (like title) and special-case the rendering if the old value is `null`. So fixing that is a bit more involved. For now, I'm just dropping these transactions completely, but intend to restore them later.

Test Plan:
  - Created objects.
  - Usually saw no extra create transactions.
  - Saw extra create transactions when making an important change away from form defaults (e.g., overriding form policy).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7661, T9527

Differential Revision: https://secure.phabricator.com/D14810
2015-12-17 10:45:01 -08:00
epriestley
38e31375ea Improve UX for customizing EditEngine forms a little bit
Summary:
Ref T10004. Tweaks some of the UX a little to be more intuitive/inviting?

  - Button says "Configure Form" instead of "Actions".
  - Root list is less "developer-ey" and more "explain what this is for-ey".

Test Plan:
{F1028928}

{F1028929}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14808
2015-12-17 08:40:00 -08:00
epriestley
57cc30d0c4 Continue hammering new *.search / *.edit documentation into shape
Summary: Ref T9964. Create some docuemntation for this stuff, and clean up the *.edit endpoints a bit.

Test Plan: Read documentation.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14798
2015-12-16 08:46:05 -08:00
epriestley
161ebad56d Improve Conduit type handling for *.edit endpoints
Summary:
Ref T9964. Three goals here:

  - Make it easier to supply Conduit documentation.
  - Make automatic documentation for `*.edit` endpoints more complete, particularly for custom fields.
  - Allow type resolution via Conduit types, so you can pass `["alincoln"]` to "subscribers" instead of needing to use PHIDs.

Test Plan:
  - Viewed and used all search and edit endpoints, including custom fields.
  - Used parameter type resolution to set subscribers to user "dog" instead of "PHID-USER-whatever".
  - Viewed HTTP parameter documentation.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14796
2015-12-16 08:45:46 -08:00
epriestley
1d72c97fc9 Fix overzealous subscribing in EditEngine
Summary:
See T9905#148799. The CommentEditField generated empty comment transactions; these are dropped later, but before they are dropped they would trigger implicit CCs.

The implicit CC rule should probably be narrower, but we shouldn't be generating these transactions in the first place.

Test Plan: No longer implicitly CC'd on a task when doing something minor like changing projects.

Reviewers: chad

Reviewed By: chad

Subscribers: avivey

Differential Revision: https://secure.phabricator.com/D14795
2015-12-15 16:17:26 -08:00
epriestley
4b3dcd5500 Add some documentation about how to set paths with owners.edit
Summary:
Ref T9964.

  - New mechanism for rich documentation on unusual/complicated edits.
  - Add some docs to `paths.set` since it's not self-evident what you're supposed to pass in.

Test Plan: {F1027177}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14791
2015-12-15 15:04:16 -08:00
epriestley
b0a5eee238 Support editing statuses and paths in Owners via Conduit API
Summary: Ref T9964. Fixes T9752. Provides API access to enable/disable packages and change their paths.

Test Plan:
  - Changed status via Conduit.
  - Changed paths via Conduit.
  - Tried to change a path use a nonsense/bogus repository PHID, got an error.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9752, T9964

Differential Revision: https://secure.phabricator.com/D14790
2015-12-15 15:04:00 -08:00
epriestley
d7693a93b3 Provide "Change Projects" and "Change Subscribers" (instead of "Add ...") in comment actions
Summary:
Ref T9908. Fixes T6205.

This is largely some refactoring to improve the code. The new structure is:

  - Each EditField has zero or one "submit" (normal edit form) controls.
  - Each EditField has zero or one "comment" (stacked actions) controls.
    - If we want more than one in the future, we'd just add two fields.
  - Each EditField can have multiple EditTypes which provide Conduit transactions.
  - EditTypes are now lower-level and less involved on the Submit/Comment pathways.

Test Plan:
  - Added and removed projects and subscribers.
  - Changed task statuses.
  - In two windows: added some subscribers in one, removed different ones in the other. The changes did not conflict.
  - Applied changes via Conduit.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6205, T9908

Differential Revision: https://secure.phabricator.com/D14789
2015-12-15 15:03:34 -08:00
epriestley
a8b402aa14 Allow pastes to be activated/archived via Conduit
Summary: Ref T9964. Add a `setIsConduitOnly()` method so we can mark a field as API-only.

Test Plan:
  - Created and edited pastes via web UI (no status field).
  - Adjusted status via web UI action.
  - Adjusted status via Conduit API.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14788
2015-12-15 06:46:05 -08:00
epriestley
39206fcbc6 Fix a bad method call in EditEngine
Summary: Ref T9983. This method is spelled wrong.

Test Plan: Hit this case, got a dialog instead of a fatal.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9983

Differential Revision: https://secure.phabricator.com/D14786
2015-12-14 17:04:35 -08:00
epriestley
c19654db16 Write some basic "dealing with Conduit changes" documentation
Summary:
Ref T9980. No magic here, just write a little bit about how to find outdated callers. Update the technical doc.

Also:

  - Fix an unrelated bug where you couldn't leave comments if an object had missing, required, custom fields.
  - Restore the ConduitConnectionLog table so `bin/storage adjust` doesn't complain.

Test Plan: Read docs.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9980

Differential Revision: https://secure.phabricator.com/D14784
2015-12-14 15:26:24 -08:00
epriestley
81ae9f8fb6 Clean up an issue with meta-editing of edit engines
Summary:
Ref T9908. These meta-edit-engines are used to generate the main editengine UIs, but they're also editable.

Fix an exception when trying to edit the meta editengine.

Test Plan: Edited editengineconfiguration editengine.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14783
2015-12-14 15:26:03 -08:00
epriestley
2160c45619 Implement an "Attachments" behavior for Conduit Search APIs
Summary:
Ref T9964. We have various kinds of secondary data on objects (like subscribers, projects, paste content, Owners paths, file attachments, etc) which is somewhat slow, or somewhat large, or both.

Some approaches to handling this in the API include:

  - Always return all of it (very easy, but slow).
  - Require users to make separate API calls to get each piece of data (very simple, but inefficient and really cumbersome to use).
  - Implement a hierarchical query language like GraphQL (powerful, but very complex).
  - Kind of mix-and-match a half-power query language and some extra calls? (fairly simple, not too terrible?)

We currently mix-and-match internally, with `->needStuff(true)`. This is not a general-purpose, full-power graph query language like GraphQL, and it occasionally does limit us.

For example, there is no way to do this sort of thing:

  $conpherence_thread_query = id(new ConpherenceThreadQuery())
    ->setViewer($viewer)
    // ...
    ->setNeedMessages(true)
    ->setWhenYouLoadTheMessagesTheyNeedProfilePictures(true);

However, we almost never actually need to do this and when we do want to do it we usually don't //really// want to do it, so I don't think this is a major limit to the practical power of the system for the kinds of things we really want to do with it.

Put another way, we have a lot of 1-level hierarchical queries (get pictures or repositories or projects or files or content for these objects) but few-to-no 2+ level queries (get files for these objects, then get all the projects for those files).

So even though 1-level hierarchies are not a beautiful, general-purpose, fully-abstract system, they've worked well so far in practice and I'm comfortable moving forward with them in the API.

If we do need N-level queries in the future, there is no technical reason we can't put GraphQL (or something similar) on top of this eventually, and this would represent a solid step toward that. However, I suspect we'll never need them.

Upshot: I'm pretty happy with "->needX()" for all practical purposes, so this is just adding a way to say "->needX()" to the API.

Specifically, you say:

```
{
  "attachments": {
    "subscribers": true,
  }
}
```

...and get back subscriber data. In the future (or for certain attachments), `true` might become a dictionary of extra parameters, if necessary, and could do so without breaking the API.

Test Plan:
- Ran queries to get attachments.

{F1025449}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14772
2015-12-14 11:53:00 -08:00
epriestley
d1a1d48001 Give ConduitAPIMethod->getMethodDescription() access to a real Viewer
Summary:
Ref T9964. The new `*.search` and `*.edit` methods generate documentation which depends on the viewer.

For example, the `*.search` methods show a reference table of the keys for all your saved queries.

Give them a real viewer to work with.

During normal execution, just populate this viewer with the request's viewer, so `$request->getViewer()` and `$this->getViewer()` both work and mean the same thing.

Test Plan: {F1023780}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14761
2015-12-14 04:20:11 -08:00
epriestley
4b77bbd60c Clarify that the "Add Comment" button might not literally add a comment if you haven't typed a comment
Summary: Ref T9908.

Test Plan: Careful reading.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14746
2015-12-11 17:39:39 -08:00
epriestley
42ef21f8fa Document how to customize forms in ApplicationEditor
Summary:
Ref T9132. I think the featureset is approximatley stable, so here's some documentation.

I also cleaned up a handful of things in the UI and tried to make them more obvious or more consistent.

Test Plan: Read documentation.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14718
2015-12-09 07:30:23 -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
21be67e87a Move inline edit from task lists to EditEngine
Summary: Ref T9908. Fixes T8903. This moves the inline edit from task lists (but not from workboards) over to editengine.

Test Plan:
  - Edited a task from a draggable list.
  - Edited a task from an undraggable list.
  - Edited a task, changed projects, saw refresh show correct projects.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T8903, T9908

Differential Revision: https://secure.phabricator.com/D14711
2015-12-08 15:29: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
59ae0d6fff Allow EditEngine create and edit forms to be reordered
Summary:
Ref T9132. Ref T9908. Puts reordering UI in place:

  - For create forms, this just lets you pick a UI display order other than alphabetical. Seems nice to have.
  - For edit forms, this lets you create a hierarchy of advanced-to-basic forms and give them different visibility policies, if you want.

Test Plan:
{F1017842}

  - Verified that "Edit Thing" now takes me to the highest-ranked edit form.
  - Verified that create menu and quick create menu reflect application order.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132, T9908

Differential Revision: https://secure.phabricator.com/D14704
2015-12-08 13:00:54 -08:00
epriestley
2f8e409876 Allow EditEngine forms to be marked as "edit" forms
Summary:
Ref T9132. Ref T9908. This attempts to move us forward on answering this question:

> Which form gets used when a user clicks "Edit Task"?

One answer is "the same form that was used to create the task". There are several problems with that:

  - The form might not exist anymore.
  - The user might not have permission to see it.
  - Some of the fields might be hidden, essentially preventing them from being edited.
  - We have to store the value somewhere and old tasks won't have a value.
  - Any instructions on the form probably don't apply to edits.

One answer is "force the default, full form". That's not as problematic, but it means we have no ability to create limited access users who see fewer fields.

The answer in this diff is:

  - Forms can be marked as "edit forms".
  - We take the user to the first edit form they have permission to see, from a master list.

This allows you to create several forms like:

  - Advanced Edit Form (say, all fields -- visible to administrators).
  - Basic Edit Form (say, no policies -- visible to trusted users).
  - Noob Edit Form (say, no policies, priorities, or status -- visible to everyone).

Then you can give everyone access to "noob", some people access to "basic", and a few people access to "advanced".

This might only be part of the answer. In particular, you can still //use// any edit form you can see, so we could do these things in the future:

  - Give you an option to switch to a different form if you want.
  - Save the form the task was created with, and use that form by default.

If we do pursue those, we can fall back to this behavior if there's a problem with them (e.g., original form doesn't exist or wasn't recorded).

There's also no "reorder" UI yet, that'll be coming in the next diff.

I'm also going to try to probably make the "create" and "edit" stuff a little more consistent / less weird in a bit.

Test Plan: Marked various forms as edit forms or not edit forms, made edits, hit permissions errors, etc.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132, T9908

Differential Revision: https://secure.phabricator.com/D14702
2015-12-08 13:00:30 -08:00
epriestley
82e67e6bb9 Clean up some EditEngine meta-policies
Summary:
Ref T9908. Simplify some of the policies here:

  - If you can edit an application (currently, always "Administrators"), you can view and edit all of its forms.
  - You must be able to edit an application to create new forms.
  - Improve some error messages.
  - Get about halfway through letting users reorder forms in the "Create" menu if they want to sort by something weird since it'll need schema changes and I can do them all in one go here.

Test Plan:
  - Tried to create and edit forms as an unprivileged user.
  - Created and edited forms as an administrator.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14700
2015-12-07 15:40:31 -08:00
epriestley
468f785845 Support "template objects" generically in EditEngine
Summary:
Ref T9132. Ref T9908. Fixes T5622. This allows you to copy some fields (projects, subscribers, custom fields, some per-application) from another object when creating a new object by passing the `?template=xyz` parameter.

Extend "copy" support to work with all custom fields.

Test Plan:
  - Created new pastes, packages, tasks using `?template=...`
  - Viewed new template docs page.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5622, T9132, T9908

Differential Revision: https://secure.phabricator.com/D14699
2015-12-07 13:44:07 -08:00
epriestley
e7fc2a387b Populate the "Quick Create" menu from EditEngine
Summary:
Ref T9908. When there are custom / renamed / policy considerations for applications, respect them in the quick create menu.

This has some performance implications, in that it makes every page slower by two queries (and potentially more, soon), which is quite bad. I have some ideas to mitigate this, but it's not the end of the world to eat these queries for now.

Test Plan: {F1017316}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14693
2015-12-07 11:13:34 -08:00
epriestley
5caee3521e Clean up some EditEngine policy issues
Summary:
Ref T9908.

  - You should not need edit permission on a task in order to comment on it.
  - At least for now, ignore any customization in Conduit and Stacked Actions. These UIs always use the full edit form as it's written in the application.

Test Plan:
  - Verified a non-editor can now comment on tasks they can see.
  - Verified a user still can't use an edit form they can't see.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9908

Differential Revision: https://secure.phabricator.com/D14691
2015-12-07 11:13:04 -08:00
epriestley
75f126c3d0 Fix a loopy comment
Summary: I wrote this earlier in D14680 but have now realized that it's the same sentence twice when read carefully.

Test Plan: read more carefully

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14687
2015-12-05 14:55:20 -08:00
epriestley
77d33ec7be Fix confusing ordering of similar actions in transaction groups
Summary:
Fixes T7250. Currently, if a display group of transactions (multiple transactions by the same author in a short period of time with no intervening comments) has several transactions of similar strength (e.g., several status change transactions) we can end up displaying them in reverse chronological order, which is confusing.

Instead, make sure transactions of the same type/strength are always in logical order.

Test Plan:
  - Merged a task into another task, then reopened the merged task.
  - Before patch: merge/reopen showed in wrong order.

{F1014954}

  - After patch: merge/reopen show in correct order.

{F1014955}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7250

Differential Revision: https://secure.phabricator.com/D14680
2015-12-05 10:51:13 -08:00
epriestley
5977215437 Don't require access to default EditConfiguration to view objects
Currently, to render comment actions you need to be able to see the
default form. Just make this work for now until it gets cleaned up.
2015-12-04 16:58:21 -08:00
epriestley
273e22d59f Save stacked actions in drafts, not just comments
Summary:
Ref T9132. Fixes T4580. Thhat might actually have been fixed a while ago or something since it describes a buggy/bad interaction which doesn't reproduce for me at HEAD.

This saves and restores all the stacked actions (subscribers, projects, etc) so that you don't lose anything if you close a window by accident.

Test Plan:
Added a bunch of actions in various states, reloaded the page, draft stuck around.

Submitted form, actions didn't stick around anymore.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4580, T9132

Differential Revision: https://secure.phabricator.com/D14675
2015-12-04 16:29:43 -08:00
epriestley
eded19a5c6 Unify EditEngine preview behavior; prepare for saving complex drafts
Summary:
Ref T9132. We currently have an old preview/draft behavior and a new actions behavior.

Let the actions behavior do drafts/previews too, so we can eventually throw away the old thing.

This is pretty much just copying the old behavior into the new one, but with a few tweaks. The major change is that we submit all the stacked actions behavior now, so the preview reflects everything the change will do (and, soon, we can save it in the draft in a consistent way).

Also includes one hack-fix that I'll clean up at some point.

Test Plan: Added a bunch of stacked actions and observed meaningful previews.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14672
2015-12-04 16:29:40 -08:00
epriestley
f1744ac6d9 Change/drop/reconcile some miscellaneous edit behaviors in Maniphest
Summary:
Ref T9132. Open to discussion here since it's mostly product stuff, but here's my gut on this:

  - Change Maniphest behavior to stop assigning tasks if they're unassigned when closed. I think this behavior often doesn't make much sense. We'll probably separately track "who closed this" in T4434 eventually.
  - Only add the actor as a subscriber if they comment, like in other applications. Previously, we added them as a subscriber for other types of changes (like priority and status changes). This is more consistent, but open to retaining the old behavior or some compromise between the two.
  - Retain the "when changing owner, subscribe the old owner" behavior.

Test Plan:
  - Added a comment, got CC'd.
  - Changed owners, saw old owner get CC'd.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14670
2015-12-04 16:29:38 -08:00
epriestley
f9e84d1a88 Make "Assign / Claim" stacked action work properly in Maniphest
Summary:
Ref T9132. This is kind of a mess because the tokenizer rewrite left rendering tokenizers in Javascript a little rough. This causes bugs like icons not showing up on tokens in the "Policy" dialog, which there's a task for somewhere I think.

I think I've fixed it enough that the beahavior is now correct (i.e., icons show up properly), but some of the code is a bit iffy. I'll eventually clean this up properly, but it's fairly well contained for now.

Test Plan:
  - Reassigned a task.
  - Put a task up for grabs.
  - No reassign on closed tasks.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14669
2015-12-04 16:29:35 -08:00
epriestley
92ea07e787 Restore "Change Status" and "Change Priority" comment actions to Maniphest
Summary: Ref T9132. Supports selects in stacked actions and adds "Change Status" + "Change Priority".

Test Plan: Changed status and priority from stacked actions.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14667
2015-12-04 16:29:33 -08:00
epriestley
b3cf00333c Limit number of EditEngine tokenizer tokens in "Owner" field UI to 1
Summary:
Ref T9132. Only allow a task to have a single owner in the UI.

In Conduit, make this field appear and behave as "phid" instead of "list<phid>".

Test Plan: Edited a task with new fancy form, got limited to one owner. Assigned/unassigned. Used Conduit to assign/unassign.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14666
2015-12-04 16:29:31 -08:00
epriestley
dd0b09a610 Make "Quote" work with EditEngine in Paste and Maniphest
Summary: Ref T9132. This makes the "Quote" action on comments work properly in these applications.

Test Plan: Quoted text in each application.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14665
2015-12-04 16:29:29 -08:00
epriestley
8bbea6d41c Make "Add Action..." add actions at the bottom instead of the top
Summary: Ref T9132. Shhh this never happened shhhhhhh.

Test Plan: Selected multiple actions, saw them add at the bottom.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14664
2015-12-04 16:29:28 -08:00
epriestley
dc0d914134 Basic stacked action support for EditEngine
Summary: Ref T9132. This still has a lot of rough edges but the basics seem to work OK.

Test Plan: {F1012627}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14653
2015-12-03 12:32:02 -08:00
epriestley
b82863d972 Implement versioned drafts in EditEngine comment forms
Summary:
Ref T9132. Fixes T5031. This approximately implements the plan described in T5031#67988:

When we recieve a preview request, don't write a draft if the form is from a version of the object before the last update the viewer made.

This should fix the race-related (?) zombie draft comments that sometimes show up.

I just added a new object for this stuff to make it easier to do stacked actions (or whatever we end up with) a little later, since I needed to do some schema adjustments anyway.

Test Plan:
  - Typed some text.
  - Reloaded page.
  - Draft stayed there.
  - Tried real hard to get it to ghost by submitting stuff in multiple windows and typing a lot and couldn't, although I didn't bother specifically narrowing down the race condition.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5031, T9132

Differential Revision: https://secure.phabricator.com/D14640
2015-12-03 07:07:29 -08:00
epriestley
a1c7ba6b8b Initial support for comments/append-edits in EditEngine
Summary:
Ref T9132. This just replaces the "Add Comment" form in Paste with a generic flow in EditEngine.

No actual field-awareness or action stacking or anything quite yet, but that will come in a bit. This mildly regresses drafts (which don't seem like a big deal for Pastes). I'll hook those up again in the next diff, but I want to build them in a better way that will work with multiple actions in a generic way, and solve T5031.

Big practical advantage here is that applications don't need copy/pasted preview controllers.

Test Plan:
  - Saw previews.
  - Added comments.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14637
2015-12-03 07:06:25 -08:00
Chad Little
8d62ade70a Render Remarkup poorly in Phame Feed stories
Summary: Seeing if this is the correct path, then will apply in Pholio, Ponder.

Test Plan: epriestley

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: joshuaspence, Korvin

Maniphest Tasks: T9825

Differential Revision: https://secure.phabricator.com/D14646
2015-12-02 14:16:03 -08:00
epriestley
773ecb9a44 Support Conduit application of most CustomField transactions in EditEngine
Summary:
Ref T9132. Give most standard custom fields reasonable Conduit support so you can use the new `application.x` endpoints to set them.

Major missing field type is dates, again.

Test Plan: Used Conduit to set various custom fields on a package.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14635
2015-12-02 09:32:49 -08:00
epriestley
c1ae5321d7 Support HTTP parameter prefilling in EditEngine forms for CustomFields
Summary:
Ref T9132. This allows you to prefill custom fields with `?custom.x.y=value`, for most types of custom fields.

Dates (which are substantially more complicated) aren't supported. I'll just do those once the dust settles. Other types should work, I think.

Test Plan:
  - Verified custom fields appear on "HTTP Parameters" help UI.
  - Used `?x=y` to prefill custom fields on edit form.
  - Performed various normal edits.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14634
2015-12-02 09:32:26 -08:00
Chad Little
b5bd4c65c2 Update transactions for handleRequest
Summary: Updates Transactions for handleRequest

Test Plan: Leave Comment, View Raw, Delete, Quote, etc.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T8628

Differential Revision: https://secure.phabricator.com/D14629
2015-12-02 07:59:36 -08:00
epriestley
029b1b6733 Partially support CustomFields in EditEngine
Summary:
Ref T9132. This isn't perfect, but doesn't break any existing functionality. This stuff works:

  - Editing values.
  - Reordering fields.
  - All builtin field tyepes.

This stuff may not work yet:

  - Assigning custom field defaults.
  - Some conduit stuff.
  - Fully custom fields?
  - Locking/hiding fields? Didn't actually test this one.

I'll keep chipping away at that stuff. In some cases, it may be easier to convert all the CustomField apps first, although Differential might be a fair bit of work.

Test Plan:
Created a bunch of custom fields of every avialable type and edited them.

{F1008789}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14617
2015-12-02 05:21:31 -08:00
epriestley
9d59086d01 Consolidate transaction generation in EditType objects
Summary:
Ref T9132. This is a bit more cleanup to make adding CustomField support easier.

Right now, both `EditField` and `EditType` can actually generate a transaction. This doesn't matter too much in practice today, but gets a little more complicated a couple of diffs from now with CustomField stuff.

Instead, always use `EditType` to generate the transaction. In the future, this should give us less total code and make more things work cleanly by default.

Test Plan: Used web UI and Conduit to make various edits to pastes, including doing race-condition tests on "Projects".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14607
2015-11-30 09:01:00 -08:00
epriestley
56be700561 Improve code structure of PHID fields in EditEngine
Summary: Ref T9132. I had some hacks in place for dealing with Edge/Subscribers stuff. Clean that up so it's structured a little better.

Test Plan:
  - Edited subscribers and projects.
  - Verified things still show up in Conduit.
  - Made concurrent edits (added a project in one window, removed it in another window, got a clean result with a correct merge of the two edits).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14601
2015-11-30 09:00:37 -08:00
epriestley
50f257adee Allow EditEngine Conduit endpoints to accept object IDs and monograms
Summary:
Ref T9132. This is a quality-of-life improvement for new `application.edit` endpoints.

Instead of strictly requiring PHIDs, allow IDs or monograms. This primarily makes these endpoints easier to test and use.

Test Plan: Edited objects via API by passing IDs, PHIDs and monograms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14600
2015-11-30 09:00:24 -08:00
epriestley
acd955c6c9 Modularize application extensions to EditEngine
Summary:
Ref T9132. Currently, EditEngine had some branchy-`instanceof` code like this:

```
if ($object instanceof Whatever) {
  do_magic();
}

if ($object instanceof SomethingElse) {
  do_other_magic();
}
```

...where `Whatever` and `SomethingElse` are first-party applications like ProjectsInterface and SubscribersInterface.

This kind of code is generally bad because third-parties can't add new stuff, and it suggest something is kind of hacky in its architecture. Ideally, we would eventually get rid of almost all of this.

T9789 is a similar discussion of this for the next layer down (`TransactionEditor`) and plans to get rid of branchy-instanceofs there too.

Since I'm about to add more stuff here (for Custom Fields), split it out first so I'm not digging us any deeper than I already dug us.

Broadly, this allows third-party extensions to add fields to every EditEngine UI if they want, like we do for Policies, Subscribers, Projects and Comments today (and CustomFields soon).

Test Plan:
{F1007575}

  - Observed that all fields still appear on the form and seem to work correctly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14599
2015-11-30 08:59:27 -08:00
epriestley
b35f578ae9 Modernize Transaction value controller, fixing logged-out policy issue
Summary: Fixes T9869. This specific transaction endpoint was missing `shouldAllowPublic()`. Also modernize things a little.

Test Plan: Viewed a policy change by clicking the policy name from the transaction record on a public object while logged out.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9869

Differential Revision: https://secure.phabricator.com/D14606
2015-11-30 06:55:31 -08:00
epriestley
37893ba2e6 Allow EditEngine configurations to be disabled and marked as "Default"
Summary:
Ref T9132.

Let configurations be enabled/disabled. This doesn't do much right now.

Let configurations be marked as default entries in the application "Create" menu. This makes them show up in the application in a dropdown, so you can replace the default form and/or provide several forms.

In Maniphest, we'll do this to provide a menu something like this:

  - New Bug Report
  - New Feature Request
  - ADVANCED TASK CREATION!!11~ (only available for Community members)

Test Plan: {F1005679}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14584
2015-11-29 08:27:26 -08:00
Chad Little
a6e24cb2be Remove pro-white-background, re-style PHUIDocumentViewPro
Summary: This makes document views a little more automatic, and a little more style to the page. The Document itself remains on a pure white centered background, but footer and preceeding objects go back to the original body color. This provides a bit more depth and separation over content and definitions/comments.

Test Plan:
Tested Phriction, Diviner, Legalpad, Phame, Email Commands, HTTP Commands, with and without a footer.

{F1005853}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14582
2015-11-28 07:20:55 -08:00
epriestley
fc1c36106d Pass recently applied transactions to HeraldAdapters
Summary: Ref T9851. See T9860. This adds a missing capability to custom HeraldActions, to pave the way for removing the obsolete/undesirable WILLEDITTASK and DIDEDITTASK events.

Test Plan: See T9860 for a replacement action.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9851

Differential Revision: https://secure.phabricator.com/D14575
2015-11-26 08:53:08 -08:00
epriestley
b219285999 Fix handling of implicit comment transaction in paste creation
Summary:
Fixes T9850. The `getComment()` test should be a `hasComment()` test, in order to discard empty comments.

Also backport a couple of future fixes which can get you into trouble if you reconfigure forms in awkward ways.

Test Plan: Created a new paste without a comment.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9850

Differential Revision: https://secure.phabricator.com/D14571
2015-11-25 08:25:10 -08:00
epriestley
c034752578 Support comments as an EditEngine field
Summary:
Ref T9132. This adds an automatic "Comments" field, like the Subscribers/Projects/Policy fields.

The primary goals here are:

  - Allow users to make comments via Conduit.
  - In the future, get stackable action support.

As a side effect, this also allows you to put comments on create forms. This is a little silly but seems fine, and may be relevant on edit forms (which I'm not 100% sure how I want to handle yet). I've just hidden them by default for now.

Test Plan:
{F976036}

{F976037}

{F976038}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14515
2015-11-22 16:27:17 -08:00
epriestley
269e0bfc94 Allow EditEngine form fields to be locked and hidden
Summary:
Ref T9132. Allows fields to be locked (shown, but not modifiable) and hidden (not shown).

In both cases, default values are still respected.

This lets you do things like create a form that generates objects with specific projects, policies, etc.

Test Plan:
  - Set defaults.
  - Locked and hid a bunch of fields.
  - Created new objects using the resulting form.

{F975801}

{F975802}

{F975803}

{F975804}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14509
2015-11-22 16:25:32 -08:00
epriestley
53d5cd3950 Allow EditEngine forms to have defaults assigned
Summary: Ref T9132. Allow form configurations to include defaults (like default projects, spaces, policies, etc).

Test Plan:
Defaulted "Language" to "Rainbow", plus other adjustments:

{F975746}

{F975747}

{F975748}

{F975749}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14508
2015-11-22 16:25:00 -08:00
epriestley
9aee90f8c1 Allow form configurations to retitle and reorder forms and add preambles
Summary:
Ref T9132. This just makes edited forms do //something//, albeit not anything very useful yet.

You can now edit a form and:

  - Retitle it;
  - add a preamble (instructions on top of the form); and
  - reorder the form's fields.

Test Plan:
{F974632}

{F974633}

{F974634}

{F974635}

{F974636}

Reviewers: chad

Reviewed By: chad

Subscribers: hach-que

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14503
2015-11-22 15:12:57 -08:00
epriestley
06de605992 Extract PHIDs from transactions later, fixing Paste extraction/attachment
Summary:
Fixes T9787. Currently, file PHID extraction logic happens very early, before we normalize/merge/etc the transactions.

In D14390, I changed how the CONTENT transaction works: before, callers would pass in a file PHID. Afterward, they just pass in the content.

Passing in the content is generaly easier and feels more correct, but inadvertenly broke PHID extraction because converting the content into a file PHID now happened after we extracted the PHID. So we'd extract the entire text of the paste as a "file PHID", which wouldn't work.

Instead, extract file PHIDs later. This impacts a couple of other applications (Conpherence, Pholio) which receive an object or have an unusual file-oriented transaction.

Test Plan:
  - Made a new paste, verified the raw file attached to it properly.
  - Made and updated a mock, verified all the files attached properly.
  - Updated a Conpherence room image, verified the files attached properly.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9787

Differential Revision: https://secure.phabricator.com/D14494
2015-11-17 08:37:07 -08:00
epriestley
12dd9ec3ff Have EditEngine API methods provide the correct application to Conduit
Summary:
Fixes T9799. Currently, if you can't see an application like Paste, we fatal when trying to generate a result for `conduit.query`, because the new EditEngine-based `paste.edit` method doesn't "know" that it's a "Paste" method.

Straighten this out, and use policies and queries a little more correctly/consistently.

Test Plan:
  - Called `conduit.query` as a user who does not have permission to use Paste.
  - Before change: fatal.
  - After change: results, excluding "paste.*" methods.

Reviewers: chad

Reviewed By: chad

Subscribers: cburroughs

Maniphest Tasks: T9799

Differential Revision: https://secure.phabricator.com/D14492
2015-11-16 10:02:50 -08:00
epriestley
7e3d8082df Fix missing EditEngineConfig on indirect pathway through conduit.query
Summary: Fixes T9772. We now need an EditEngineConfiguration to do interesting things with EditEngine, but this public API wasn't properly making sure we have one.

Test Plan: Called `conduit.query` from web console. Fatal prior to patch; success afterward.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9772

Differential Revision: https://secure.phabricator.com/D14475
2015-11-12 11:22:37 -08:00
epriestley
0398097498 Allow ApplicationEditor forms to be reconfigured
Summary:
Ref T9132. This diff doesn't do anything interesting, it just lays the groundwork for more interesting future diffs.

Broadly, the idea here is to let you create multiple views of each edit form. For example, we might create several different "Create Task" forms, like:

  - "New Bug Report"
  - "New Feature Request"

These would be views of the "Create Task" form, but with various adjustments:

  - A form might have additional instructions ("how to file a good bug report").
  - A form might have prefilled values for some fields (like particular projects, subscribers, or policies).
  - A form might have some fields locked (so they can not be edited) or hidden.
  - A form might have a different field order.
  - A form might have a limited visibility policy, so only some users can access it.

This diff adds a new storage object (`EditEngineConfiguration`) to keep track of all those customizations and represent "a form which has been configured to look and work a certain way".

This doesn't let these configurations do anything useful/interesting, and you can't access them directly yet, it's just all the boring plumbing to enable more interesting behavior in the future.

Test Plan:
ApplicationEditor forms now let you manage available forms and edit the current form:

{F959025}

There's a new (bare bones) list of all available engines:

{F959030}

And if you jump into an engine, you can see all the forms for it:

{F959038}

The actual form configurations have standard detail/edit pages. The edit pages are themselves driven by ApplicationEditor, of course, so you can edit the form for editing forms.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14453
2015-11-10 10:24:40 -08:00
epriestley
2b41ed01c6 Fix no-op transaction error on paste.create Conduit API method
Summary:
Fixes T9735. I changed how the TYPE_LANGUAGE transction works a little but that accidentally tripped an error condition in `paste.create`.

  - Don't bail on no-effect transactions to `paste.create` (like not setting a language).
  - When a transaction type has no tailored UI message, make it easier to figure out which transaction is problematic.

Test Plan: Ran `arc paste ...` locally. Got an error before the patch, clean paste creation afterward.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9735

Differential Revision: https://secure.phabricator.com/D14440
2015-11-08 07:09:53 -08:00
lkassianik
28b8c8e212 HTML emails for Calendar event description changes should respect remarkup rules
Summary: Ref T7964, HTML emails for Calendar event description changes should respect remarkup rules

Test Plan: Create event and edit description, check that email has a correctly formatted remarkup description section.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T7964

Differential Revision: https://secure.phabricator.com/D13554
2015-11-07 07:39:52 -08:00
epriestley
621f806e3b Provide formal Users/Projects/Mailable fields for EditEngine
Summary: Ref T9132. This allows you to prefill EditEngine forms with stuff like `?subscribers=epriestley`, and we'll figure out what you mean.

Test Plan:
  - Did `/?subscribers=...` with various values (good, bad, mis-capitalized).
  - Did `/?projects=...` with various values (good, bad, mis-capitalized).
  - Reviewed documentation.
  - Reviewed {nav Config > HTTP Parameter Types}.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14404
2015-11-04 12:05:41 -08:00
epriestley
20e4c3fbd4 Modularize complex HTTP parameter types
Summary:
Ref T9132. We have several places in the code that sometimes need to parse complex types. For example, we accept all of these in ApplicationSearch and now in ApplicationEditor:

> /?subscribers=cat,dog
> /?subscribers=PHID-USER-1111
> /?subscribers[]=cat&subscribers[]=PHID-USER-2222

..etc. The logic to parse this stuff isn't too complex, but it isn't trivial either.

Right now it lives in some odd places. Notably, `PhabricatorApplicationSearchEngine` has some weird helper methods for this stuff. Rather than give `EditEngine` the same set of weird helper methods, pull all this stuff out into "HTTPParameterTypes".

Future diffs will add "Projects" and "Users" types where all the custom parsing/lookup logic can live. Then eventually the Search stuff can reuse these.

Generally, this just breaks the code up into smaller pieces that have more specific responsibilities.

Test Plan: {F944142}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14402
2015-11-04 12:05:21 -08:00
epriestley
9de4bc6f3a Slightly improve organization of PhabricatorApplicationEditEngine
Summary: Ref T9132. This just moves code around, breaks it up into some smaller chunks, tries to reduce duplication, and adds a touch of documentation.

Test Plan: Created and edited pastes.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14398
2015-11-04 12:05:06 -08:00
lkassianik
5c6d2be18f Helper method for max text field length and validate alias length
Summary: Ref T8992, Validate alias text field length.

Test Plan: Create Phurl with alias of more than 64 characters. Get error. Reduce length of alias to successfully save Phurl.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin

Maniphest Tasks: T8992

Differential Revision: https://secure.phabricator.com/D14403
2015-11-04 10:22:23 -08:00
Chad Little
39f8feab5a PHUIDocumentViewPro tweaks
Summary: Use in MailCommands and HTTP Parameters

Test Plan: Tested MailCommands in Paste, HTTP Parameters in Paste, Legalpad, Diviner. Mobile and Desktop breakpoints.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14397
2015-11-03 13:43:26 -08:00
epriestley
5030ba0401 Roughly generate transaction-oriented API methods from EditEngines
Summary:
Ref T5873. Ref T9132. This is really rough and feels pretty flimsy at the edges (missing validation, generality, modularity, clean error handling, etc) but gets us most of the way toward generating plausible "whatever.edit" Conduit API methods from EditEngines.

These methods are full-power methods which can do everything the edit form can, automatically support the same range of operations, and update when new fields are added.

Test Plan:
  - Used new `paste.edit` to create a new Paste.
  - Used new `paste.edit` to update an existing paste.
  - Applied a variety of different transactions.
  - Hit a reasonable set of errors.

{F941144}

{F941145}

{F941146}

{F941147}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5873, T9132

Differential Revision: https://secure.phabricator.com/D14393
2015-11-03 10:12:37 -08:00
epriestley
3dec4c7dbd Provide contextual documentation explaining how to prefill ApplicationEditor create forms
Summary:
Ref T9132. Although forms do generally support prefilling right now, you have to guess how to do it.

Provide an explicit action showing you which values are supported and how to prefill them. This is generated automatically when an application switches to ApplicationEditor.

Test Plan:
{F939804}

{F939805}

{F939806}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9132

Differential Revision: https://secure.phabricator.com/D14392
2015-11-03 10:12:17 -08:00
epriestley
105cbaaee1 Implement a basic version of ApplicationEditor in Paste
Summary:
Ref T9132. Ref T4768. This is a rough v0 of ApplicationEditor, which replaces the edit workflow in Paste.

This mostly looks and works like ApplicationSearch, and is heavily modeled on it.

Roughly, we define a set of editable fields and the ApplicationEditor stuff builds everything else.

This has no functional changes, except:

  - I removed "Fork Paste" since I don't think it's particularly useful now that pastes are editable. We could restore it if users miss it.
  - Subscribers are now editable.
  - Form field order is a little goofy (this will be fixed in a future diff).
  - Subscribers and projects are now race-resistant.

The race-resistance works like this: instead of submitting just the new value ("subscribers=apple, dog") and doing a set operation ("set subscribers = apple, dog"), we submit the old and new values ("original=apple" + "new=apple, dog") then apply the user's changes as an add + remove ("add=dog", "remove=<none>"). This means that two users who do "Edit Paste" at around the same time and each add or remove a couple of subscribers won't overwrite each other, unless they actually add or remove the exact same subscribers (in which case their edits legitimately conflict). Previously, the last user to save would win, and whatever was in their field would overwrite the prior state, potentially losing the first user's edits.

Test Plan:
  - Created pastes.
  - Created pastes via API.
  - Edited pastes.
  - Edited every field.
  - Opened a paste in two windows and did project/subscriber edits in each, saved in arbitrary order, had edits respected.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T4768, T9132

Differential Revision: https://secure.phabricator.com/D14390
2015-11-03 10:11:54 -08: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
Joshua Spence
495cb7a2e0 Mark PhabricatorPHIDType::getPHIDTypeApplicationClass() as abstract
Summary: Fixes T9625. As explained in a `TODO` comment, seems reasonable enough.

Test Plan: Unit tests.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, hach-que

Maniphest Tasks: T9625

Differential Revision: https://secure.phabricator.com/D14068
2015-11-03 06:47:12 +11:00
epriestley
2728a9f964 Allow builds to have parameters
Summary: Ref T9352. See D13635. Build targets can have variables already, but let builds have them too. This mostly enables future use cases (sub-builds, more sophisticated build triggers).

Test Plan: With a custom Herald rule + action like the one in T9352, updated a revision and saw it generate multiple builds with varying parameters.

Reviewers: chad, hach-que

Reviewed By: hach-que

Maniphest Tasks: T9352

Differential Revision: https://secure.phabricator.com/D14222
2015-10-02 06:32:08 -07:00
epriestley
3e60740c7c Slightly modernize transaction diff controller
Summary: Ref T9272. This doesn't fix anything, just a little cleanup while I was looking at it.

Test Plan: Clicked "Show Details" on a couple description changes, got the same effect for less code.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9272

Differential Revision: https://secure.phabricator.com/D14168
2015-09-25 11:15:57 -07:00
epriestley
de01f3e2e0 Add Maniphest Task email creator to CCs
Summary: Fixes T9369.

Test Plan:
  - Sent a mail with Mail.app to `bugs@local.phacility.com`.
  - Used "View Raw Mail", copy-pasted it into `mail.txt` on disk.
  - Ran `cat mail.txt | ./scripts/mail/manage_mail.php --process-duplicates`.
  - Saw task get created and me get added as CC.
  - Changed "To" to include another user, ran command again, saw task get created and other user get added as CC.

Reviewers: chad

Reviewed By: chad

Subscribers: Korvin

Maniphest Tasks: T9369

Differential Revision: https://secure.phabricator.com/D14086
2015-09-09 14:07:07 -07:00
epriestley
3ef270b292 Allow transaction publishers to pass binary data to workers
Summary:
Ref T8672. Ref T9187. Root issue in at least one case is:

  - User makes a commit including a file with some non-UTF8 text (say, a Japanese file full of Shift-JIS).
  - We pass the file to the TransactionEditor so it can inline or attach the patch if the server is configured for these things.
    - When inlining patches, we convert them to UTF8 before inlining. We must do this since the rest of the mail is UTF8.
    - When attaching patches, we send them in the original encoding (as file attachments). This is correct, and means we need to give the worker the raw patch in whatever encoding it was originally in: we can't just convert it to utf8 earlier, or we'd attach the wrong patch in some cases.
  - TransactionEditor does its thing (e.g., creates the commit), then gets ready to send mail about whatever it did.
  - The publishing work now happens in the daemon queue, so we prepare to queue a PublishWorker and pass it the patch (with some other data).
  - When we queue workers, we serialize the state data with JSON.

So far, so good. But this is where things go wrong:

  - JSON can't encode binary data, and can't encode Shift-JIS. The encoding silently fails and we ignore it.

Then we get to the worker, and things go wrong-er:

  - Since the data is bad, we fatal. This isn't a permanent failure, so we continue retrying the task indefinitely.

This applies several fixes:

  # When queueing tasks, fail loudly when JSON encoding fails.
  # In the worker, fail permanently when data can't be decoded.
  # Allow Editors to specify that some of their data is binary and needs special handling.

This is fairly messy, but some simpler alternatives don't seem like good ways forward:

  - We can't convert to UTF8 earlier, because we need the original raw patch when adding it as an attachment.
  - We could encode //only// this field, but I suspect some other fields will also need attention, so that adding a mechanism will be worthwhile. In particular, I suspect filenames //may// be causing a similar problem in some cases.
  - We could convert task data to always use a serialize()-based binary safe encoding, but this is a larger change and I think it's correct that things are UTF8 by default, even if it makes a bit of a mess. I'd rather have an explicit mess like this than a lot of binary data floating around.

The change to make `LiskDAO` will almost certainly catch some other problems too, so I'm going to hold this until after `stable` is cut. These problems were existing problems (i.e., the code was previously breaking or destroying data) so it's definitely correct to catch them, but this will make the problems much more obvious/urgent than they previously were.

Test Plan:
  - Created a commit with a bunch of Shift-JIS stuff in a file.
  - Tried to import it.

Prior to patch:

  - Broken PublishWorker with distant, irrelevant error message.

With patch partially applied (only new error checking):

  - Explicit, local error message about bad key in serialized data.

With patch fully applied:

  - Import went fine and mail generated.

Reviewers: chad

Reviewed By: chad

Subscribers: devurandom, nevogd

Maniphest Tasks: T8672, T9187

Differential Revision: https://secure.phabricator.com/D13939
2015-08-22 15:14:05 -07:00
Chad Little
5590642a1d Simplify some transaction translations
Summary: Ref T8700, I don't believe we need to be specific here about the object, since it displays on the object.

Test Plan: Change policy a few times on a task, see new translation

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T8700

Differential Revision: https://secure.phabricator.com/D13913
2015-08-16 17:47:58 -07:00
epriestley
7a1bbe6634 Add basic support for Herald outbound rules
Summary: Ref T5791. This is still very basic (no global actions, no support for matching headers/bodies/recipients/etc) but gets the core in.

Test Plan:
{F715209}

{F715211}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13897
2015-08-15 10:54:33 -07:00
Joshua Spence
368f359114 Use PhutilClassMapQuery instead of PhutilSymbolLoader
Summary: Use `PhutilClassMaQuery` instead of `PhutilSymbolLoader`, mostly for consistency. Depends on D13588.

Test Plan: Poked around a bunch of pages.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D13589
2015-08-14 07:49:01 +10:00
Chad Little
31cfdef0f7 Reduce colors in ApplicationTransactions for subscriptions
Summary: Remove previously added colors.

Test Plan: Load page, see less color (task)

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D13816
2015-08-06 17:30:47 -07:00
Chad Little
2383e741aa Add user icons / colors for subscriber transactions
Summary: Adds additional icon states for subscriber transactions. Also updated "eraser" to "trash" (man that icon is bad).

Test Plan: add a subscriber, remove a subscriber.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D13800
2015-08-05 12:40:47 -07:00
epriestley
5f76c71d78 Share target filtering code in HeraldAction
Ref T8726. This shares some target filtering code with the base class.
2015-08-03 14:34:37 -07:00
epriestley
776caa507b Modularize the Harbormaster "Run build plan" Herald action
Ref T8726. Modularizes "Run build plan" in Differential and Diffusion.
2015-08-03 14:33:26 -07:00
epriestley
343801d449 Show badges on timelines
Summary: Ref T8941.

Test Plan: {F659486}

Reviewers: chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T8941

Differential Revision: https://secure.phabricator.com/D13708
2015-07-24 16:04:44 -07:00
epriestley
262be61ee5 Merge branch 'master' into redesign-2015 2015-06-29 14:07:58 -07:00
Chad Little
626c7bc906 [Redesign] Clean up AphrontDialog
Summary: Ref T8099, Cleans up UI issues, adds `appendList` and renders lists and paragraphs with Remarkup UI.

Test Plan: Test Policy Dialogs, other various dialogs.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T8099

Differential Revision: https://secure.phabricator.com/D13463
2015-06-29 12:49:21 -07:00
epriestley
b39f5d651c Modernize transaction comment editor
Summary: Fixes T8703. The URI handling here was a little unusual.

Test Plan:
  - Edited and deleted comments in several applications, including Macro.
  - As an admin, deleted others' comments.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8703

Differential Revision: https://secure.phabricator.com/D13469
2015-06-29 11:30:27 -07:00
Eitan Adler
2536febed3 Remove duplicated duplicated words
Test Plan: eyeball it

Reviewers: joshuaspence, #blessed_reviewers, epriestley

Reviewed By: joshuaspence, #blessed_reviewers, epriestley

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D13462
2015-06-27 08:43:44 -07:00
Bob Trahan
7e0249d68c MetaMTA - more progress to mail app
Summary:
Ref T5791. This diff adds a "sensitive" flag to `PhabricatorMetaMTAMail`, defaults it to true in the constructor, and then sets it to false in teh application transaction editor. Assumption here is that sensitive emails are basically all the emails that don't flow through the application transaction editor.

This diff also gets a basic "mail view" page up and going.

This diff also fixes a bug writing recipient edges; the actor was being included.

This bug also fixes a querying bug; we shouldn't do the automagic join of $viewer is recipient or $viewer is actor if folks are querying for recipients or actors already. The bug manifested itself as having the "inbox" be inbox + outbox.

Test Plan: viewd list of messages. viewed message detail.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T5791

Differential Revision: https://secure.phabricator.com/D13406
2015-06-23 12:55:44 -07:00
Bob Trahan
1bb2978a89 Desktop Notification support
Summary:
Fixes T4139. Adds a "Desktop Notifications" panel to settings. For now, we start with "Send Desktop Notifications Too" functionality. We can try to be fancy later and only send desktop notifications if the web app doesn't have focus, etc.

Test Plan:
Made some comments as a test user on a task and got purdy desktop notifications using Chrome. Then did it again with Firefox.

Played around with permissions form with Chrome and got helpful information about what was up. Played around with Firefox and got similar results, except canceling the dialogue didn't invoke my handler code somehow. Oh Firefox!

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: rbalik, tycho.tatitscheff, joshuaspence, epriestley, Korvin

Maniphest Tasks: T4139

Differential Revision: https://secure.phabricator.com/D13219
2015-06-22 13:11:37 -07:00
epriestley
af8ad58e6b Probably fix notifications not being properly marked as unread
Summary: Fixes T8586. This wasn't quite right in D13320.

Test Plan: iiam

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8586

Differential Revision: https://secure.phabricator.com/D13331
2015-06-17 10:43:25 -07:00
epriestley
30c4783c42 Dramatically limit the range of failures which can cause duplicate mail
Summary:
Ref T8574. Currently, failures during mail body construction, feed publishing, or search indexing could cause us to retry the publishing task and potentially send duplicate mail.

Instead, build (but do not send) the mail first, then send all the mail at the very end.

This isn't completley perfect, but should make it enormously harder for duplicate mail to be generated.

Test Plan: Sent some mail, ran the daemons, saw it show up normally in the outbound queue.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8574

Differential Revision: https://secure.phabricator.com/D13320
2015-06-16 16:43:24 -07:00
Joshua Spence
b6d745b666 Extend from Phobject
Summary: All classes should extend from some other class. See D13275 for some explanation.

Test Plan: `arc unit`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D13283
2015-06-15 18:02:27 +10:00
epriestley
3de3a72dd8 Add a "Subscribers" object policy
Summary:
Ref T5681. Getting this to work correctly is a bit tricky, mostly because of the policy checks we do prior to applying an edit.

I think I came up with a mostly-reasonable approach, although it's a little bit gross. It uses `spl_object_hash()` so it shouldn't be able to do anything bad/dangerous (the hints are strictly bound to the hinted object, which is a clone that we destroy moments later).

Test Plan:
  - Added + ran a unit test.
  - Created a task with a "Subscribers" policy with me as a subscriber (without the hint stuff, this isn't possible: since you aren't a subscriber *yet*, you get a "you won't be able to see it" error).
  - Unsubscribed from a task with a "Subscribers" policy, was immediately unable to see it.
  - Created a task with a "subscribers" policy and a project subscriber with/without me as a member (error / success, respectively).

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5681

Differential Revision: https://secure.phabricator.com/D13259
2015-06-13 15:45:17 -07:00
epriestley
466755476a Allow PolicyRules to serve as "Object Policies"
Summary:
Ref T5681. Ref T8488. This allows policy rules to provide "Object Policies", which are similar to the global/basic policies:

  - They show up directly in the dropdown (you don't have to create a custom rule).
  - They don't need to create or load anything in the database.

To implement one, you just add a couple methods on an existing PolicyRule that let Phabricator know it can work as an object policy rule.

{F494764}

These rules only show up where they make sense. For example, the "Task Author" rule is only available in Maniphest, and in "Default View Policy" / "Default Edit Policy" of the Application config.

This should make T8488 easier by letting us set the default policies to "Members of Thread", without having to create a dedicated custom policy for every thread.

Test Plan:
  - Set tasks to "Task Author" policy.
  - Tried to view them as other users.
  - Viewed transaction change strings.
  - Viewed policy errors.
  - Set them as default policies.
  - Verified they don't leak into other policy controls.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5681, T8488

Differential Revision: https://secure.phabricator.com/D13257
2015-06-13 15:44:38 -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
6d6211d441 Use ApplicationTransactions in ApplicationEmail
Summary:
Ref T8498. I want to add Spaces to these, and the logic for getting Spaces right is a bit tricky, so swap these to ApplicationTransactions.

One new piece of tech: made it easier for Editors to raise DuplicateKeyException as a normal ValidationException, so callers don't have to handle this case specially.

One behavioral change: we no longer require these addresses to be at the `auth.email-domains` domains -- I think this wasn't quite right in the general case. It's OK to require users to have `@mycompany.com` addresses but add `@phabricator.mycompany-infrastructure.com` addresses here if you want.

Test Plan:
  - Tried to create a duplicate email.
  - Tried to create an empty email.
  - Tried to create an invalid email.
  - Created a new email.
  - Deleted an email.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8498

Differential Revision: https://secure.phabricator.com/D13246
2015-06-11 10:15:49 -07:00
epriestley
88e7cd158f Allow Spaces to be archived
Summary:
Ref T8377. This adds a standard disable/enable feature to Spaces, with a couple of twists:

  - You can't create new stuff in an archived space, and you can't move stuff into an archived space.
  - We don't show results from an archived space by default in ApplicationSearch queries. You can still find these objects if you explicitly search for "Spaces: <the archived space>".

So this is a "put it in a box in the attic" sort of operation, but that seems fairly nice/reasonable.

Test Plan:
  - Archived and activated spaces.
  - Used ApplicationSearch, which omitted archived objects by default but allowed searches for them, specifically, to succeed.
  - Tried to create objects into an archived space (this is not allowed).
  - Edited objects in an archived space (this is OK).

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8377

Differential Revision: https://secure.phabricator.com/D13238
2015-06-11 10:13:47 -07:00
epriestley
a06618f879 Fix an issue where "Send an email to..." rules might be discarded
Summary: Fixes T8464. We could lose the additional users from "Send an email..." rules //if// Herald did not apply any other transactions to the task.

Test Plan:
  - Destroyed all Herald rules.
  - Created a single "Send an email to..." rule.
  - Created a task.
  - Saw target get an email.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T8464

Differential Revision: https://secure.phabricator.com/D13245
2015-06-11 05:53:29 -07:00
epriestley
739bdeccab Improve some Spaces behaviors
Summary:
Ref T8449. Try out some more subtle behaviors:

  - Make the "Space" control part of the policy control, so the UI shows "Visible To: [Space][Policy]". I think this helps make the role of spaces more clear. It also makes them easier to implement.
  - Don't show the default space in headers: instead, show nothing.
  - If the user has access to only one space, pretend spaces don't exist (no edit controls, no header stuff).

This might be confusing, but I think most of the time it will all align fairly well with user expectation.

Test Plan:
  - Viewed a list of pastes (saw Space with non-default space, no space with default space, no space with user in only one space).
  - Viewed a paste (saw Space with non-default space, saw no space with default space, saw no space with user in only one space).
  - Edited spaces on objects (control as privileged user, no control as locked user).
  - Created a new paste in a space (got space select as privileged user, no select as locked user).

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8449

Differential Revision: https://secure.phabricator.com/D13229
2015-06-10 15:52:18 -07:00
epriestley
9c82881cac Fix "unmarked 0 inline comments as not undone" transactions
Summary:
Fixes T8483. I did this incorrectly in D13159, by doing it correctly first and then editing it carelessly. For most transaction types, it didn't matter, but did for inline state.

Also, clean up any bad inline state transactions.

Test Plan:
  - Ran migration, bad transactions vanished.
  - Marked some inline comments as done.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8483

Differential Revision: https://secure.phabricator.com/D13226
2015-06-09 13:30:45 -07:00
Joshua Spence
f47e69c015 Mark some strings for translation
Summary: Add some more `pht`izations.

Test Plan: Eyeball it.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D13200
2015-06-09 23:06:52 +10:00
epriestley
d6afce7d30 Stop "join project" from trying to write an inverse edge on Users
Summary: Now that Users implement PhabricatorApplicationTransactionInterface, we try to write an inverse edge. At least for now, we should retain the old behavior instead.

Test Plan:
  - Unit tests which cover this stuff pass again.
  - Grepped for other `instanceof PhabricatorApplicationTransactionInterface`, the all seemed either benign or irrelevant.

Reviewers: joshuaspence, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D13215
2015-06-08 14:45:22 -07:00
epriestley
c3b11439f2 Apply Herald subscription effects immediately
Summary:
Fixes T8464. We could incorrectly use a cached value when computing CC's.

Just load a fresh value. There are no other callers that would benefit from this cache, so it's more complicated to reload it correctly prior to publishing than to just skip it.

Also make the PHID headers unique.

Test Plan:
  - Verified that users received mail about the transactions which caused them to be added to an object.
  - Veirfied that headers no longer have redundant values.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8464

Differential Revision: https://secure.phabricator.com/D13206
2015-06-08 10:50:13 -07:00
epriestley
ef90007a21 Support Spaces transactions
Summary:
Ref T8424. This adds crude integration with Paste's edit/view workflows: you can change the space a Paste appears in, see transactions, and get a policy callout.

Lots of rough edges and non-obviousness but it pretty much works.

Test Plan:
  - Created and updated Pastes.
  - Moved them between spaces, saw policy effects.
  - Read transactions.
  - Looked at feed.
  - Faked query to return no spaces, saw control and other stuff vanish.
  - Faked query to return no spaces, created pastes.
  - Tried to submit bad values and got errors.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T8424

Differential Revision: https://secure.phabricator.com/D13159
2015-06-05 10:42:49 -07:00
epriestley
98aae51c3d Fix an issue with mentions in transactions
Ref T6367. Fixes T8415.

Maniphest filters transactions too early. This happens automatically later. Remove the code.

Transactions should be filtered per-user. If a transaction is hidden for some users, we shouldn't mail them. Move the filtering logic to be per-user.

Stack:

```
[Thu Jun 04 05:51:05.371061 2015] [:error] [pid 25111] [client 127.0.0.1:56497] [2015-06-04 05:51:05] EXCEPTION: (Exception) Transaction ("PHID-XACT-TASK-x4jlylat47s6ttr", of type "core:edge") requires a handle ("PHID-DREV-rs7jaoxbcb3av6biq4b5") that it did not load. at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:277]
[Thu Jun 04 05:51:05.372546 2015] [:error] [pid 25111] [client 127.0.0.1:56497] arcanist(head=master, ref.master=4e83efb31d3e), instances(head=master, ref.master=db56d5d6ad91), ledger(head=master, ref.master=5694485699a4), libcore(), phabricator(head=xaction1, ref.master=04a22a8fa443, ref.xaction1=04a22a8fa443, custom=17), phutil(head=master, ref.master=c2cd90ee7aec), services(head=master, ref.master=2d76591c4f87)
[Thu Jun 04 05:51:05.372559 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #0 <#2> PhabricatorApplicationTransaction::getHandle(string) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:463]
[Thu Jun 04 05:51:05.372564 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #1 <#2> PhabricatorApplicationTransaction::shouldHide() called at [<phabricator>/src/applications/maniphest/storage/ManiphestTransaction.php:163]
[Thu Jun 04 05:51:05.372568 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #2 <#2> ManiphestTransaction::shouldHide() called at [<phutil>/src/utils/utils.php:428]
[Thu Jun 04 05:51:05.372572 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #3 <#2> mfilter(array, string, boolean) called at [<phabricator>/src/applications/maniphest/editor/ManiphestTransactionEditor.php:380]
[Thu Jun 04 05:51:05.372576 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #4 <#2> ManiphestTransactionEditor::shouldSendMail(ManiphestTask, array) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:957]
[Thu Jun 04 05:51:05.372580 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #5 <#2> PhabricatorApplicationTransactionEditor::applyTransactions(ManiphestTask, array) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:2858]
[Thu Jun 04 05:51:05.372585 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #6 <#2> PhabricatorApplicationTransactionEditor::applyInverseEdgeTransactions(DifferentialRevision, DifferentialTransaction, integer) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:569]
[Thu Jun 04 05:51:05.372589 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #7 <#2> PhabricatorApplicationTransactionEditor::applyBuiltinExternalTransaction(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/differential/editor/DifferentialTransactionEditor.php:615]
[Thu Jun 04 05:51:05.372594 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #8 <#2> DifferentialTransactionEditor::applyBuiltinExternalTransaction(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:489]
[Thu Jun 04 05:51:05.372611 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #9 <#2> PhabricatorApplicationTransactionEditor::applyExternalEffects(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:827]
[Thu Jun 04 05:51:05.372616 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #10 <#2> PhabricatorApplicationTransactionEditor::applyTransactions(DifferentialRevision, array) called at [<phabricator>/src/applications/differential/controller/DifferentialCommentSaveController.php:124]
[Thu Jun 04 05:51:05.372621 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #11 <#2> DifferentialCommentSaveController::processRequest() called at [<phabricator>/src/aphront/AphrontController.php:33]
[Thu Jun 04 05:51:05.372625 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #12 <#2> AphrontController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:226]
[Thu Jun 04 05:51:05.372629 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #13 phlog(Exception) called at [<phabricator>/src/aphront/configuration/AphrontDefaultApplicationConfiguration.php:226]
[Thu Jun 04 05:51:05.372633 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #14 AphrontDefaultApplicationConfiguration::handleException(Exception) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:230]
[Thu Jun 04 05:51:05.372637 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #15 AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink, MultimeterControl) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:140]
[Thu Jun 04 05:51:05.372641 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #16 AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:19]
```

Auditors: btrahan
2015-06-04 06:05:24 -07:00
epriestley
069e60d2ff Send mail to targets in the user's translation
Summary: Ref T6367.

Test Plan:
  - Added and executed unit tests.
  - Sent mail to A (en_US) and B (en_A*).
  - Got one mail in English and one mail in ENGLISH.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6367

Differential Revision: https://secure.phabricator.com/D13142
2015-06-03 18:59:33 -07:00
epriestley
6db97bde12 Build separate mail for each recipient, honoring recipient access levels
Summary:
Ref T6367. Removes `multiplexMail()`!

We can't pass a single body into a function which splits it anymore: we need to split recipients first, then build bodies for each recipient list. This lets us build separate bodies for each recipient's individual translation/access levels.

The new logic does this:

  - First, split recipients into groups called "targets".
    - Each target corresponds to one actual mail we're going to build.
    - Each target has a viewer (whose translation / access levels will be used to generate the mail).
    - Each target has a to/cc list (the users who we'll ultimately send the mail to).
  - For each target, build a custom mail body based on the viewer's access levels and settings (language prefs not actually implemented).
  - Then, deliver the mail.

Test Plan:
  - Read new config help.

Then did a bunch of testing, primarily with `bin/mail list-outbound` and `bin/mail show-outbound` (to review generated mail), `bin/phd debug taskmaster` (to run daemons freely) and `bin/worker execute --id <id>` (to repeatedly test a specific piece of code after identifying an issue).

With `one-mail-per-recipient` on (default):

  - Sent mail to multiple users.
  - Verified mail showed up in `mail list-outbound`.
  - Examined mail with `mail show-outbound`.
  - Added a project that a subscriber could not see.
    - Verified it was not present in `X-Phabricator-Projects`.
    - Verified it was rendered as "Restricted Project" for the non-permissioned viewer.
  - Added a subscriber, then changed the object policy so they could not see it and sent mail.
    - Verified I received mail but the other user did not.
  - Enabled public replies and verified mail generated with public addresses.
  - Disabld public replies and verified mail generated with private addresses.

With `one-mail-per-recipient` off:

  - Verified that one mail is sent to all recipients.
  - Verified users who can not see the object are still filtered.
  - Verified that partially-visible projects are completely visible in the mail (this violates policies, as documented, as the best available compromise).
  - Enabled public replies and verified the mail generated with "Reply To".

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: carlsverre, epriestley

Maniphest Tasks: T6367

Differential Revision: https://secure.phabricator.com/D13131
2015-06-03 18:59:31 -07:00