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

10565 commits

Author SHA1 Message Date
Chad Little
551732b962 Basic NUX states for Phriction
Summary: Adds a basic nux for `/` and not found documents. Ref T10023

Test Plan: Visit a clean install, see Welcome page. Visit a non built page, see not found UX

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T10023

Differential Revision: https://secure.phabricator.com/D14854
2015-12-22 12:14:44 -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
61a92df66e Fix two issues with Phurl / Badges mail generation
Summary:
  - Phurl is missing a ReplyHandler / MailReceiver (all of this code should get cleaned up eventually, but I don't plan to get to it for a while).
  - Badges has a bad call.

This should clean up some bad daemon tasks.

Test Plan: Saw fewer daemon errors after these changes.

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14852
2015-12-22 08:19:53 -08:00
epriestley
96fe8c0b83 Implement basic ngram search for Owners Package names
Summary:
Ref T9979. This uses ngrams (specifically, trigrams) to build a reasonably efficient index for substring matching. Specifically, for a package like "Example", with ID 123, we store rows like this:

```
< ex, 123>
<exa, 123>
<xam, 123>
<amp, 123>
<mpl, 123>
<ple, 123>
<le , 123>
```

When the user searches for `exam`, we join this table for packages with tokens `exa` and `xam`. MySQL can do this a lot more efficiently than it can process a `LIKE "%exam%"` query against a huge table.

When the user searches for a one-letter or two-letter string, we only search the beginnings of words. This is probably what they want, the only thing we can do quickly, and a reasonable/expected behavior for typeaheads.

Test Plan:
  - Ran storage upgrades and search indexer.
  - Searched for stuff with "name contains".
  - Used typehaead and got sensible results.
  - Searched for `aabbccddeeffgghhiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz` and saw only 16 joins.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14846
2015-12-22 08:00:33 -08:00
Chad Little
5c8025c41d Add some more consistant NUX to Phame
Summary: Adds a no visible blogs and no posts nux state using new UI. Ref T10032

Test Plan: Archived all my blogs, got no posts fallback. Test a New Blog, got create a post, logged out, saw no create button.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T10032

Differential Revision: https://secure.phabricator.com/D14848
2015-12-22 07:12:17 -08:00
epriestley
426d648681 In Drydock, don't reset current branch to point at unrelated commit
Summary:
Fixes T10037. When we're building commit `aabbccdd`, we currently do this to check it out:

  git reset --hard aabbccdd

However, this has an undesirable side effect of moving the current branch pointer to point at `aabbccdd`. The current branch pointer may be some totally different branch which `aabbccdd` is not part of, so this is confusing and misleading.

Instead, use `git reset --hard HEAD` to get the primary effect we want (destroying staged changes) and then `git checkout aabbccdd` to checkout the commit in a detached HEAD state.

Test Plan:
  - Ran a build (a commit-focused operation) successfully.
  - Verified working copy was pointed at a detached HEAD afterward:

```
builder@sbuild001:/var/drydock/workingcopy-167/repo/git-test-ii$ git status
HEAD detached at ffc7635
nothing to commit, working directory clean
```

  - Ran a land (a branch-foused operation) successfully.
  - Verified working copy was pointed at a branch afterward:

```
builder@sbuild001:/core/data/drydock/workingcopy-168/repo/git-test$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean
```

Reviewers: chad

Reviewed By: chad

Subscribers: yelirekim

Maniphest Tasks: T10037

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

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

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

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6884, T10004

Differential Revision: https://secure.phabricator.com/D14849
2015-12-21 17:35:09 -08:00
epriestley
a761f73384 Allow index extensions to skip indexing if the object has not changed
Summary:
Fixes T9890. This allows IndexExtensions to emit an object version.

Before we build indexes, we check if the indexed version is the same as the current version. If it is, we just don't call that extension.

T9890 has a case where this is useful: a script went crazy and posted thousands of comments to a single task.

Without versioning, that results in the same comments being indexed over and over again. With versioning, most of the queue could just exit without doing any work.

Test Plan:
  - Added a `sleep(1)` to the actual indexing, used `bin/search index --background` to queue up a lot of tasks, ran them with `bin/phd debug task`, saw them complete very quickly with only one actual index operation performed.
  - Used `bin/search index --trace` and `bin/search index --trace --background` to observe the behavior of queries against the index version store, which looked sensible.
  - Made comments/transactions, saw versions update.
  - Used `bin/remove destroy`, verified index versions were purged.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9890

Differential Revision: https://secure.phabricator.com/D14845
2015-12-21 17:27:14 -08:00
epriestley
23c42486e4 Rename "SearchEngine" to "FulltextStorageEngine"
Summary:
Ref T9979. I picked this name long before the advent of modern "Engine" architecture and it ended up being pretty confusing.

Rename "SearchEngine" (currently: mysql or elasticsearch, used to store and query fulltext indexes) to "FulltextStorageEngine" to make it more clear what it does and disambituate it from ApplicationSearch, which also has a bunch of stuff called "SearchEngine", "SearchEngineExtension", etc.

Test Plan: Grepped for `phabricatorsearchengine`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

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

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14842
2015-12-21 17:25:23 -08:00
epriestley
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
aab1574e33 Remove TYPE_SEARCH_DIDUPDATEINDEX event
Summary:
Ref T9979. This event had one weird callsite and no known third-party callers. It can be done more cleanly as an extension, now.

This index is used to allow us to "Group By: Project" in Maniphest without joining into the Projects database.

Test Plan:
  - Ran a query with "Group By: Project" in Maniphest.
  - Renamed project "Apples" to "Zebras".
  - Reloaded page.
  - UI properly moved "Zebras" tasks to the bottom of the list.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14836
2015-12-21 17:23:59 -08:00
epriestley
02f82c2af5 Modularize fulltext indexing of Projects, Subscriptions and Custom Fields
Summary: Ref T9979. This is going to become `FulltextEngine`, but pave the way for that by pulling extensions out of it.

Test Plan:
{F1036624}

  - Used `bin/search index Txxx`, saw projects, subscribers and custom fields rebuild in the index.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9979

Differential Revision: https://secure.phabricator.com/D14835
2015-12-21 17:04:25 -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
Chad Little
5fecd55d6e More NUX states
Summary: Ref T10032, adds "Basic" NUX to more applications.

Test Plan: Visit each with ?nux=true and click on the create link. T10032 is tracking which apps need general modernization to pick up these changes.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T10032

Differential Revision: https://secure.phabricator.com/D14847
2015-12-21 13:13:44 -08:00
Chad Little
675be8efc5 Add more NUX states
Summary: Adds basic NUX to Dashboards, Herald, Repositories, Maniphest. Note Herald and Dashboard Panels don't fine the nux for some reason, assume they will when modernized?

Test Plan: Read text, click buttons.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14844
2015-12-21 11:15:54 -08:00
Chad Little
bde9ac43e7 Add various NUX states
Summary: Adds basic NUX UI to Countdown, Paste, Phurl, Ponder, Slowvote, Macro, and Pholio.

Test Plan: Review each with ?nux=true. Click on Create Button.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14840
2015-12-21 09:55:54 -08:00
Chad Little
75ba2c0926 Correct some Pirate translations
Summary: Swapped these by mistake.

Test Plan: load pirate english, read

Reviewers: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14838
2015-12-21 08:04:23 -08:00
Chad Little
c6f3a03209 Basic NUX blank states
Summary: Implement in Badges

Test Plan:
Test with nux=true.

{F1033431}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: johnny-bit, Korvin

Differential Revision: https://secure.phabricator.com/D14833
2015-12-21 07:39:46 -08:00
Chad Little
006321cce7 Add a pirate translation
Summary: Basic Pirate, mostly Maniphest

Test Plan: Play lots with Maniphest

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14830
2015-12-20 07:03:18 -08:00
epriestley
8a81d208c4 Don't show "master (branched from master)" in UI
Summary:
Ref T3462. If someone works directly on `master`, we currently show "Branch: master (branched from master)" in the UI.

Although this is sort of technically accurate, it is confusing.

Instead, just show "Branch: master" in this situation.

Test Plan: Saw "master" instead of "master (branched from master)".

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T3462

Differential Revision: https://secure.phabricator.com/D14829
2015-12-19 12:57:59 -08:00
epriestley
dbb84f1ddc Add basic NUX support to SearchEngines
Summary:
This is just putting a hook in that pretty much works. Behavior:

  - If you visit `/maniphest/?nux=true`, it always shows NUX for testing.
  - Otherwise, it shows NUX if there are no objects in the application yet.

Test Plan: {F1031846}

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14828
2015-12-19 12:57:13 -08:00
Chad Little
9d1ba9c038 Add a Read More link to PHUIDocumentSummaryView
Summary: Currently it's difficult to notice posts may be much longer than the summary (in most cases, actually), Adds a consistent "Read More" link to the full post. Also made sure "violet" was more consistantly used.

Test Plan:
Review summaries in Phame

{F1031799}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14827
2015-12-19 12:49:23 -08:00
epriestley
4daf2eb5de Update library map. 2015-12-19 11:55:59 -08:00
Nick Zheng
8eec9e2c0e Provide a more straightforward way to revoke SSH keys by finding and destroying the objects
Summary: Ref T9967

Test Plan:
Ran migrations.
Verified database populated properly with PHIDs (SELECT * FROM auth_sshkey;).
Ran auth.querypublickeys conduit method to see phids show up
Ran bin/remove destroy <phid>.
Viewed the test key was gone.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin

Maniphest Tasks: T9967

Differential Revision: https://secure.phabricator.com/D14823
2015-12-19 11:52:26 -08:00
epriestley
aeae0e7028 Prepare Projects schema for subprojects
Summary:
Ref T10010. This does some cleanups on the schema:

  - `viewPolicy`, `editPolicy` and `joinPolicy` were nullable, but should never be `null`. Set them to defaults if they're null, then make the column non-nullable.
  - Rename `phrictionSlug` to `primarySlug` and stop adding and removing trailing slashes from it.
  - Add new columns to support milestones and non-milestone subprojects.
  - Drop very old subprojectPHIDs column. This hasn't done anything in the UI for years and years, and isn't particularly realistic to migrate forward.

The new columns aren't reachable from the UI.

Test Plan:
  - Applied patches.
  - Grepped for `phrictionSlug`.
  - Grepped for `subprojectPHIDs`.
  - Created tasks.
  - Edited tasks.
  - Verified existing tasks still had primary slugs.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10010

Differential Revision: https://secure.phabricator.com/D14825
2015-12-19 09:21:36 -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
46e690b2fd Fix value reading in custom Text and Remarkup fields in EditEngine
Summary: Ref T10004. I missed these previously, so they didn't work quite right. Restore them to glory.

Test Plan: Edited remarkup and text custom fields on an Owners package.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14821
2015-12-18 11:57:44 -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
7168d8edd9 Make Drydock reclaim unused resources when it reaches a resource limit
Summary:
Fixes T9994. Currently, when Drydock can't allocate a new resource because some limit has been reached, it waits patiently for a resource to become available.

It is possible that no resource will ever become available. Particularly with "Working Copy" resources, the new lease may want a copy of `rB`, but the resource may already be maxed out on `rA`.

Right now, no process exists to automatically reclaim the unused `rA`.

When we encounter this situation, try to reclaim one of the other resources if it is just sitting there unused.

Specifically:

  - Add a "reclaim" command which means "release this resource //if// it is completely unused".
  - Add a `bin/drydock reclaim` to send this command to every active resource.
  - When we try to acquire a resource and can't, but only because of some kind of limit / utilization problem, try to release an unused resource to free up some room.

Test Plan:
  - Set "Working Copy" resource limit to 1.
  - Ran "Test Configuration" in `rA`, which worked.
  - Ran "Test Configuration" in `rB`, which hung forever.
  - Applied patch.
  - Ran "Test Configuration" in `rB`, saw it reclaim the `rA` resource, use the slot, then succeed.
  - Ran "Test Configuration" in `rA` again, saw it grab the slot back.
  - Ran `bin/drydock reclaim` and saw it reclaim a bunch of old orphaned resources.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9994

Differential Revision: https://secure.phabricator.com/D14819
2015-12-18 11:55:51 -08:00
epriestley
e9af4f8970 Fix an issue where Drydock followup tasks would not queue if the main task failed
Summary:
Ref T9994. This fixes the first issue discussed on that task, which is that when a merge fails after "arc land", we would not clean up all the leases properly.

Specifically, when a merge fails, we use `queueTask()` to schedule a followup task. This followup destroys the lease and frees the underlying resource.

However, the default behavior of `queueTask()` is to //not queue tasks// if the parent task fails. This is a reasonable, safe behavior that was originally introduced in D8774, where it kept us from sending too much mail if a task did "send some mail" and then failed a little later on and got retried.

Since I think the default behavior is correct, I just special cased the behavior for Drydock to make it queue even on failure. These are the only types of followup tasks we currently want to queue on main task failure.

(It's possible that future Blueprints might want some kind of more specialized behavior, where some tasks queue only on success, but we can cross that bridge when we come to it.)

Test Plan:
  - See T9994#149878 for test case setup.
  - I ran that test case again with this patch, and saw the followup task queue properly in the `--trace` log, a correspoinding update task show up in `/daemon/`, and the lease get destroyed when I ran it a moment later.

{F1029915}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9994

Differential Revision: https://secure.phabricator.com/D14818
2015-12-18 08:17:04 -08:00
epriestley
5bbf0ba132 Add a setup warning about deprecated Maniphest policy configuration
Summary: Ref T10003. Give installs more warning about these changes.

Test Plan: Changed configuration, saw warning. Reset configuration, no warning.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10003

Differential Revision: https://secure.phabricator.com/D14817
2015-12-18 08:16:53 -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
a07a06ab08 Give custom controls passable disabled states
Summary: Fixes T9871. Ref T10004. These won't win any awards but it fixes them being incredibly weird and confusing.

Test Plan:
{F1029090}

  - Tried to use controls, got reasonable behavior.
  - Used normal controls to make sure I didn't break anything.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9871, T10004

Differential Revision: https://secure.phabricator.com/D14814
2015-12-17 15:13:28 -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
8a0dfa94d4 Make configured and EditEngine defaults work correctly for custom fields
Summary:
Ref T10004. Fixes T5158. There was a long-standing issue with defaults not working properly, but EditEngine has made it more obvious because it's a lot easier to set defaults now.

The issue is basically that the defaults are getting set as the field's real value early on, so when we go to generate the transaction "old value" later, we build a transaction that uses the //new// value as both the "new value" and "old value". Then the engine says "you didn't change anything, so I'm going to ignore this" and drops it.

To fix this, return `null` as the "old value" by default, and add a call to overwrite that after we load a legitimate old value.

This fix is a touch iffy, but I have some grand plans to clean up the CustomField stuff more broadly later on.

Test Plan:
  - Set config defaults on select/typeahead fields, created and edited tasks.
  - Set form defaults on select/typehaead fields, created and edited tasks.
  - In all cases, transactions and state accurately reflected edits.
  - Set defaults on //hidden// fields, verified forms respected them correctly.
  - This does generate some fluffy transactions, but I'll deal with those in T7661.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5158, T10004

Differential Revision: https://secure.phabricator.com/D14809
2015-12-17 10:44:41 -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
5d76a4b0a2 Improve handling of multiple edit forms when logged out
Summary:
Ref T10004. Currently, when a logged-out user visits an application like Maniphest, we show them a disabled "Create Task" button with no dropdown menu.

This is technically correct in some sense because none of the items in the menu will work, but we can be more helpful and show the items, just in a disabled state:

{F1028903}

When the user clicks these, they'll be pushed through the login flow and (after D14804) end up on the same page they were on when they selected the item. From here, they can proceed normally.

I changed "...to continue." to "...to take this action." to hopefully be a little more clear. In particular, we do not //continue// the action after you log in: you end up back on the same page you started on. For example, if you clicked "Create New Bug" from the list view, you end up back on the list view and need to click "Create New Bug" again. If you clicked "Edit Task" from some task detail page, you end up on the task detail page and have to click "Edit Task" again.

I think this behavior is always very good. I think it is often the best possible behavior: for actions like "Edit Blocking Tasks" and "Merge Duplicates In", the alternatives I can see are:

  - Send user back to task page (best?)
  - Send user to standalone page with weird dialog on it and no context (underlying problem behavior all of this is tackling, clearly not good)
  - Send user back to task page, but with dialog open (very complicated, seems kind of confusing/undesirable?)

For actions like "Create New Bug" or "Edit Task", we have slightly better options:

  - Send user back to task page (very good?)
  - Send user to edit/create page (slightly better?)

However, we have no way to tell if a Workflow "makes sense" to complete in a standalone way. That is, we can't automatically determine which workflows are like "Edit Task" and which workflows are like "Merge Duplicates In".

Even within an action, this distinction is not straightforward. For example, "Create Task" can standalone from the Maniphest list view, but should not from a Workboard. "Edit Task" can standalone from the task detail page, but should not from an "Edit" pencil action on a list or a workboard.

Since the simpler behavior is easy, very good in all cases, often the best behavior, and never (I think?) confusing or misleading, I don't plan to puruse the "bring you back to the page, with the dialog open" behavior at any point. I'm theoretically open to discussion here if you REALLY want the dialogs to pop open magically but I think it's probably a lot of work.

Test Plan: As a logged out user, clicked "Create Task". Got a dropdown showing the options available to me if I log in. Clicked one, logged in, ended up in a reasonable place (the task list page where I'd started).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14806
2015-12-17 08:30:54 -08:00
epriestley
2868a69f65 Remove all setObjectURI() from ActionListViews
Summary:
Ref T10004. After D14804, we get this behavior by default and no longer need to set it explicitly.

(If some endpoint did eventually need to set it explicitly, it could just change what it passes to `setHref()`, but I believe we currently have no such endpoints and do not foresee ever having any.)

Test Plan:
  - As a logged out user, clicked various links in Differential, Maniphest, Files, etc., always got redirected to a sensible place after login.
  - Grepped for `setObjectURI()`, `getObjectURI()` (there are a few remaining callsites, but to a different method with the same name in Doorkeeper).

Reviewers: chad

Reviewed By: chad

Subscribers: hach-que

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14805
2015-12-17 08:30:22 -08:00
epriestley
e869e7df0b When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.

In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.

See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.

ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.

Finally, we have better tools for fixing the default behavior now than we did in 2013.

Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.

In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.

I'll remove the `setObjectURI()` mechanism in the next diff.

Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 08:30:03 -08:00
epriestley
a5d23c9f3e Allow custom fields to be ordered ascending or descending
Summary:
Fixes T6864. This creates a sort of busy menu but I think that's proably fine -- users are opting into activating these fields for search anyway.

In the future, we could refine this as, e.g.:

  - don't show these options in the dropdown;
  - do show them on some new "http prefilling" sort of page;
  - then you access them as an advanced user with `?order=secret-magic`.

But I'm not going to bother for now.

Test Plan: Ordered by an int field, then reversed the order.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6864

Differential Revision: https://secure.phabricator.com/D14800
2015-12-16 12:59:22 -08:00
Chad Little
36bfff3898 Give PhameBlog an EditEngine
Summary: This seems to work, but I couldn't figure out how to pass over a Caption for a text field.

Test Plan: New blog, Edit blog.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14770
2015-12-16 11:56:53 -08:00
epriestley
5e182180a9 Provide a "PHUIFormIconSetControl"
Summary:
Ref T9992. This is a step on the path to getting EditEngine working in Badges, Projects and Calendar.

This doesn't add a new `EditField` for icons yet, just standardizes the old stuff. New stuff is more general and I saved 150 lines of code.

I put the endpoint in Files because the similar "choose a profile picture" endpoint will definitely go there, and this endpoint might eventually feature, like, "draw your own icon~~" or something.

Test Plan:
  - Created events, projects and badges with custom icons.
  - Edited events, projects and badges, changing their icons.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9992

Differential Revision: https://secure.phabricator.com/D14799
2015-12-16 08:46:51 -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
6c4c93a091 Allow login to be disabled for authentication providers
Summary:
Fixes T9997. This was in the database since v0, I just never hooked up the UI since it wasn't previously meaningful.

However, it now makes sense to have a provider like Asana with login disabled and use it only for integrations.

Test Plan: Disabled login on a provider, verified it was no longer available for login/registration but still linkable.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9997

Differential Revision: https://secure.phabricator.com/D14794
2015-12-15 15:03:06 -08:00
epriestley
2d588715bc Always automatically generate Phame slugs
Summary:
Fixes T9995. I think letting users customize slugs is not a hugely compelling as a product feature, and this fixes the issue with slugs that have "/" characters in them and makes the move to EditEngine easier since I don't have to deal with the weird JS thing.

Instead, just generate slugs automatically. No more JS, no more separate field, things automatically update if you rename a blog, and now that URIs have IDs in them the old URI will still work after a rename.

Test Plan:
  - Applied migration.
  - Created new posts.
  - Edited existing posts.
  - Visited various posts.
  - Created a post with a bunch of "/" in the title, things still worked fine.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9995

Differential Revision: https://secure.phabricator.com/D14792
2015-12-15 14:18:56 -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
ab748e522a Fix an issue with the Spaces EditField not reading values properly
Summary: Fixes T9988. This logic got inverted by accident at some point.

Test Plan:
  - Edited a task, shifting spaces.
  - Created a task in default space.
  - Created a task in custom space.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9988

Differential Revision: https://secure.phabricator.com/D14787
2015-12-15 06:45:54 -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
29e2acd525 Have "limit=1" tokenizers replace tokens instead of disabling "Browse"
Summary:
Fixes T9984. When a tokenizer only allows one selection (like "Task Owner:" or "Land Onto Branch:"), keep the browse button active but have it //replace// values.

Also, have "Create Subtask" default to the system default status, so subtasks of closed tasks are not also closed.

Test Plan:
  - Browsed an empty limit=1 tokenizer.
  - Replaced a full limit=1 tokenizer.
  - Browsed an empty no-limit tokenizer.
  - Browsed more tokens into the no-limit tokenizer.
  - Typed some tokens normally.
  - Created a subtask of a closed task.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9984

Differential Revision: https://secure.phabricator.com/D14785
2015-12-14 15:29:42 -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
2805ba6f42 Add by-caller lookup to call logs, plus viewer calls
Summary:
Ref T9980. By default, show the viewer //their// calls.

Make it easy to find their own deprecated calls.

I don't like the word "My" but couldn't come up with anything better that didn't feel like a big loss of clarity.

The permissions on this log are also a little weird: non-admins can see everyone else's calls.

I think we should eventually lock that down, but plan to keep it this way for now:

First, a lot of your calls end up with no caller set right now, because we don't set the caller early enough in the process so a lot differnet types of errors can leave us with no user on the log. Fixing that isn't trivial, and users may reasonably want to access to these "no caller" logs to check for errors or debug stuff.

Second, none of it is really that sensitive?

Third, it's reasonable for users to want to look at bots?

I'd plan to maybe do this eventually:

  - Make the caller get populated more often after auth code is simplified.
  - Only let users look at their calls and maybe bot calls and anonymous calls.
  - Let admins look at everything.

But for now everyone can see everything.

Test Plan: {F1025867}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9980

Differential Revision: https://secure.phabricator.com/D14782
2015-12-14 15:25:49 -08:00
epriestley
6580bbdf39 Make it easy to find deprecated calls in the Conduit call log
Summary: Ref T9980. This makes it much easier to look for calls to deprecated methods.

Test Plan: {F1025851}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9980

Differential Revision: https://secure.phabricator.com/D14781
2015-12-14 15:25:28 -08:00
epriestley
0692115953 Remove all references to the Conduit ConnectionLog
Summary:
Ref T5955, T9980, T9982.

We currently store two types of Conduit logs: //connection// logs and //method// logs.

Originally, Conduit worked like web logins: you'd call `conduit.connect` and then get a session back. This approach still works, but new clients don't use it and it will probably stop working eventually after T5955 is further along.

There was no real reason for things to work like this and no other API in the world does, I think it was just slightly easier to implement back in 2011.

This table was used to group up related calls in a UI long ago, I think, but that got deleted at some point. In any case, it serves no purpose in modern Phabricator.

Test Plan: `grep`

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T5955, T9980, T9982

Differential Revision: https://secure.phabricator.com/D14780
2015-12-14 15:25:11 -08:00
epriestley
4a147dcbfb Move ConduitLogs to ApplicationSearch
Summary:
Ref T9980. Start making this UI more useful and powerful so we can give administrators a better toolset for reacting to API changes.

Fixes T9755. We were logging the caller, just not rendering it properly.

Test Plan: {F1025799}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9755, T9980

Differential Revision: https://secure.phabricator.com/D14779
2015-12-14 14:45:08 -08:00
epriestley
00bd824781 Remove the "deprecated calls in the last 30 days" setup warning
Summary: Ref T9980. I don't think this is actually useful, and plan to give users and administrators more powerful tools instead.

Test Plan: Loaded setup warnings.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9980

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

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

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

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14776
2015-12-14 11:54:13 -08:00
epriestley
10cdc55cf7 Give "owners.search" a "paths" attachment and a default "owners" value
Summary:
Ref T9964.

  - Add a "paths" attachment for fetching paths.
  - Always load owners. We will need this to do policy checks in the future, anyway, and this data is not large, is very useful, and is reasonable to load unconditionally.

Test Plan:
  - Queried packages via API.
  - Edited packages (paths, owners).
  - Created a package.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

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

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14774
2015-12-14 11:53:32 -08:00
epriestley
c0e20a11c1 Add a "projects" Search attachment for Conduit APIs
Summary: Ref T9964. Builds on D14772. Allows callers to request project PHIDs for objects.

Test Plan: {F1025468}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14773
2015-12-14 11:53:17 -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
8ec413b972 Clean up "ids" and "phids" handling in SearchEngines
Summary:
Ref T9964. I added several hacks to get these working. Clean them up and pull this into a proper extension.

The behavior in the web UI is:

  - they work in all applications; but
  - they only show up in the UI if a value is specified.

So if you visit `/view/?ids=1,2` you get the field, but normally it's not present. We could refine this later. I'm going to add documentation about how to prefill these forms regardless, which should make this discoverable by reading the documentation.

There's one teensey weensey hack: in the API, I push these fields to the top of the table. That one feels OK, since it's purely a convenience/display adjustment.

Test Plan: Queried by IDs, reviewed docs.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14769
2015-12-14 04:24:54 -08:00
epriestley
fdd2d802d2 Clean up "*.search" API method documentation pages
Summary:
Ref T9964. Building tables in Remarkup is kind of neat-ish but ends up feeling kind of hacky, and requires weird workarounds if any of the values have `|` in them.

Switch to normal elements instead.

Also move the magic "ids" and "phids" to be more like real fields. I'll clean this up fully in a diff or two, it's just a little tricky because Maniphest has an "ids" field.

Test Plan: {F1024294}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14768
2015-12-14 04:24:39 -08:00
epriestley
99ade500bc Flesh out Conduit parmeter types for maniphest.search
Summary: Ref T9964. I left a couple of these unsupported for now since they're weird in some way.

Test Plan: {F1024031}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14767
2015-12-14 04:24:01 -08:00
epriestley
663dce5029 Flesh out Conduit parameter types for Owners + CustomFields
Summary:
Ref T9964. Fill in more parameter types and descriptions.

(No date support yet since it's a bit more involved.)

Test Plan: {F1024022}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14766
2015-12-14 04:23:44 -08:00
epriestley
0282ce74ab Flesh out Conduit types for Paste search fields
Summary: Ref T9964. This fills in types and descriptions for ApplicationSearch fields in Paste.

Test Plan:
Got this nice table now:

{F1023999}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14765
2015-12-14 04:23:28 -08:00
epriestley
1b325a0a89 Modularize SearchEngine extensions
Summary:
Ref T9964. ApplicationSearch currently has a bunch of hard-coded `if ($object instanceof thing)` stuff.

Pull that out so it can live in extensions.

Test Plan:
 - Searched by spaces, subscribers, projects.

{F1023921}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14764
2015-12-14 04:23:02 -08:00
epriestley
05a798e3ac Add basic typechecking support to Conduit
Summary:
Ref T9964. I want to show users what we're expecting in "constraints", and let constraints like "authors=epriestley" work to make things easier.

I'm generally very happy with the "HTTPParameterType" stuff from EditEngine, so add a parallel set of "ConduitParameterType" classes. These are a little simpler than the HTTP ones, but have a little more validation logic.

Test Plan:
This is really just a proof of concept; some of these fields are now filled in:

{F1023845}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14763
2015-12-14 04:21:39 -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
f3b57990bf Add "maniphest.search" Conduit API endpoint
Summary: Ref T9964. This is a basic implementation of the new "maniphest.search" endpoint.

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

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14760
2015-12-14 04:08:57 -08:00
epriestley
9499987cfe Add "owners.search" Conduit API endpoint, with CustomField support
Summary:
Ref T9964. Adds a new-style "owners.search" endpoint, and an extension for customfields.

Puts enough indirection in place to give us nice, consistent "custom.key" user-facing keys instead of "std:custom:owners:na0shf9a8dfdsafl" junk.

Test Plan:
  - Searched Owners via API.
  - Searched by ID.
  - Ordered by custom fields.
  - Reviewed API docs.
  - Used normal search with ordering.
  - Viewed custom field values in search results.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9964

Differential Revision: https://secure.phabricator.com/D14758
2015-12-13 02:11:59 -08:00
Chad Little
32a7674c22 Add Drafts to PhameHome
Summary: Adds a list of your drafts. Fixes T9927y

Test Plan:
Load up home, see my drafts. Fake 0 drafts, see fallback message.

{F1023139}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D14756
2015-12-12 13:26:18 -08:00
epriestley
3d14b76f4d Fix double feed stories in Phame
Summary:
Ref T9360. Fixes the double-rendering of post bodies in feed stories.

Downside is that 'publish' (on its own) no longer shows a body, but that seems fine.

Test Plan:
  - Got some double bodies.
  - Applied patch.
  - No more double bodies.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9360

Differential Revision: https://secure.phabricator.com/D14748
2015-12-11 20:12:25 -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
dbdd702702 404 older-style Phame URIs properly
Summary: Ref T9968. Some of the crumb/route handling wasn't quite tight enough and could hit a fatal.

Test Plan: Hit previously-fataling URI, got a 404 instead.

Reviewers: chad

Reviewed By: chad

Subscribers: starruler

Maniphest Tasks: T9968

Differential Revision: https://secure.phabricator.com/D14747
2015-12-11 17:32:52 -08:00
Chad Little
efb6bb3dcf Add "Blogs" section to PhameHome
Summary: Ref T9927. Adds a "Blogs" section to PhameHome. Removes "New Post" Controller. Adds flipped layout for PHUITwoColumnView

Test Plan:
Test PhameHome, Ponder, New Post, etc. Mobile and Desktop states.

{F1022080}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: johnny-bit, Korvin

Maniphest Tasks: T9927

Differential Revision: https://secure.phabricator.com/D14744
2015-12-12 01:23:09 +00:00
epriestley
7b99735946 Throw CommandException instead of Exception after git fetch failure in repository updates
Summary: Fixes T9966. In this unusual, difficult-to-reach case, we throw `Exception` (which has no censoring) instead of `CommandException` (which has censoring). Throw `CommandException` instead.

Test Plan:
  - Hacked up a bunch of stuff in order to hit this: disabled origin validation, origin correction, and pointed repository at a bad domain.
  - Verified message is now censored correctly.

{F1022217}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9966

Differential Revision: https://secure.phabricator.com/D14745
2015-12-11 16:53:29 -08:00
epriestley
4ec6990ca7 Implement a rough initial version of ApplicationSearch-driven Conduit read endpoints
Summary:
Ref T9964. See that task for some context and discussion.

Ref T7715, which has the bigger picture here.

Basically, I want Conduit read endpoints to be full-power, ApplicationSearch-driven endpoints, so that applications can:

  - Write one EditEngine and get web + conduit writes for free.
  - Write one SearchEngine and get web + conduit reads for free.

I previously made some steps toward this, but this puts more of the structure in place.

Test Plan:
Viewed API console endpoint and read 20 pages of docs:

{F1021961}

Made various calls: with query keys, constraints, pagination, and limits.

Viewed new {nav Config > Modules} page.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T7715, T9964

Differential Revision: https://secure.phabricator.com/D14743
2015-12-11 15:27:06 -08:00
epriestley
ab7d3caa00 Allow Phurl short aliases to accept trailing / characters
Summary: Fixes T9963.

Test Plan: Visited `/u/x/` and `/u/x`.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9963

Differential Revision: https://secure.phabricator.com/D14742
2015-12-11 10:28:19 -08:00
epriestley
20d2652d03 Mark external -> external redirects in Phame to canonicalize URIs as "external"
Summary: Ref T9897. If you visit `/post/123/spoderman/` it will try to redirect you to `/post/123/spiderman/`, but currently only internal views work because these redirects aren't marked as safe/external.

Test Plan: Visited a misspelled/out-of-date URI on an external blog view, got a good redirect.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9897

Differential Revision: https://secure.phabricator.com/D14741
2015-12-11 08:35:37 -08:00
epriestley
9e78f33847 Also update the resource map
This is not my morning.

Auditors: chad
2015-12-11 08:23:39 -08:00
epriestley
dc79d9ea84 Put back "PhabricatorResourceSite"
Auditors: chad
2015-12-11 08:22:16 -08:00
epriestley
8a906b0e18 Remove skins from Phame
Summary:
Ref T9897. Purge a bunch of stuff:

  - Remove skins.
  - Remove all custom sites for skin resources.
  - Remove "framed", "notlive", "preview", separate "live" controllers (see below).
  - Merge "publish" and "unpublish" controllers into one.

New behavior:

  - Blogs and posts have three views:
    - "View": Internal view URI, which is a normal detail page.
    - "Internal Live": Internal view URI which is a little prettier.
    - "External Live": External view URI for an external domain.

Right now, the differences are pretty minor (basically, different crumbs/chrome). This mostly gives us room to put some milder flavor of skins back later (photography or more "presentation" elements, for example).

This removes 9 million lines of code so I probably missed a couple of things, but I think it's like 95% of the way there.

Test Plan:
Here are some examples of what the "view", "internal" and "external" views look like for blogs (posts are similar):

"View": Unchanged

{F1021634}

"Internal": No chrome or footer. Still write actions (edit, post commments). Has crumbs to get back into Phame.

{F1021635}

"External": No chrome or footer. No write actions. No Phabricator crumbs. No policy/status information.

{F1021638}

I figure we'll probably tweak these a bit to figure out what makes sense (like: maybe no actions on "internal, live"? and "external, live" probably needs a way to set a root "Company >" crumb?) but that they're reasonable-ish as a first cut?

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9897

Differential Revision: https://secure.phabricator.com/D14740
2015-12-11 08:14:12 -08:00
epriestley
c62e0a10f6 Clarify that ApplicationEditor supports editing itself
Summary: edit forms in yo' edit forms

Test Plan: ~(o.o)~

Reviewers: chad

Reviewed By: chad

Differential Revision: https://secure.phabricator.com/D14739
2015-12-10 19:19:20 -08:00
epriestley
954cd4b1b6 When arc has sent target branch data up after D14736, use it in the UI and "Land Revision"
Summary:
Ref T9952. Ref T3462. After D14736, if we have information about the target/"onto" branch, use it in the UI:

  - Show "feature (branched from master)" instead of "feature".
  - Default "Land Revision" to hit the correct branch.

Test Plan:
  - Branched from `test` with branch tracking.
  - Diffed.
  - Saw "feature (branched from test)" in UI.
  - Saw "test" fill as default in "Land Revision", despite the repository having a different default branch.

{F1020587}

{F1020588}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T3462, T9952

Differential Revision: https://secure.phabricator.com/D14737
2015-12-10 15:24:38 -08:00
epriestley
f60548d081 Default "Land Revision" dialog to land into the default branch for the repository
Summary:
Ref T9952. Default the branch target in the dialog to be whatever branch is the default branch for the repository.

This will be correct for repositories like ours (which land everything into `master`) and correct most of the time for repositories which have some other "primary" branch (maybe `development`).

It won't be great if there are multiple open lines of development in a repository (for example, some changes go to `newdesignpro` and some changes go to `legacy-1.2`). I'll do work in T3462 next to improve those cases so we can pick a better default.

Test Plan:
  - Saw dialog default to "master".
  - Changed repo default branch, saw it default to "notmaster" instead.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9952

Differential Revision: https://secure.phabricator.com/D14734
2015-12-10 14:21:59 -08:00
epriestley
856bdaf77e Add an "Onto Branch" selector control to "Land Revision" dialog
Summary:
Ref T9952. This adds a typeahead so you can pick a branch to target.

It does not choose a default branch, the user must pick a branch explicitly.

Test Plan:
  - Landed rGITTESTd587fada48fc to `master` (by typing "master").
  - Landed rGITTEST86c339b2ef01 to `notmaster` (by typing "notmaster").

{F1020531}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9952

Differential Revision: https://secure.phabricator.com/D14733
2015-12-10 14:21:38 -08:00