Fix border on Actions List.

Summary: This adds setActionList to PropertyListView and properly places it in an archaic HTML 1.0 table.

Test Plan: test layouts with actions really tall or properties really tall. Always see a full height border.

Reviewers: epriestley, btrahan

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D7239
Remove loadMemberPHIDs from PhabricatorProject

Summary:
Ref T603. Move toward stamping out all the Project / ProjectProfile query irregularities with respect to policies.

  - Fixes a bug with Asana publishing when the remote task is deleted.
  - Fixes an issue with Herald commit rules.

Test Plan:
  - Viewed projects;
  - edited projects;
  - added and removed members from projects;
  - republished Asana-bridged feed stories about commits.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7251
Remove PhabricatorProject->loadProfile

Summary: Ref T603. Do modern, sensible queries here.

Test Plan: Viewed project profile, list, member edit, profile edit, used typeahead, changed project image.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7252
Remove `ProjectProfile->loadProfileImageURI()`

Summary: Ref T603. Gets rid of a sketchy, non-policy-aware, unbatched file query.

Test Plan: Looked at projects, typeahead, edited project profile images.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7253
When editing objects which use files, attach the files to the objects

Summary: Ref T603. Fixes T3921. Tightens up policy controls for file/object relationships in existing applications.

Test Plan:
  - Uploaded new project image, verified it got an edge to the project.
  - Uploaded new profile image, verified it got an edge to me.
  - Uploaded new macro image, verified it got an edge to the macro.
  - Uploaded new paste via web UI and conduit, verified it got attached.
  - Replaced, added images to a mock, verified they got edges.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3921, T603

Differential Revision: https://secure.phabricator.com/D7254
Move determination of reviewer authority into DifferentialRevisionQuery

Summary:
Ref T1279. We currently determine reviewers at display time, but this is bad for several reasons:

  - It puts queries very close to the display layer.
  - We have to query for each revision if we want to figure out authority for several.
  - We need to figure it out in several places, so we'll end up with copies of this logic.
  - The logic isn't trivial (exceptions for the viewer, exceptions to that rule for install configuration).
  - We already do this "figure it out when we need it" stuff in Diffusion for audits and it's really bad: we have half-working copies of the logic spread all over the place.

Instead, put it in the Query. Callers query for it and get the data attached to the reviewer objects.

Test Plan:
  - Looked at some revisions, verified the correct lines were highlighted.
    - Looked at a revision I created and verified that projects I was a member of were not highlighted.
      - With self-accept enabled, these //are// highlighted.
    - Looked at a revision I did not create and verified that projects I was a member of were highlighted.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1279

Differential Revision: https://secure.phabricator.com/D7241
When a user accepts a revision, accept for all projects the user has authority over

Summary: Ref T1279. If you accept a revision, also accept on behalf of all the projects you have authority to accept for.

Test Plan:
  - Accepted a revision which I was a reviewer on, saw my own status and an authority project's status change to "Accepted".
  - Accepted a revision which I was not a reviewer on, saw my own status be added (as "Accepted") and the project's status update.

Also, see screenshot.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, wisutsak.jaisue.7

Maniphest Tasks: T1279

Differential Revision: https://secure.phabricator.com/D7242
Allow accepting accepted revisions, and rejecting rejected revisions

Summary:
Ref T1279. With the new per-reviewer status, you can always accept or reject a revision.

This is primarily cosmetic/UI changes. In particular, you've always been able to reject a rejected revision, the UI just didn't show you an option.

Test Plan: Accepted accepted revisions; rejected rejected revisions. See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1279

Differential Revision: https://secure.phabricator.com/D7243
Provide an "Add blocking reviewer..." Herald action

Summary: Ref T1279. These reviewers don't actually create a logical block yet (that is, revisions still transition to "accepted" even in their presence), but this handles everything except that.

Test Plan: Added Herald rules and updated revisions; see screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1279

Differential Revision: https://secure.phabricator.com/D7244
Make "reject" and "blocking reviewer" block acceptance in Differential

Summary:
Ref T1279. This is a logical change.

  - "Reject" (nee "Request Changes") is now sticky. The review won't transition to "Accepted" until the reviewer clears their objection. In practice, I think it always worked like this anyway (without technical enforcement, users just followed this rule naturally, since disobeying this rule is kind of a dick move) so I don't expect this to change much. I think this rule is easier to understand than the old rule now, given the multi-reviewer status and blocking reviewers.
  - "Blocking Reviewer" and "Reject" now prevent a revision from transitioning to "Accepted". When reviewers accept, resign, or are removed, we do a check to see if the reivsion has: at least one user reviewer who has accepted; zero rejects; and zero blocks. If all conditions are satisfied, we transition it to "accepted".

Practically, the primary net effect of this is just to make blocking reviews actually block.

This is pretty messy, but there's not much we can do about it until after T2222, since we have two completely separate editor pathways which are both responsible for adjusting status. Eventually, these can merge into a single sane editor which implements reasonable rules in reaonable ways. But that day is not today.

Test Plan: With three users and a project, made a bunch of accepts, rejects, resigns and reviewer removals. I think I probably covered most of the pathways? There are a lot of interactions here.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, wisutsak.jaisue.7

Maniphest Tasks: T1279

Differential Revision: https://secure.phabricator.com/D7245
Allow Herald rules to be disabled, instead of deleted

Summary:
Ref T603. Ref T1279. Further improves transaction and policy support for Herald.

  - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled.
  - Track disables with transactions.
  - Gate disables with policy controls.
  - Show policy and status information in the headers.
  - Show transaction history on rule detail screens.
  - Remove the delete controller.
  - Support disabled queries in the ApplicationSearch.

Test Plan:
  - Enabled and disabled rules.
  - Searched for enabled/disabled rules.
  - Verified disabled rules don't activate.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1279, T603

Differential Revision: https://secure.phabricator.com/D7247
Fix minor issue with data attachment on project creation