Summary: Another pass at consolidating colors
Test Plan: Test various pages and UI elements
Reviewers: epriestley
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6905
Summary: Starting to roll out the standard colors and spacing to action list, headers, and property views. Also softened the grey borders a hex.
Test Plan: Review Maniphest and Differential on desktop and mobile. Felt the flow of standardization waft over me.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6869
Summary: More grey tweaks, breaking these up so I can test and tweak each as needed.
Test Plan: Review pages.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6866
Summary: This adds standard 'blues' and start integration of standard colors for text, backgrounds, and borders.
Test Plan: sb
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6857
Summary: Split some of these up for safe regexes.
Test Plan: reload celerity
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6858
Summary:
This attempts some consistency in form layouts. Notably, they all now contain headers and are 16px off the sides and tops of pages. Also updated dialogs to the same look and feel. I think I got 98% of forms with this pass, but it's likely I missed some buried somewhere.
TODO: will take another pass as consolidating these colors and new gradients in another diff.
Test Plan: Played in my sandbox all week. Please play with it too and let me know how they feel.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: Korvin, aran
Differential Revision: https://secure.phabricator.com/D6806
Summary:
Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field).
ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later.
Test Plan: {F54304}
Reviewers: btrahan
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T3721
Differential Revision: https://secure.phabricator.com/D6758
Summary: Tightens up the CSS to display more items (4 wide on 15") and fixes some mobile CSS issues with appseach. Fixes T3614
Test Plan: Tested Pholio, Macros, mobile layouts
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3614
Differential Revision: https://secure.phabricator.com/D6694
Summary:
Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569.
Provide a link you can click to see the full message.
This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them.
Test Plan: {F51261} {F51262}
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T3557
Differential Revision: https://secure.phabricator.com/D6546
Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this.
Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, Korvin, chad
Maniphest Tasks: T3553
Differential Revision: https://secure.phabricator.com/D6488
Summary: Fixes T3473, mostly reverts previous changes to clean up required field text, will have to redesign that in general for responsiveness.
Test Plan: use logout form, use new conpherence form
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3473
Differential Revision: https://secure.phabricator.com/D6371
Summary: green, like celery
Test Plan: drag and drop and image, same green colors.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6368
Summary:
Tried out `PhabricatorObjectItemView` for Differential. It looks smexy and smooth.
Refs T2014
- Title and Date as Maniphest
- Author in the handle icon
- Bar color reflects revision status (Needs Review, Accepted, Abandoned etc.) @chad looking for non-blue is faster than keeping watch for everything that's not "Closed" in old table form
- Some status information are in footer icons; currently only stale/old status display as well as saved drafts, maybe more in future; these come into my mind:
- No reviewer warning
- Push Blocking Priority (T2730)
- Trivial, fast review guaranteed
- Sketch / Just looking for advice/help
- Arcanist Project (T2614)
- Denote "Public Send-in" (T1476)
{F37662}
{F37663}
{F37664}
{F37665}
Some flaws:
- Date and reviewers on every entry the same?
- No respect for Differential fields (for some reason, every entry appeared the same, so broke it to parts)
- Plenty of (potential) increase in height - advise reducing paging length from 100 to 50 - or just ignore me
Suggestions for the future:
- Expand the meta information regarding revisions; e.g. the various status displays above
- Uh... T2543, T1279, T793, T731 and what else I want for Differential, because they are awesome!
- T793 should be in particular easy appearance-wise, just copy-paste from Maniphest
Test Plan: By looking at it, of course. Verified there are no errors or crashed
Reviewers: epriestley, chad, btrahan, liguobig
Reviewed By: chad
CC: aran, Korvin, edward, nh
Maniphest Tasks: T2014
Differential Revision: https://secure.phabricator.com/D5451
Conflicts:
src/__celerity_resource_map__.php
Summary:
Ref T603.
- Primarily, this gets rid of a `DifferentialRevisionListData` callsite.
- Also modernize and clean up some UI stuff.
Test Plan:
{F48260}
{F48261}
Reviewers: btrahan, chad
Reviewed By: chad
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D6334
Summary: Removes extra padding on rendering notifications in jx-notification.
Test Plan: test a notification
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6259
Summary: Changes it to a dialog view, tweaks some layout bugs on full width forms.
Test Plan: Tested loging in and resetting my password. Chrome + Mobile
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin, nrp
Differential Revision: https://secure.phabricator.com/D6257
Summary:
Ref T1536.
- When users try to add a one-of provider which already exists, give them a better error (a dialog explaining what's up with reasonable choices).
- Disable such providers and label why they're disabled on the "new provider" screen.
Test Plan:
{F47012}
{F47013}
Reviewers: chad, btrahan
Reviewed By: chad
CC: aran
Maniphest Tasks: T1536
Differential Revision: https://secure.phabricator.com/D6256
Summary: Added in color variables in most used places. Tweaked green to be a bit more serious.
Test Plan: Tested Tags, Error View, Timeline, Object Views, and Color Palette.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6244
Summary: This adds an 83% Light set of colors for highlights, warnings, etc.
Test Plan: Tested Notifications, Error View, and Color Palette page. Test is out, not quite sure on notifications.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6239
Summary: Touches a lot of little spacing things here and there, stuck to 4px grid when possible, checked mobile views.
Test Plan: Mobile, Logging In, Multiple Providers.
Reviewers: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6220
Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow.
Test Plan: {F46333}
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1536
Differential Revision: https://secure.phabricator.com/D6200
Summary: Ref T1536. Adds an initial "choose a provider type" screen for adding a new provider. This doesn't go anywhere yet.
Test Plan: {F46316}
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, chad
Maniphest Tasks: T1536
Differential Revision: https://secure.phabricator.com/D6199
Summary: Ref T1536. Error state is a bit gross but we need to sort that out in general.
Test Plan:
{F46549}
{F46550}
Reviewers: chad, btrahan
Reviewed By: chad
CC: aran
Maniphest Tasks: T1536
Differential Revision: https://secure.phabricator.com/D6208
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
Summary:
Ref T2625.
- Build the mobile menu from the delegating controller.
- Make the result header look a little better (still a bit funky).
Test Plan:
{F44774}
{F44775}
Reviewers: btrahan, chad
Reviewed By: chad
CC: aran
Maniphest Tasks: T2625
Differential Revision: https://secure.phabricator.com/D6090
Summary: We were clipping this to 300px, which is arbitrary to iPhone.
Test Plan: test on Nexus, iPhone
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D6089
Summary:
Fixes T3279. For ApplicationSearch (and in some other cases) I'd like users to be able to provide an optional date. This isn't currently possible.
Add a checkbox which disables or enables the input.
Test Plan: Used UIExample to enter dates. Used Calendar to enter dates.
Reviewers: chad, btrahan
Reviewed By: chad
CC: aran
Maniphest Tasks: T3279
Differential Revision: https://secure.phabricator.com/D6082
Summary:
Fixes T3252. Other enhancements:
- Header in widget panel was 2px too short.
- Typeahead in add people only allowed one person
- Typeahead in add people was cutoff by overflow:hidden
- X in remove has been changed to unicode (multiply)
- Add people dialog form fields are full width
- Some other CSS tweaks.
Test Plan: Add, Remove people.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3252
Differential Revision: https://secure.phabricator.com/D6076
Summary:
Ref T2625. @chad, you might have some feedback here. The behaviors this implements are:
- When the user selects "Advanced Search", we show the full search UI and no results (for performance and clarity).
- When the user submits a search which //is not// a named search, we show the full search UI and the "Save Custom Query..." button.
- When the user submits a search which //is// a named search, we show "Results for search X." with an "Edit Query..." button. The button expands the search form.
- When the user selects a builtin query (like "All Pastes"), we don't show any search UI, but I'm probably going to make this behave more like named searches.
Test Plan:
{F44346}
{F44347}
Reviewers: chad, btrahan, blc
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2625
Differential Revision: https://secure.phabricator.com/D6063
Summary:
Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses.
The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this:
if ($request->isFormPost()) {
$form->readFromRequest($request); // (1)
if ($form->isComplete()) { // (2)
$response = $form->writeToResponse($response); // (3)
// Process result here. // (4)
}
} else {
$form->readFromObject($object); // (5)
}
The key parts are:
# This reads the form state from the request, including reading all the inactive pages.
# This tests if all pages are valid and the user just clicked "Done" on the last page.
# This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms).
# Here, we would save the object or apply the transactions.
# When the user views the form for the first time, we preload all the values from some object (which might just be empty).
Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness.
There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy.
I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to.
Test Plan: Paged forward and backward through the form.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2232
Differential Revision: https://secure.phabricator.com/D6003
Summary: This adds the ability to have a multi-column full height container that is responsive based on PHUIBox's shadow box.
Test Plan: Tested new examples in UIExamples and Workboards.
Reviewers: epriestley, edward, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5996
Summary: Debating removing the textures from the sidenavs, sending this around for comments.
Test Plan: Test homepage and various sidenavs, mobile layouts.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5948
Summary:
- Makes text larger (12px, 13px)
- Makes global search match notifications container look
- Makes the jx typeahead feel a bit more attached, and similar to tokens and other inputs.
Test Plan: Tested global search and jx typeahead in maniphest.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5939
Summary: This piggybacks onto device-phone's CSS rules to enable a full width form (for smaller spaces).
Test Plan: Convert New Message dialog to fullWidth.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5924
Summary: Converts to ObjectList for display, pht's most everything, some responsive design when possible. Tables still are tables, but scroll on touch.
Test Plan: Use iOS simulator on Diffusion, Chrome
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5847
Summary:
-Tokenizer field now grows.
-Tokenizer input text standard #333
Test Plan: use tokenizer
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3158
Differential Revision: https://secure.phabricator.com/D5886
Summary:
This creates a common form look and feel across the site. I spent a bit of time working out a number of kinks in our various renderings. Some things:
- Font Styles are correctly applied for form elements now.
- Everything lines up!
- Selects are larger, easier to read, interact.
- Inputs have been squared.
- Consistant CSS applied glow (try it!)
- Improved Mobile Responsiveness
- CSS applied to all form elements, not just Aphront
- Many other minor tweaks.
I tried to hit as many high profile forms as possible in an effort to increase consistency. Stopped for now and will follow up after this lands. I know Evan is not a super fan of the glow, but after working with it for a week, it's way cleaner and responsive than the OS controls. Give it a try.
Test Plan: Tested many applications, forms, mobile and tablet.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5860
Summary:
Highlights the current day :)
I am not great in choosing colors. @chad can suggest some improvements :)
Test Plan: {F41738}
Reviewers: epriestley
Reviewed By: epriestley
CC: chad, aran, Korvin, AnhNhan
Maniphest Tasks: T2627
Differential Revision: https://secure.phabricator.com/D5790
Summary: For some evil design purpose.
Test Plan: Focused, blurred tokenizers.
Reviewers: chad
Reviewed By: chad
CC: aran
Differential Revision: https://secure.phabricator.com/D5780
Summary: It looks bad before the background image loads.
Test Plan: Looked at table header.
Reviewers: chad
Reviewed By: chad
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D5777
Summary: This is mostly minor, but visually it makes the wiki feel more 'page like' and better separates the actual content from other data displayed.
Test Plan: Tested Chrome, iPhone, and iPad.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin, AnhNhan
Maniphest Tasks: T2686
Differential Revision: https://secure.phabricator.com/D5366
Summary: We're baking some useful things into ActionHeader, would like to consolidate it's use around the site for consistency.
Test Plan: Tested log out dialog, attach dependencies, delete document in phriction.
Reviewers: epriestley, btrahan
Reviewed By: epriestley
CC: aran, Korvin, AnhNhan
Differential Revision: https://secure.phabricator.com/D5635
