1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-04 20:52:43 +01:00
Commit graph

5161 commits

Author SHA1 Message Date
epriestley
fdbd377625 Replace old login validation controller with new one
Summary: Ref T1536. We can safely replace the old login validation controller with this new one, and reduce code dplication while we're at it.

Test Plan: Logged in with LDAP, logged in with OAuth, logged in with username/password, did a password reset.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6178
2013-06-16 10:18:45 -07:00
epriestley
068263a6df Move LDAP to new registration flow
Summary:
Ref T1536. LDAP is very likely the worst thing in existence.

This has some rough edges (error handling isn't perfect) but is already better than the current LDAP experience! durrr

Test Plan: Registered and logged in using LDAP.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, mbishopim3

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6177
2013-06-16 10:18:34 -07:00
epriestley
70b30ab527 Add Google support to new registration flow
Summary: Ref T1536. Adds Google support.

Test Plan: Registered and logged in with Google.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6167
2013-06-16 10:18:04 -07:00
epriestley
2bc44a130c Add GitHub auth to new flows
Summary: Ref T1536. Support for GitHub on new flows.

Test Plan: Registered and logged in with GitHub.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6166
2013-06-16 10:17:29 -07:00
epriestley
a12a6d5c7d Add Disqus OAuth to new flows
Summary: Ref T1536. Adds Disqus as a Provider.

Test Plan: Registered and logged in with Disqus.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6165
2013-06-16 10:16:14 -07:00
epriestley
1329b7b51e Add password authentication and registration to new registration
Summary:
Ref T1536. Ref T1930. Code is not reachable.

This provides password authentication and registration on the new provider/adapter framework.

I sort of cheated a little bit and don't really route any password logic through the adapter (instead, this provider uses an empty adapter and just sets the type/domain on it). I think the right way to do this //conceptually// is to treat username/passwords as an external black box which the adapter communicates with. However, this creates a lot of practical implementation and UX problems:

  - There would basically be two steps -- in the first one, you interact with the "password black box", which behaves like an OAuth provider. This produces some ExternalAccount associated with the username/password pair, then we go into normal registration.
  - In normal registration, we'd proceed normally.

This means:

  - The registration flow would be split into two parts, one where you select a username/password (interacting with the black box) and one where you actually register (interacting with the generic flow). This is unusual and probably confusing for users.
  - We would need to do a lot of re-hashing of passwords, since passwords currently depend on the username and user PHID, which won't exist yet during registration or the "black box" phase. This is a big mess I don't want to deal with.
  - We hit a weird condition where two users complete step 1 with the same username but don't complete step 2 yet. The box knows about two different copies of the username, with two different passwords. When we arrive at step 2 the second time we have a lot of bad choices about how to reoslve it, most of which create security problems. The most stragihtforward and "pure" way to resolve the issues is to put password-auth usernames in a separate space, but this would be incredibly confusuing to users (your login name might not be the same as your username, which is bizarre).
  - If we change this, we need to update all the other password-related code, which I don't want to bother with (at least for now).

Instead, let registration know about a "default" registration controller (which is always password, if enabled), and let it require a password. This gives us a much simpler (albeit slightly less pure) implementation:

  - All the fields are on one form.
  - Password adapter is just a shell.
  - Password provider does the heavy lifting.

We might make this more pure at some point, but I'm generally pretty satisfied with this.

This doesn't implement the brute-force CAPTCHA protection, that will be coming soon.

Test Plan: Registered with password only and logged in with a password. Hit various error conditions.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T1536, T1930

Differential Revision: https://secure.phabricator.com/D6164
2013-06-16 10:15:49 -07:00
epriestley
104d3221d9 Implement new auth login flow and login validation controller
Summary:
Ref T1536. None of this code is reachable.

Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly).

Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 10:15:33 -07:00
epriestley
c108ada7e4 Provide start screen and full registration flow on the new auth stuff
Summary:
Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()).

This adds:

  - A provider-driven "start" screen (this has the list of ways you can login/register).
  - Registration actually works.
  - Facebook OAuth works.

@chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have:

  - Password
  - LDAP
  - Facebook
  - GitHub
  - Phabricator
  - Disqus
  - Google

We plan to add:

  - Asana
  - An arbitrary number of additional instances of Phabricator

Users want to add:

  - OpenID
  - Custom providers

And I'd like to have these at some point:

  - Stripe
  - WePay
  - Amazon
  - Bitbucket

So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case.

Test Plan: Registered a new acount with Facebook.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 10:15:16 -07:00
epriestley
7efee51c38 Put some glue in between PhabricatorAuthProvider and the OAuth adapters
Summary: Ref T1536. None of this code is reachable. Glues AuthProvider to OAuthAdapter.

Test Plan: Code is unreachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6160
2013-06-16 10:14:19 -07:00
epriestley
c05ee9ed68 Generalize login flows for new registration
Summary:
Ref T1536. None of this code is reachable.

`PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow.

`PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider.

Test Plan: Static only, code isn't meaningfully reachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 10:14:07 -07:00
epriestley
db1cf41ec4 New Registration Workflow
Summary:
Currently, registration and authentication are pretty messy. Two concrete problems:

  - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad.
  - We can't practically implement OpenID because we can't reissue the authentication request.

Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess.

Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps:

  - User authenticates with remote service.
  - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`.
  - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc.

This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this:

  $profile = $event->getValue('profile')

  $username = $profile->getDefaultUsername();
  $is_employee = is_this_a_facebook_employee($username);
  if (!$is_employee) {
    throw new Exception("You are not employed at Facebook.");
  }

  $fbid = get_fbid_for_facebook_username($username);
  $profile->setDefaultEmail($fbid);

  $profile->setCanEditUsername(false);
  $profile->setCanEditEmail(false);
  $profile->setCanEditRealName(false);
  $profile->setShouldVerifyEmail(true);

Seem reasonable?

Test Plan: N/A yet, probably fatals.

Reviewers: vrana, btrahan, codeblock, chad

Reviewed By: btrahan

CC: aran, asherkin, nh, wez

Maniphest Tasks: T1536, T2394

Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
epriestley
8744cdb699 Migrate PhabricatorUserLDAPInfo to PhabricatorExternalAccount
Summary: Ref T1536. This is similar to D6172 but much simpler: we don't need to retain external interfaces here and can do a straight migration.

Test Plan: TBA

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6173
2013-06-16 09:55:55 -07:00
Bob Trahan
9327e51446 Conpherence - fix no messages button
Summary: make it work with z-index and make it grey.

Test Plan:
clicked the grey button and it worked! Safari and Chrome

clicked around and observed loading mask functioning correctly

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3396

Differential Revision: https://secure.phabricator.com/D6207
2013-06-14 17:00:09 -07:00
epriestley
8111dc74bf Migrate the OAuthInfo table to the ExternalAccount table
Summary: Ref T1536. Migrates the OAuthInfo table to ExternalAccount, and makes `PhabricatorUserOAuthInfo` a wrapper for an ExternalAccount.

Test Plan: Logged in with OAuth, registered with OAuth, linked/unlinked OAuth accounts, checked OAuth status screen, deleted an account with related OAuth.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6172
2013-06-14 07:04:41 -07:00
epriestley
bce4b7addf Internalize storage access for PhabricatorUserOAuthInfo
Summary:
Ref T1536. Move all access to the underlying storage to inside the class. My plan is:

  - Migrate the table to ExternalAccount.
  - Nuke the table.
  - Make this class read from and write to ExternalAccount instead.

We can't get rid of OAuthInfo completely because Facebook still depends on it for now, via registration hooks.

Test Plan: Logged in and registered with OAuth.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6171
2013-06-14 07:00:29 -07:00
epriestley
3005811b9e Remove OAuth token/expiry interfaces
Summary:
Ref T1536. Currently, we store OAuth tokens along with their expiry times and status. However, all we use this for is refreshing profile pictures and showing a silly (and probably somewhat confusing) interface about token status.

I want to move this storage over to `PhabricatorExternalAccount` to make the cutover easier. Drop it for now, including all the profile image stuff (I plan to rebuild that in a more sensible way anyway).

Test Plan: Viewed screen; linked/unlinked accounts.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6170
2013-06-14 06:59:23 -07:00
epriestley
8886416e30 Expand the "PhabricatorExternalAccount" table for new registration
Summary:
Ref T1536. This is the schema code for `PhabricatorExternalAccount` which was previously in D4647. I'm splitting it out so I can put it earlier in the sequence and because it's simple and standalone.

Expands `PhabricatorExternalAccount` to have everything we need for the rest of registration.

Test Plan: Implemented the remainder of new registration on top of this.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6169
2013-06-14 06:55:18 -07:00
epriestley
efbd3ecc48 Fix the type of some values passed to MySQL
Summary: Ref T3377. MySQL ignores indexes if we hand it mismatched datatypes. This seems colossally dumb, but give it what it expects.

Test Plan: wat

Reviewers: wez, btrahan

Reviewed By: wez

CC: aran

Maniphest Tasks: T3377

Differential Revision: https://secure.phabricator.com/D6201
2013-06-13 18:01:40 -07:00
Chad Little
02b59e685f PHUIButtonView class
Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class.

Test Plan: UIExamples

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6192
2013-06-12 18:23:35 -07:00
Chad Little
a66e6c2126 Add Login icons to PHUIIconView.
Summary: Prepping to use.

Test Plan: UIExamples

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6191
2013-06-12 15:05:16 -07:00
Chad Little
554a15c902 Fix hovers on mobile menus.
Summary: Restrict the menu hovers to desktop

Test Plan: test desktop and mobile

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6190
2013-06-12 10:30:15 -07:00
Chad Little
341ee8b9b2 Add authentication icon
Summary: its a lock - Fixes T3341

Test Plan: surprise!

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3341

Differential Revision: https://secure.phabricator.com/D6187
2013-06-12 07:40:04 -07:00
epriestley
ce01d6fc2b Add a setup issue to warn about an unconfigured upload limit
Summary:
Ref T3354. There's no way for us to test most of the config options which actually affect this limit, so the Phabricator config is basically a canary value to indicate "the administrator hasn't configured anything yet".

Raise a setup issue if it isn't set. There's a trail to get here from Files, but we've de-emphasized the old-school upload form so it's hard to unearth.

Emphasize the warning that you need to read the documentation and configure like 30 other things to make this work.

Test Plan: Cleared my config, verified I got the issue, read it, set my config, issue went away.

Reviewers: jamesr, chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T3354

Differential Revision: https://secure.phabricator.com/D6185
2013-06-12 05:49:41 -07:00
Chad Little
4672705c22 Tweak audit status colors.
Summary: Fixes T3242. Changes the red and orange objects to match the transactions. Also adds a highlight color to 'cards'.

Test Plan: Review my audits in my sandbox

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3242

Differential Revision: https://secure.phabricator.com/D6184
2013-06-11 20:53:55 -07:00
Chad Little
ff89843034 Fix white + icon hover / apps create
Summary: Decided to just remove the hover grey to white, seems fine with the new white icons.

Test Plan: use homepage + icons

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6181
2013-06-11 19:10:12 -07:00
Bob Trahan
4c9c6fcda8 Conpherence - fix some ajax bugs
Summary: the people widget was returning a comma-delimited list of HTML nodes so kill that noise with some hsprintf action. We also weren't consistently updating the latest transaction id so simplify those codepaths (widgets vs pontificate) a bit. Fixes T3336.

Test Plan: left some messages, added some participants. noted that the people widget looked good and only the pertinent transactions were pulled down on updates.

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3336

Differential Revision: https://secure.phabricator.com/D6180
2013-06-11 15:07:53 -10:00
Chad Little
6825e6ca77 Soften shadow on white icons
Summary: The shadow on the white icons was too harsh for their size, looked bad on timelines.

Test Plan: Check timeline example, phuilist example.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6176
2013-06-11 11:26:33 -07:00
Chad Little
8e6bda51f2 Login icons
Summary: Took a stab at some login icons for buttons.

Test Plan: photoshop

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6174
2013-06-11 10:22:09 -07:00
Bob Trahan
0779682694 Diffusion - fix a bug from T2784 (D5894 to be more specific)
Summary: Fixes T3314. Now you can view the tags for a specific commit.

Test Plan: visited http://phabricator.dev/diffusion/P/tags/master/;9b5f0aa03a5ffc93d5f4fce83fef5efb435097cc and saw a nice, 'no tags' paged. Then I tagged the commit, did a git pull, and reloaded. On reload, the page showed a tag.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3314

Differential Revision: https://secure.phabricator.com/D6168
2013-06-10 16:15:06 -07:00
Chad Little
fed0a2a496 Fix search and core icons in top nav
Summary: Fixes T3330

Test Plan: Test desktop and mobile menus in chrome and ios.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3330

Differential Revision: https://secure.phabricator.com/D6157
2013-06-09 09:11:32 -07:00
Evan Priestley
ee82f6f8bd Merge pull request #334 from Naatan/master
Fixed maniphest transaction types were not translatable
2013-06-07 18:22:54 -07:00
Nathan
b3d1acfebd Fixed maniphest transaction types were not translatable 2013-06-08 00:33:38 +00:00
epriestley
059183f6b5 Allow configuration to have custom UI types
Summary:
Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields.

I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything.

Test Plan:
UI now renders via custom code, although that code does nothing (produces an unadorned text field):

{F45693}

Reviewers: chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 12:36:18 -07:00
epriestley
77c03a8a42 Add "Title" and "Blurb" to new profile editor
Summary:
Ref T1703.

  - Adds "Title".
  - Adds "Blurb".
  - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch.

Test Plan:
{F45689}

{F45690}

Edited the fields, too.

Reviewers: chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 10:22:45 -07:00
epriestley
6ffbee115b Add ApplicationTransactions/CustomField based user profile editor
Summary:
Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField.

{F45617}

My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings":

  - Sex
  - Language
  - Timezone

These will be "profile":

  - Real Name
  - Title
  - Blurb
  - Profile Image (but I'm going to put this on a separate UI)
  - Other custom fields

Test Plan: Edited my realname using the new interface.

Reviewers: chad, seporaitis

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 09:55:55 -07:00
Chad Little
7598330e24 Remove subscribe icons
Summary: Used more logical icons for subscribe, auto, and delete instead of the mail icons. Fixes T3329

Test Plan: Tested subscribing and unsubscribing in Maniphest.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T3329

Differential Revision: https://secure.phabricator.com/D6151
2013-06-06 15:06:08 -07:00
epriestley
524c2acb3d Flesh out ApplicationTransactions/CustomField integration
Summary:
None of this code is reachable yet. See discussion in D6147. Ref T1703.

Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation.

Test Plan: Code not reachable.

Reviewers: chad, seporaitis

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 14:53:07 -07:00
epriestley
b7c584137f Begin generalizing custom fields
Summary:
Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit.

For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though:

  - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch.
  - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed.
  - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field.

For ApplicationSearch, I've adopted and generalized D5278.

For ApplicationTransactions, I haven't made any specific affordances yet.

For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this:

  - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled.
  - We load every avialable field to populate this list. New fields will appear at the bottom.
  - There are two downsides to this approach:
    - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream.
    - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability.
    - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to.
    - We can fix both of these problems with a straightforward configuration migration if we want to bother.
  - There are numerous upsides to this approach:
    - We can delete a bunch of code and replace it with simple configuration.
    - In general, we don't need the "selector" classes anymore.
    - Users can enable available-but-disabled fields with one click.
    - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff.
    - Generally, it's super easy for users to understand.

This doesn't actually do anything yet and will probably see some adjustments before anything starts running it.

Test Plan: Static checks only, this code isn't reachable yet.

Reviewers: chad, seporaitis

Reviewed By: chad

CC: aran

Maniphest Tasks: T1703

Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 14:52:40 -07:00
Chad Little
90b45b3a0a PHUIDocument view for mobile devices.
Summary: Adds collapsing of the sidebar, also allows you to say where it goes on mobile (above or below content). ToC for example, above. General Navbar, below. Up to you.

Test Plan: Review UIExamples and Diviner.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6150
2013-06-06 12:47:40 -07:00
Chad Little
d3aed20752 PHUIList changes for responsive design
Summary: Fixes some issues with lists and tablet/mobile layouts.

Test Plan: shrink my screen

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6148
2013-06-06 11:59:14 -07:00
epriestley
9e591f488b Fix Diviner issue when publishing new atoms
Summary: We need to make sure the symbol is always saved before the atom. I mucked this up recently and didn't catch it locally since I'd already generated the atoms.

Test Plan: Ran `bin/diviner generate` after truncating all diviner tables.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6146
2013-06-06 09:09:08 -07:00
epriestley
1433a035c6 Make some incremental improvements in Diviner
Summary: Gets TOC populated for articles, at least, and fixes a few other things.

Test Plan: {F45474}

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6144
2013-06-06 08:36:51 -07:00
Chad Little
76c8705a27 Add home icon to examples
Summary: home icon on examples

Test Plan: O.O

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6145
2013-06-05 20:50:03 -07:00
Chad Little
148ab2b772 Lots of Icons
Summary: Tweaks the dark, grey, and white icons to match the action-icons. Also added a home icon for navigation.

Test Plan: looked at list navs, action menus.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6142
2013-06-05 18:59:23 -07:00
epriestley
7615e59cf9 Default application search to the topmost filter
Summary: Allow users to set a default by dragging it to the top. When they land on a page without a saved query, choose their default.

Test Plan: Hit `/paste/`, got my default results, etc.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6140
2013-06-05 18:58:50 -07:00
epriestley
5f98c5f386 Simplify drag-and-drop list implementations
Summary:
  - Use the same styles for shared operations (`drag-ghost`, `drag-dragging`).
  - Move shared code into the base class.

Test Plan: Dragged around tasks and named queries.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6141
2013-06-05 17:36:33 -07:00
Chad Little
d0bb4e1c93 Restrict icon hover on lists to sidebar.
Summary: Needed to be more restrictive

Test Plan: Test maniphest and list examples.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D6139
2013-06-05 16:29:32 -07:00
epriestley
0f82990798 Allow named queries to be reordered by dragging
Summary:
Also you have to drop them. So drag, and then drop.

This needs some cleanup and reconciliation/generalization with the Maniphest implementation. In particular, you can't drag things to the very top right now, and they should share more CSS and more behaviors.

Test Plan:
Look I alphabetized them:

{F45286}

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6136
2013-06-05 16:22:27 -07:00
epriestley
f26be0e2d4 Remove all the container node stuff from AphrontTagView
Summary: See discussion in D6131, D6130. This turned into 35 layers of mess so throw it away and just tweak the JS to be more flexible.

Test Plan:
  - Clicked "Show More Applications".
  - Clicked "Show Fewer Applications".
  - Edited tasks using popup dialog.
  - Tried to drag tasks using pencil icon (correctly no longer works).
  - Changed threads in Conpherence.
  - Not sure how to actually hit the Conpherence "Load ... Threads" thing since
    it seems to auto-load? But that works, at least, and the code doesn't really
    care what you hit.
  - Added a conpherence participant.
  - Added a new calendar item.
  - Poked around other menus.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6133
2013-06-05 16:21:55 -07:00
epriestley
94c29007b6 Generalize rules for "workflow" sigil
Summary:
See discussion in D6130. Basically, all of these should activate workflow:

  <a data-sigil="workflow" href="...">...</a>

  <div data-sigil="workflow">
    <a href="...">...</a>
  </div>

  <form data-sigil="workflow" action="...">...</form>

  <div data-sigil="workflow">
    <form action="...">...</form>
  </div>

The only case where we don't want to activate workflow is this one:

  <form data-sigil="workflow">
    <a href="...">...</a>
  </form>

Here, the form should workflow but the `<a />` should not.

These cases aren't really covered:

  // Undefined no matter where "workflow" is because it's nonsense.
  <a><a>...</a></a>

  // As above except like a million times more dumb.
  <form><form>...</form></form>

  // This one is ambiguous. The <a /> will currently workflow. We don't do
  // this anywhere and probably never will. If we want a different rule we
  // can cross that bridge when we come to it.
  <div data-sigil="workflow">
    <form action="...">
      <a href="...">...</a>
    </form>
  </div>

Test Plan: Clicked/submitted some things with workflow.

Reviewers: chad

Reviewed By: chad

CC: aran

Differential Revision: https://secure.phabricator.com/D6131
2013-06-05 16:21:21 -07:00