1. 22 Jun, 2020 15 commits
    • Daniel Stone's avatar
      LOCAL/UI: Project: Show review/CI status on workboard · ecb1b12d
      Daniel Stone authored
      On project workboard cards, also show the status of linked code reviews;
      both the review itself, and any attached Harbormaster CI buildables.
      
      This is already taken care of in the task-detail view by 45c740ac,
      and extends it to the workboard view. It should probably share more code
      with the task-detail view.
      
      It will not be accepted upstream in its current form; it was felt in
      https://secure.phabricator.com/T7076 discussion that performing multiple
      queries for each revision to get the current state was too much. This
      makes it exceedingly unlikely that doing the same number of queries for
      every task in a workboard would be acceptable.
      
      There was discussion of how to fix that, but it was essentially
      impossible, and explicitly discouraged for anyone to even try.
      ecb1b12d
    • Daniel Stone's avatar
      LOCAL/POLICY: Maniphest: Auto-assign purchasing tasks to approver · 0e82e784
      Daniel Stone authored
      Enforce a local policy, that on purchasing tasks, the approver will be
      auto-assigned if there is no assignee.
      
      The 'correct' fix would probably be a Herald rule, if it were actually
      possible to implement. An EditEngine extension might work as well, but
      this was easier.
      0e82e784
    • Daniel Stone's avatar
      LOCAL/POLICY: Project: Make project field required for Maniphest · a3382d93
      Daniel Stone authored
      Enforce a local policy that all tasks must have an associated project.
      a3382d93
    • Daniel Stone's avatar
      LOCAL/POLICY: Differential: Clear 'Depends On' when attaching new diff · f3aefef7
      Daniel Stone authored
      When we attach a new diff to a Differential revision, clear out its
      'Depends On' field. This is so we don't end up with dependency cycles
      when we rebase/cherry-pick commits out of order.
      
      As upstream do not use rebasing/chery-picking/multi-patch-branch
      workflows, this is unlikely to be accepted.
      f3aefef7
    • Daniel Stone's avatar
      HACK: Conduit: Accept OAuth2 Authorization header · ceb5d374
      Daniel Stone authored
      This is really lame. The Ruby OAuth2 client can only pass its token in
      the form data (which Phab is not prepared to accept), or as part of the
      Authorization header (which PHP strips out).
      
      Use a function only available in newer PHP to scrape the Authorization
      header from the raw stream.
      
      I have no idea what the correct fix is.
      ceb5d374
    • Daniel Stone's avatar
      HACK: OAuth: Accept Mattermost double-URI · 3c392731
      Daniel Stone authored
      Mattermost OAuth requires two separate URIs, whereas the Phabricator
      OAuth server only allows returning to a single URI. Special case
      Mattermost and get on with life.
      
      The correct fix is to actually allow multiple values in the OAuth
      configuration. I don't know off the top of my head how this would work,
      e.g. a tokenising field, or a multi-line field (which I don't know how
      to achieve without Remarkup), or ... ?
      3c392731
    • Daniel Stone's avatar
      HACK: Reverse add/remove transaction application order · f403b20b
      Daniel Stone authored
      PhabricatorApplicationTransactionEditor contains logic (inside
      combineTransactions -> mergeTransactions ->
      mergePHIDOrEdgeTransactions), which will combine two transactions of the
      same edge type and author, then apply the operations in a deterministic
      order.
      
      This breaks our change to remove dependencies when updating a
      Differential revision, since we (acting as the user who uploaded the
      revision) remove the DifferentialRevisionDependsOn edge, then have the
      Remarkup block parser add the dependencies from the commit message
      later.
      
      The two (simplified) transactions of:
      {
          "1-from-our-change-to-differential": {
              "type": "edge",
              "-": {
      	    "PHID-DREV-1234": [...], // remove previous dep
      	}
          },
          "2-from-remarkup-parsing": {
              "type": "edge",
              "+": {
      	    "PHID-DREV-1234": [...], // add dep from commit message
      	}
          }
      }
      
      get merged into:
      {
          "1-combined": {
              "type": "edge",
      	"-": {
      	    "PHID-DREV-1234": [...], // remove previous dep
      	},
      	"+": {
      	    "PHID-DREV-1234": [...], // add dep from commit message
      	}
          }
      }
      
      getPHIDTransactionNewValue() then returns an empty dictionary, because
      it always executes the add before the remove, regardless of ordering.
      The correct fix would be quite invasive to the transaction editor
      (making the combine function considerably less naïve, and always
      preserving order of operation WRT identical PHIDs); the quick fix for
      now (at least) is to just make add operations execute after remove, thus
      'fixing' it for the only case we really care about.
      
      The correct fix is more time than worthwhile to achieve, especially
      since it's extremely difficult to achieve without code modifications.
      f403b20b
    • Emanuele Aina's avatar
      BROKEN: Add the `phill` command line tool to import projects and tasks · fc3e3bf7
      Emanuele Aina authored
      This is completely broken with modern transactions. It should also be
      rewritten to match Phabricator's coding style.
      fc3e3bf7
    • Daniel Stone's avatar
      WIP: Transactions: Hide transactions involving restricted objects · 412e18fe
      Daniel Stone authored
      If a transaction has an object that a particular user cannot see, then
      mark the transaction as hidden for the default transaction view. This
      particularly elides 'foo moved this task from Restricted Workboard
      Column to Restricted Workboard Column on the Restricted Project board'
      messages in the timeline, which are not hugely useful.
      
      This would need a fair bit more work to go upstream, especially eliding
      notifications for restricted-only transactions as well.
      412e18fe
    • Daniel Stone's avatar
      WIP: Maniphest: Hide hidden project tags for tasks · b5e9b67f
      Daniel Stone authored
      If the viewer doesn't have permission to see something a task has been
      tagged with, then don't show it to them in the Maniphest task list view,
      the task detail view, or the workboard view.
      
      This should be extended further to also eliminate it from the
      transaction history (in the task detail view) and also from
      notifications, but it's a start.
      
      This would need quite a bit more work to go upstream.
      b5e9b67f
    • Daniel Stone's avatar
      WIP: Maniphest: Allow restricting custom fields to subtypes · eaf1c72c
      Daniel Stone authored
      Add a 'subtype' parameter to custom fields, which means they will only
      be visible on (and validated with) tasks of a particular subtype.
      
      Suitable for upstream after much rework:
      https://secure.phabricator.com/D17593
      eaf1c72c
    • Emanuele Aina's avatar
      Derive story/mention time from transactions · 1d55b99c
      Emanuele Aina authored
      By taking the story time from the transaction creation date we ensure that the times reported in the feed view match the ones reported in the item-specific change lists.
      1d55b99c
    • Quinn Ebert's avatar
      Default Phriction ACL configuration support · 530c6484
      Quinn Ebert authored
      This implements an Applications > Phriction configuration option that allows the administrators to specify default view and edit ACL policies for root-level Phriction documents.
      
      Test Plan:
        1. Create a clean test install of Phabricator, login as the admin user
        2. Go to Applications, configure settings for Phriction, set up the ACL you want
        3. Upon creating the first document in Phriction, the ACL chosen by default should be the one you configured in step 2.
      530c6484
    • Daniel Stone's avatar
      Accept arrays in PHID custom-field validation · 10648032
      Daniel Stone authored
      As setValueFromStorage() notes, we can accept either JSON strings or arrays for PHID-type custom fields. Handle this in decodeValue by passing through an array if we've received one.
      
      Test Plan:
        - Add Maniphest custom field with PhabricatorPeopleDatasource
        - Create task with field filled
        - Go to Maniphest task detail view
        - Observe no errors in DarkConsole / PHP error log
      10648032
    • Daniel Stone's avatar
      Preserve silent and time when updating blocked tasks · feaa199c
      Daniel Stone authored
      Ref T13042. Updating blocked tasks creates a new ManiphestTransactionEditor instance from within the current transaction application, which fails to carry over all of the current properties. Failing to update silent means that mails will be generated for updates to blocked tasks, regardless of the setting for the original transaction editor.
      
      Failing to preserve the time can also give large time deltas in corner cases, such as running an importer which pulls tasks from yesteryear.
      
      This equally applies to inverse-edge transactions, though I don't have a ready-made usecase for those.
      feaa199c
  2. 16 Jun, 2020 2 commits
    • epriestley's avatar
      (stable) Improve the quality of SSH error messages · d5a7d408
      epriestley authored
      Summary: See PHI1784. Currently, users who pass an invalid SSH command to Phabricator's SSH handler get an unhelpful error message. Make it more helpful.
      
      Test Plan: Ran `./bin/ssh-exec` with no arguments (old, helpful error), invalid arguments (before: unhelpful error; after: helpful error), and valid arguments (old, helpful behavior).
      
      Differential Revision: https://secure.phabricator.com/D21362
      d5a7d408
    • epriestley's avatar
      (stable) Fix an issue where "Export Data" could fail if a user had a nonempty... · c96d52ca
      epriestley authored
      (stable) Fix an issue where "Export Data" could fail if a user had a nonempty custom policy preference
      
      Summary:
      The "Export Data" workflow incorrectly uses the "Policy Favorites" setting to choose a default export format. This is just a copy/paste error; the correct setting exists and is unused.
      
      If the setting value is an array (as the "Policy Favorites" value often is), we try to use it as an array index. This generates a runtime exception after D21044.
      
      ```
      [2020-06-16 06:32:12] EXCEPTION: (RuntimeException) Illegal offset type in isset or empty at [<arcanist>/src/error/PhutilErrorHandler.php:263]
        #0 <#2> PhutilErrorHandler::handleError(integer, string, string, integer, array) called at [<phabricator>/src/applications/search/controller/PhabricatorApplicationSearchController.php:460]
      ```
      
        - Use the correct setting.
        - Make sure the value we read is a string.
      
      Test Plan:
        - Used "Export Data" with a nonempty, array-valued "Policy Favorites" setting.
          - Before: runtime exception.
          - After: clean export.
        - Used "Export Data" again, saw my selection from the first time persisted.
      
      Differential Revision: https://secure.phabricator.com/D21361
      c96d52ca
  3. 30 May, 2020 1 commit
  4. 26 May, 2020 2 commits
    • epriestley's avatar
      (stable) In Phortune accounts, prevent self-removal more narrowly · 621f9de4
      epriestley authored
      Summary:
      Currently, Phortune attempts to prevent users from removing themselves as account managers. It does this by checking that the new list includes them.
      
      Usually this is sufficient, because you can't normally edit an account unless you're already a manager. However, we get the wrong result (incorrect rejection of the edit) if the actor is omnipotent and the acting user was not already a member.
      
      It's okay to edit an account into a state which doesn't include you if you have permission to edit the account and aren't already a manager.
      
      Specifically, this supports more formal tooling around staff modifications to billing accounts, where the actor has staff-omnipotence and the acting user is a staff member and only used for purposes of leaving a useful audit trail.
      
      Test Plan: Elsewhere, ran staff tooling to modify accounts and was able to act as "alice" to add "bailey", even though "alice" was not herself a manager.
      
      Differential Revision: https://secure.phabricator.com/D21288
      621f9de4
    • epriestley's avatar
      In Phortune accounts, prevent self-removal more narrowly · f686a0b8
      epriestley authored
      Summary:
      Currently, Phortune attempts to prevent users from removing themselves as account managers. It does this by checking that the new list includes them.
      
      Usually this is sufficient, because you can't normally edit an account unless you're already a manager. However, we get the wrong result (incorrect rejection of the edit) if the actor is omnipotent and the acting user was not already a member.
      
      It's okay to edit an account into a state which doesn't include you if you have permission to edit the account and aren't already a manager.
      
      Specifically, this supports more formal tooling around staff modifications to billing accounts, where the actor has staff-omnipotence and the acting user is a staff member and only used for purposes of leaving a useful audit trail.
      
      Test Plan: Elsewhere, ran staff tooling to modify accounts and was able to act as "alice" to add "bailey", even though "alice" was not herself a manager.
      
      Differential Revision: https://secure.phabricator.com/D21288
      f686a0b8
  5. 23 May, 2020 2 commits
  6. 22 May, 2020 6 commits
  7. 21 May, 2020 2 commits
    • epriestley's avatar
      Prevent keyboard selection of change blocks inside edit suggestions · 87fb35ab
      epriestley authored
      Summary: Ref T13513. When a revision has inlines with edit suggestions, pressing "j" and "k" can incorrectly select the blocks inside the diffs inside the inlines.
      
      Test Plan: Used "j" to cycle through changes in a revision with inline comments with edit suggestions, didn't get jumped into the suggestion diffs.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21283
      87fb35ab
    • epriestley's avatar
      Make "Open in Editor" use the simple line number of the current selected block · 66566f87
      epriestley authored
      Summary:
      Ref PHI1749. Instead of opening files to the last unchanged line on either side of the change, open files to the "simple" line number of the selected block.
      
      For inlines, this is the inline line number.
      
      For blocks, this is the first new-file line number, or the first old-file line number if no new-file line number exists in the block.
      
      This may not always be what the user is hoping for (we can't know what the state of their working copy is) but should produce more obvious behavior.
      
      Test Plan:
        - In Diffusion, used "Open in Editor" with and without line selections. Saw same behavior as before.
        - Used "n" and "r" to leave an inline with the keyboard, saw same behavior as before.
        - Used "\" and "Open in Editor" menu item to open a file with:
          - Nothing selected or changeset selected (line: 1).
          - An inline selected (line: inline line).
          - A block selected (line: first line in block, per above).
      
      Differential Revision: https://secure.phabricator.com/D21282
      66566f87
  8. 20 May, 2020 9 commits
    • epriestley's avatar
      Drop old "differential_commit" table · d3d41324
      epriestley authored
      Summary: Ref T13276. Ref T13513. All readers and writers were removed more than a year ago; clean up the last remnants of this table.
      
      Test Plan: Grepped for table references, found none.
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13513, T13276
      
      Differential Revision: https://secure.phabricator.com/D21281
      d3d41324
    • epriestley's avatar
      Use the changeset parse cache to cache suggestion changesets · 6d0dbeb7
      epriestley authored
      Summary:
      Ref T13513. Syntax highlighting is potentially expensive, and the changeset rendering pipeline can cache it. However, the cache is currently keyed ONLY by Differential changeset ID.
      
      Destroy the existing cache and rebuild it with a more standard cache key so it can be used in a more ad-hoc way by inline suggestion snippets.
      
      Test Plan: Used Darkconsole, saw cache hits and no more inline syntax highlighting for changesets with many inlines.
      
      Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21280
      6d0dbeb7
    • epriestley's avatar
      Put a readthrough cache in front of inline context construction · 5d0ae283
      epriestley authored
      Summary: Ref T13513. Inline comment context information is somewhat expensive to construct and can be cached. Add a readthrough cache on top of it.
      
      Test Plan: Loaded a source code changeset with many inline comments, used Darkconsole to inspect query activity. Saw caches get populated. Updated cache key, saw caches regenerate. Browsed Diffusion, nothing looked broken.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21279
      5d0ae283
    • epriestley's avatar
      Clean up Diffusion behaviors for inline edit suggestions · d2d7e7f5
      epriestley authored
      Summary: Ref T13513. For now, I'm not supporting inline edit suggestions in Diffusion, although it's likely not difficult to do so in the future. Clean up some of the code so that plain ol' inlines work the same way they did before.
      
      Test Plan:
        - Created, edited, reloaded, submitted inlines in Diffusion: familiar old behavior.
        - Created, edited, reloaded, submitted inlines with suggestions in Differential: familiar new behavior.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21278
      d2d7e7f5
    • epriestley's avatar
      Render inline comment suggestions as real diffs · 10f24135
      epriestley authored
      Summary: Ref T13513. When rendering an inline suggestion for display, use highlighting and diffing.
      
      Test Plan: {F7495053}
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21277
      10f24135
    • epriestley's avatar
      Roughly support inline comment suggestions · 84656215
      epriestley authored
      Summary:
      Ref T13513. This still has quite a few rough edges and some significant performance isssues, but appears to mostly work.
      
      Allow reviewers to "Suggest Edit" on an inline comment and provide replacement text for the highlighted source.
      
      Test Plan: Created, edited, reloaded, and submitted inline comments in various states with and without suggestion text.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21276
      84656215
    • epriestley's avatar
      Make server components of inline comment content handling state-oriented · 00430fdb
      epriestley authored
      Summary: Ref T13513. Introduce a formal server-side content state object so the whole state can be saved and restored to the drafts table, read from the request, etc.
      
      Test Plan: Created and edited inlines. Reloaded drafts with edits. Submitted normal and editing comments. Grepped for affected symbols.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21275
      00430fdb
    • epriestley's avatar
      Allow "has draft inlines?" queries to overheat · 4b2a4470
      epriestley authored
      Summary:
      Ref T13513. If your 10 most recently authored inlines have all been deleted, these queries can fail by overheating. This is silly and probably rarely happens outside of development.
      
      For now, just let them overheat. This may create a false negative (incorrect "no draft" signal when the real condition is "drafts, but 10 most recent comments were deleted"). This could be sorted out later with a query mode like "executeAny()", perhaps.
      
      Test Plan:
        - Created and deleted 10 inlines.
        - Submitted comments.
        - Before: overheating fatal during draft flag generation.
        - After: clean submission.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21274
      4b2a4470
    • epriestley's avatar
      Make inline content "state-oriented", not "string-oriented" · 87bc3052
      epriestley authored
      Summary:
      Ref T13513. Currently, all the inline code passes around strings to describe content. I plan to add background music, animation effects, etc., soon. To prepare for this change, make content a state object.
      
      This does not change any user-visible behavior, it just prepares for content to become more complicated than a single string.
      
      Test Plan: Created, edited, submitted, cancelled, etc., comments.
      
      Maniphest Tasks: T13513
      
      Differential Revision: https://secure.phabricator.com/D21273
      87bc3052
  9. 19 May, 2020 1 commit
    • epriestley's avatar
      Remove PHPMailer code which generates bogus "Message-ID" email headers · 9d5b8bd1
      epriestley authored
      Summary:
      See <https://discourse.phabricator-community.org/t/how-to-override-localhost-localdomain-in-email-message-id/3876/>.
      
      Currently, Phabricator generates a "Message-ID" only in a subset of cases (roughly: when the message is first-in-thread and we expect the thread may have more than one message).
      
      In cases where it does not generate a message ID, it expects the SMTP server to generate one for it. Servers will generally do this, and some ONLY do this (that is, they ignore IDs from Phabricator and replace them). Thus, several pieces of configuration control whether Phabricator attempts to generate a "Message-ID" at all.
      
      The PHPMailer code has fallback behavior which generates a "<random>@localhost.localdomain" message ID. This is never desirable and ignores Phabricator-level configuration that Message IDs should not be generated.
      
      For now, remove this code: it is never the desired behavior and sometimes explicitly contradicts the intent of configuration.
      
      Possibly, a better change may be to make Phabricator always generate a message ID in cases where it isn't forbidden from doing so by configuration. However, that's a more complicated change and it's not clear if/when it would produce better behavior, so start here for now.
      
      Test Plan: Confirmed by affected user (see linked thread).
      
      Differential Revision: https://secure.phabricator.com/D21272
      9d5b8bd1