PHUIButtonBarView

Summary: Adds a handy bar full of tiny buttons. Use only when directed. Ref: T4394

Test Plan: View UI Examples.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8169
Legalpad - remarkup LX to link to LX

Summary: standard ish. Fixes T4388.

Test Plan: made a comment with L1 and noted L1 linked to L1. Also observed working-ish hovercard.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T4388

Differential Revision: https://secure.phabricator.com/D8178
Add Description Header/Icon in Pholio

Summary: Add described, simple header and icon with divider.

Test Plan: Tested on an existing mock and created a new mock with and without a description.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8181
Make Projects a PhabricatorSubscribableInterface, but with restricted defaults

Summary:
Ref T4379. I want project subscriptions to work like this (yell if this seems whacky, since it makes subscriptions mean somethign a little different for projects than they do for other objects):

  - You can only subscribe to a project if you're a project member.
  - When you're added as a member, you're added as a subscriber.
  - When you're removed as a member, you're removed as a subscriber.
  - While you're a member, you can optionally unsubscribe.

From a UI perspective:

  - We don't show the subscriber list, since it's going to be some uninteresting subset of the member list.
  - We don't show CC transactions in history, since they're an uninteresting near-approximation of the membership transactions.
  - You only see the subscription controls if you're a member.

To do this, I've augmented `PhabricatorSubscribableInterface` with two new methods. It would be nice if we were on PHP 5.4+ and could just use traits for this, but we should get data about version usage before we think about this. For now, copy/paste the default implementations into every implementing class.

Then, I implemented the interface in `PhabricatorProject` but with alternate defaults.

Test Plan:
  - Used the normal interaction on existing objects.
  - This has no actual effect on projects, verified no subscription stuff mysteriously appeared.
  - Hit the new error case by fiddling with the UI.

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8165
Improve detection of no-op edge edits in ApplicationTransactions

Summary:
Ref T4379. When you add a redundant edge, we currently compare the values strictly, using `===`. However, the old and new versions of the edge have slightly different member data, because one has been synthetically constructed and one has been read from the database.

Instead, compare only the things we actually care about:

  # Were any destintations added or removed?
  # Was any edge data changed?

If the answer to both questions is "no", consider the update a no-op.

Test Plan: In the next diff, I'm making project members use the EDGE transaction type. Before this change, adding an existing project member would generate a transaction with no changes. Now, it is correctly detected as a no-op, while normal transactions continue to work properly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8166
Implement "Edit Members" and "Join/Leave" with real ApplicationTransactions

Summary:
Ref T4379. Projects has been partially converted to ApplicationTransactions, but the rough state of the world is that all the //storage// is modern, but most of the stuff on top isn't yet. Particularly, there's a `PhabricatorProjectEditor` which is //not// a subclass of `PhabricatorApplicationTransactionEditor`, but which fakes its way through writing reasonable data into modern storage.

This introduces a real transaction editor, `PhabricatorProjectTransactionEditor`, with the eventual goal of moving all of the old functionality into it and deleting the old class. This diff only moves the membership transaction into new code (it doesn't even move all of it -- when we create a project, we add the author as a member, and that can't move quite yet since there are other transactions at the same time).

Test Plan:
  - Created a new project.
  - Edited members.
  - Joined / left project.
  - This already has a pile of unit test coverage.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8167
Remove PhabricatorProjectEditor

Summary:
Ref T4379. Perform all editing with modern transaction infrastructure. A few practical changes here:

  - Message for "project name required" should be a little nicer. I'll deal with this once more stuff gets straightened out. You get a reasonable message now, it's just not nicely handled as part of the form.
  - Message for "project name is not unique" should be a little nicer. Same as above.
  - Previously, we would automatically archive a project when the last member left or was removed. I'll probably restore this in a bit but am omitting it for the moment for simplicity.
  - Previously, we would create projects with goofy nonsensical permissions. Now we create them with reasonable permissions.

Test Plan:
  - Created project.
  - Edited project.
  - Ran unit tests.
  - Viewed project edit history.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8168
Move "Archive Project" to a standard, separate action

Summary:
Ref T4379. Projects currently include their "delete/disable" function as part of edit, which is atypical. Instead, provide it as a first-class action. This is primarily for consistency between applications.

(The action list on projects is getting pretty huge, but we can deal with that separately; I have some ideas.)

Test Plan: Archived/unarchived a project. Edited a project.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8177
Make the "you can't edit away your edit capability" policy check generic

Summary:
Ref T4379. Currently, you can edit away your edit capability in Projects. Prevent this in a general way.

Since some objects have complex edit policies (like "the owner can always edit"), we can't just check the value itself. We also can't fairly assume that every object has a `setEditPolicy()` method, even though almost all do right now. Instead, provide a way to pretend we've completed the edit and changed the policy.

Test Plan: Unit tests, tried to edit away my edit capability.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8179
Standardize Pholio CSS

Summary: Use standard spacing and colors

Test Plan: Reload pinboard home, see correct gutters and colors

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8187
Implement custom fields in Projects

Summary:
Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects.

My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure.

A distant secondary goal is that this is a feature which users like/want because users like/want features.

Test Plan: Added a custom field and examined it in the edit, view, and search interfaces.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3794, T4010, T4379

Differential Revision: https://secure.phabricator.com/D8180
Migrate project blurb/description to standard custom field storage

Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it.

Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8182
Migrate project profiles onto projects, and remove ProjectProfile object

Summary:
Ref T4379. Long ago, the "Project" vs "ProjectProfile" split was intended to allow a bunch of special fields on projects without burdening the simple use cases, but CustomField handles that far better and far more generally, and doing this makes using ApplicationTransactions a pain to get right, so get rid of it.

The only remaining field is `profileImagePHID`, which we can just move to the main Project object. This is custom enough that I think it's reasonable not to express it as a custom field.

Test Plan: Created a project, set profile, edited project, viewed in typeahead, ran migration, verified database results.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8183
Make project profile picture edits transactional

Summary: Ref T4379. Make changing pictures use apptransactions.

Test Plan: {F111554}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4379

Differential Revision: https://secure.phabricator.com/D8184
Rebuild custom field indexes when rebuilding standard/fulltext search indexes

Summary:
Ref T4379. Fixes T4359. Currently, `bin/search index` does not rebuild CustomField indexes. This is because they aren't really part of the main search index. However, from a user's point of view this is by far the most logical place to look for index rebuilds, and it's straightforward for us to write into this secondary store.

At some point, it might be nice to let you specify fields as "fulltext" too, although no one has asked for that yet. We could then dump the text of those fields into the fulltext index. Ref T418.

Test Plan: Used `bin/search index --type proj --trace`, etc., and examination of the database to verify that indexes rebuilt. Reindexed users, tasks, projects.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4359, T418, T4379

Differential Revision: https://secure.phabricator.com/D8185
Herald - make herald condition of herald rule display better

Summary: ...by the surprising step of changing how this data is stored from id to phid. Also a small fix to not allow "disabled" rules to be used as herald rule conditions, i.e. can't make a rule that depends on a disabled rule.

Test Plan: viewed existing herald rule that had a rule condition and noted nice new display using handle. made a new rule that had a rule condition and verified it worked correctly.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8186
Remove 'setShadow' from PHUIBoxView

Summary: Removes setShadow, uses setBorder instead

Test Plan: Tested multicolumn, feed, search box, many other areas. Things look less 3d.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8192
Soft-launch project boards

Summary: Ref T1344. I don't think we'll need to destroy any data moving forward, and would like to get more feedback about what changes users want.

Test Plan: Looked at a project and clicked onto its board.

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T1344

Differential Revision: https://secure.phabricator.com/D8191
Support "only the first time" in Maniphest

Summary:
Ref T4403. Implements "only the first time" for Maniphest rules, and fixes the trigger itself.

The trigger would never fire and block rules because it was comparing a string (like "first") to an int (like 0).

The "only" vs "every" stuff is contributed and I should have pushed back harder on this toInt / toString stuff. Maybe I'll just get rid of it; it purely causes confusion and problems.

Test Plan: Wrote an "only the first time" rule, ran it twice, it applied once.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4403

Differential Revision: https://secure.phabricator.com/D8193
Fix alternate filtering conditions in object selector dialog

Summary:
These didn't get updated either when the main search got rebuilt. Adjust and modernize them. Also this uses "exclude", which I couldn't find any callsites for but just missed, so restore that.

At some point I plan to swap this whole thing to ApplicationSearch and that will let us get rid of a bunch of stuff.

Test Plan: Searched for all filters, got sensible results, verified source object doesn't show up as a result.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, mbishopim3

Differential Revision: https://secure.phabricator.com/D8188