1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-05 05:02:44 +01:00
Commit graph

17077 commits

Author SHA1 Message Date
epriestley
4fd473e7ed Remove explicit administrative actions from the user activity log
Summary:
Depends on D20669. Ref T13343. Currently, the user activity log includes a number of explicit administrative actions which some administrator (not a normal user or a suspicious remote address) takes. In most/all cases, these changes are present in the user profile transaction log too, and that's //generally// a better place for them (for example, it doesn't get GC'd after a couple months).

Some of these are so old that they have no writers (like DELETE and EDIT). I'd generally like to modernize this a bit so we can reference it in email (see T13343) and I'd like to modularize the event types as part of that -- partly, cleaning this up makes that modularization easier.

There's maybe some hand-wavey argument that administrative vs non-administrative events could be related and might be useful to see in a single log, but I can't recall a time when that was actually true, and we could always build that kind of view later by just merging the two log sources, or by restoring double-writes for some subset of events. In practice, I've used this log mostly to look for obvious red flags when users report authentication difficulty (e.g., many unauthorized login attempts), and removing administrative actions from the log is only helpful in that use case.

Test Plan: Grepped for all the affected constants, no more hits in the codebase.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20670
2019-07-19 15:46:20 -07:00
epriestley
2ee5e71029 Simplify implementation of "SysetemAction->getSystemActionConstant()"
Summary: Depends on D20668. Ref T13343. Just an easy cleanup/simplification while I'm here.

Test Plan: `grep` for `getActionConstant()`

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20669
2019-07-19 15:45:37 -07:00
epriestley
a75766c0e5 Replace old rate limiting in password login flow with "SystemAction" rate limiting
Summary:
Depends on D20667. Ref T13343. Password auth currently uses an older rate limiting mechanism, upgrade it to the modern "SystemAction" mechanism.

This mostly just improves consistency, although there are some tangential/theoretical benefits:

  - it's not obvious that making the user log GC very quickly could disable rate limiting;
  - if we let you configure action limits in the future, which we might, this would become configurable for free.

Test Plan:
  - With CAPTCHAs off, made a bunch of invalid login attempts. Got rate limited.
  - With CAPTCHAs on, made a bunch of invalid login attempts. Got downgraded to CAPTCHAs after a few.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20668
2019-07-19 15:44:52 -07:00
epriestley
e090b32c75 Add a rate limit to requesting account recovery links from a given remote address
Summary:
Depends on D20666. Ref T13343. In D20666, I limited the rate at which a given user account can be sent account recovery links.

Here, add a companion limit to the rate at which a given remote address may request recovery of any account. This limit is a little more forgiving since reasonable users may plausibly try multiple variations of several email addresses, make typos, etc. The goal is just to hinder attackers from fishing for every address under the sun on installs with no CAPTCHA configured and no broad-spectrum VPN-style access controls.

Test Plan: {F6607846}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20667
2019-07-19 15:42:53 -07:00
epriestley
80294e7a4a Add a rate limit to generating new account recovery links for a given account
Summary:
Depends on D20665. Ref T13343. We support CAPTCHAs on the "Forgot password?" flow, but not everyone configures them (or necessarily should, since ReCAPTCHA is a huge external dependency run by Google that requires you allow Google to execute JS on your domain) and the rate at which any reasonable user needs to take this action is very low.

Put a limit on the rate at which account recovery links may be generated for a particular account, so the worst case is a trickle of annoyance rather than a flood of nonsense.

Test Plan: {F6607794}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20666
2019-07-19 15:42:21 -07:00
epriestley
ced416cc73 Allow Auth messages to have detailed descriptions and default values, then give "Email Login" both
Summary:
Depends on D20664. Ref T13343. There's a reasonable value for the default "Email Login" auth message (generic "you reset your password" text) that installs may reasonably want to replace. Add support for a default value.

Also, since it isn't completely obvious where this message shows up, add support for an extended description and explain what's going on in more detail.

Test Plan:
  - Viewed message detail page, saw more detailed information.
  - Sent mail (got default), overrode message and sent mail (got custom message), deleted message (got default again).

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20665
2019-07-19 15:39:21 -07:00
epriestley
38d30af362 Give "Auth Messages" a view/detail state before users customize them
Summary:
Depends on D20663. Ref T13343. Currently, if an Auth message hasn't been customized yet, clicking the message type takes you straight to an edit screen to create a message.

If an auth message has already been customized, you go to a detail screen instead.

Since there's no detail screen on the "create for the first time" flow, we don't have anywhere to put a more detailed description or a preview of a default value.

Add a view screen that works if a message is "empty" so we can add this stuff.

(The only reason we don't already have this is that it took a little work to build; this also generally improves the consistency and predictability of this interface.)

Test Plan: {F6607665}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20664
2019-07-19 15:38:45 -07:00
epriestley
a0c9f9f90c Allow installs to customize mail body guidance in the "Email Login" and "Set Password" emails
Summary:
Depends on D20662. Ref T13343. Installs may reasonably want to change the guidance users receive in "Email Login"/"Forgot Password" email.

(In an upcoming change I plan to supply a piece of default guidance, but Auth Messages need a few tweaks for this.)

There's probably little reason to provide guidance on the "Set Password" flow, but any guidance one might issue on the "Email Login" flow probably doesn't make sense on the "Set Password" flow, so I've included it mostly to make it clear that this is a different flow from a user perspective.

Test Plan:
  - Set custom "Email Login" and "Set Password" messages.
  - Generated "Email Login" mail by using the "Login via email" link on the login screen.
  - Generated "Set Password" email by trying to set a password on an account with no password yet.
  - Saw my custom messages in the resulting mail bodies.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20663
2019-07-19 15:37:43 -07:00
epriestley
5dd4895001 Move "Password Reset" email to "PeopleMailEngine"
Summary:
Ref T13343. This makes "Password Reset" email a little more consistent with other modern types of email. My expectation is that this patch has no functional changes, just organizes code a little more consistently.

The new `setRecipientAddress()` mechanism deals with the case where the user types a secondary (but still verified) address.

Test Plan:
  - Sent a normal "login with email" email.
  - Sent a "login with email to set password" email by trying to set a password on an account with no password yet.
  - Tried to email reset a bot account (no dice: they can't do web logins so this operation isn't valid).
  - Tested existing "PeopleMailEngine" subclasses:
    - Created a new user and sent a "welcome" email.
    - Renamed a user and sent a "username changed" email.
  - Reviewed all generated mail with `bin/mail list-outbound`.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13343

Differential Revision: https://secure.phabricator.com/D20662
2019-07-19 15:30:34 -07:00
epriestley
f55aac49f4 Rename "pastebin" database to "paste"
Summary:
See D20650. Long ago, this got added as "pastebin", but that's the name of another product/company, not a generic term for paste storage.

Rename the database to `phabricator_paste`.

(An alternate version of this patch would rename `phabricator_search` to `phabricator_bing`, `phabricator_countdown` to `phabricator_spacex`, `phabricator_pholio` to `phabricator_adobe_photoshop`, etc.)

Test Plan:
  - Grepped for `pastebin`, now only found references in old patches.
  - Applied patches.
  - Browsed around Paste in the UI without encountering issues.

Reviewers: amckinley

Reviewed By: amckinley

Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam

Differential Revision: https://secure.phabricator.com/D20661
2019-07-19 05:53:26 -07:00
epriestley
cb4add3116 In Ferret, allow documents with no title to match query terms by using LEFT JOIN on the "title" ranking field
Summary:
Fixes T13345. See D20650. Currently, `PhabricatorCursorPagedPolicyAwareQuery` does a JOIN against the "title" field so it can apply additional ranking/ordering conditions to the query.

This means that documents with no title (which don't have this field) are always excluded from the result set.

We'd prefer to include them, just not give them any bonus ranking/relevance boost. Use a LEFT JOIN so they get included.

Test Plan:
  - Applied D20650 (diff 1), made it use raw `getTitle()` as the document title, indexed a paste with no title.
  - Searched for a term in the paste body.
  - Before change: no results.
  - After change: found result.

{F6601159}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13345

Differential Revision: https://secure.phabricator.com/D20660
2019-07-18 10:37:36 -07:00
epriestley
17caecdda3 Make workboard real-time updates mostly work
Summary:
Depends on D20654. Ref T4900. When a task is edited, emit a "workboards" event for all boards it appears on (in a future change, this should also include all boards it //previously// appeared on, and all parents of both sets of boards -- but I'm just getting things working for now).

When we receive a "workboards" event, check if the visible board should be updated.

Aphlict has a complicated intra-window leader/follower election system which could let us process this update event exactly once no matter how many windows a user has open with the same workboard. I'm not trying to do any of this since it seems fairly rare. It makes sense for events like "you have new notifications" where we don't want to generate 100 Ajax calls if the user has 100 windows open, but very few users seem likely to have 100 copies of the same workboard open.

Test Plan:
  - Ran `bin/aphlict debug`.
  - Opened workboard A in two windows, X and Y.
  - Edited and moved tasks in window X.
  - Saw "workboards" messages in the Aphlict log.
  - Saw window Y update in nearly-real-time (locally, this is fast enough that it feels instantaneous).

Then:

  - Stopped the Aphlcit server.
  - Edited a task.
  - Started the Aphlict server.
  - Saw window Y update after a few moments (i.e., update in response to a reconnect).

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20656
2019-07-18 10:00:17 -07:00
epriestley
9ab5f59ca2 Export "date" and "remarkup" custom fields to Excel + "zip" extension check
Summary:
Fixes T13342. This does a few different things, although all of them seem small enough that I didn't bother splitting it up:

  - Support export of "remarkup" custom fields as text. There's some argument here to export them in some kind of structure if the target is JSON, but it's hard for me to really imagine we'll live in a world some day where we really regret just exporting them as text.
  - Support export of "date" custom fields as dates. This is easy except that I added `null` support.
  - If you built PHP from source without "--enable-zip", as I did, you can hit the TODO in Excel exports about "ZipArchive". Since I had a reproduction case, test for "ZipArchive" and give the user a better error if it's missing.
  - Add a setup check for the "zip" extension to try to avoid getting there in the first place. This is normally part of PHP so I believe users generally won't hit it, I just hit it because I built from source. See also T13232.

Test Plan:
  - Added a custom "date" field. On tasks A and B, set it to null and some non-null value. Exported both tasks to Excel/JSON/text, saw null and a date, respectively.
  - Added a custom "remarkup" field, exported some values, saw the values in Excel.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13342

Differential Revision: https://secure.phabricator.com/D20658
2019-07-18 09:59:20 -07:00
epriestley
d02beaf816 Make reloading workboards with "R" respect workboard ordering
Summary:
Depends on D20653. Ref T4900. Pass ordering details to the reload endpoint so it can give the client accurate ordering/header information in the response.

The removed comment mentions this, but here's why this is a difficult mess:

  - In window A, view a board with "Group by: Owner" and no tasks owned by "Alice". Since "Alice" owns no tasks, this means the columns do not have an "Assigned to: Alice" header!
  - In window B, edit task T and assign it to Alice.
  - In window A, press "R".

Window A now not only needs to update to properly reflect the state of task T, it actually needs to draw a new "Assigned to: Alice" header in every column.

Fortunately, the "group by" code anticipates this being a big mess, is fairly careful about handling it, and the client can handle this state change and the actual code change here isn't too involved. This is just causing a lot of not-very-obvious indirect effects in the pipeline to handle these situations that need complex redraws.

Test Plan:
  - After making various normal edits/creates/moves in window A, pressed "R" in window B. Saw ordering reflected correctly after sync.
  - Went through the whole "Group by: Owner" + assign to unrepresented owner flow above. After pressing "R", saw "Assigned to: Alice" appear on the board.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20654
2019-07-17 13:17:00 -07:00
epriestley
8669c3c0d2 When updating a workboard with "R", send the client visible set with version numbers
Summary:
Depends on D20652. Ref T4900. When the user presses "R", send a list of cards currently visible on the client and their version numbers.

On the server:

  - Compare the client verisons to the server versions so we can skip updates for objects which have not changed. (For now, the client version is always "1" and the server version is always "2", so this doesn't do anything meaningful, and every card is always updated.)
  - Compare the client visible set to the server visible set and "remove" any cards which have been removed from the board.

I believe this means that "R" always puts the board into the right state (except for some issues with client orderings not being fully handled yet). It's not tremendously efficient, but we can make versioning better (using the largest object transaction ID) to improve that and loading the page in the first place doesn't take all that long so even sending down the full visible set shouldn't be a huge problem.

Test Plan:
  - In window A, removed a card from a board.
  - In window B, pressed "R" and saw the removal reflected on the client.
  - (Also added cards, edited cards, etc., and didn't catch anything exploding.)

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20653
2019-07-17 13:16:03 -07:00
epriestley
1ee6ecf397 Move "BoardResponseEngine" toward a more comprehensive update model
Summary:
Depends on D20639. Ref T4900. Currently, "BoardResponseEngine" has a `setObjectPHID()` method. This is called after edit operations to mean "we just edited object X, so we know it needs to be updated".

Move toward `setUpdatePHIDs(...)` in all cases, with `setUpdatePHIDs(array(the-object-we-just-edited))` as a special case of that. After this change, callers pass:

  - An optional list of PHIDs they know need to be updated on the client. Today, this is always be a card we just edited (on edit/move flows), or a sort of made-up list of PHIDs for the moment (when you press "R"). In the future, the "R" endpoint will do a better job of figuring out a more realistic update set.
  - An optional list of PHIDs currently visible on the client. This is used to update ordering details and mark cards for removal. This is currently passed by edit/move, but not by pressing "R" (it will be in the future).
  - An optional list of objects. The "R" workflow has to load these anyway, so we can save a couple queries by letting callers pass them. For now, the edit/move flows still rely on the engine to figure out what it needs to load.

This does very little to actually change client behavior, it mostly just paves the way for the next update to the "R" workflow to make it handle add/remove cases properly.

Test Plan:
  - Edited and moved cards on a workboard.
  - Pressed "R" to reload a workboard.

Neither of these operations seem any worse off than they were before. They still don't fully work:

  - When you edit a card and delete the current workboard project from it, it remains visible. This is also the behavior on `master`. This is sort of intentional since we don't necessarily want to make these cards suddenly disappear? Ideally, we would probably have some kind of "tombstone" state where the card can still be edited but can't be dragged, and the next explicit user interaction would clean up old tombstones. This interaction is very rare and I don't think it's particularly important to specialize.
  - When a card is removed from the board, "R" can't currently figure out that it should be removed from the client. This is because the client does not yet pass a "visiblePHIDs" state. It will in an upcoming change.
  - The "R" flow always sends a full set of card updates, and can not yet detect that some cards have not changed.
  - There's a TODO, but some ordering stuff isn't handled yet.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20652
2019-07-17 13:13:15 -07:00
epriestley
db69686927 Make pressing "R" on your keyboard reload the card state on workboards
Summary:
Depends on D20638. Ref T4900. This is an incremental step toward proper workboard updates.

Currently, the client can mostly update its view because we do updates when you edit or move a card, and the client and server know how to send lists of card updates, so a lot of the work is already done.

However, the code assumes we're only updating/redrawing one card at a time. Make the client accept and process multiple card updates.

In future changes, I'll add versioning (so we only update cards that have actually changed), fix the "TODO" around ordering, and move toward actual Aphlict-based real-time updates.

Test Plan:
  - Opened the same workboard in two windows.
  - Edited cards in one window, pressed "R" (capital letter, with no modifier keys) to reload the second window.
  - Saw edits and moves reflected accurately after sync, except for some special cases of header/order interaction (see "TODO").

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20639
2019-07-17 13:11:26 -07:00
Austin McKinley
97c1699756 Fix transaction title rendering for AuthenticationConfigs
Summary: I was poking around in `PhabricatorAuthProviderViewController` and noticed that none of the subclass-specific rendering was working. Figured out that no one ever calls `PhabricatorAuthProviderConfigTransaction->setProvider()`, so instead of adding all those calls, just pull the provider out of the config object.

Test Plan:
Before: {F6598145}
After: {F6598147}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D20655
2019-07-17 12:41:00 -07:00
Austin McKinley
2f313a0e0d Remove "unstable" status and T2784-specific warning message
Summary: Ref T2784. These are lookin' pretty stable. Subclasses like `DiffusionGetLintMessagesConduitAPIMethod` have their warnings about unstable methods, so just remove this warning in the base class.

Test Plan: Loaded `/conduit`, observed lack of unstable warnings. Only unstable methods are now `diffusion.getlintmessages`, `diffusion.looksoon`, and `diffusion.updatecoverage`.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T2784

Differential Revision: https://secure.phabricator.com/D20651
2019-07-15 14:05:26 -07:00
Austin McKinley
7852adb84b Actually enforce auth.lock-config
Summary: Forgot to post this after D20394. Fixes T7667.

Test Plan:
    * Edited some providers with the config locked and unlocked.
    * Opened the edit form with the config unlocked, locked the config, then saved, and got a sensible error: {F6576023}

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T7667

Differential Revision: https://secure.phabricator.com/D20645
2019-07-15 11:52:55 -07:00
epriestley
d2935fd7bd Fix a bad call to "writeInfo()" in "bin/phd stop" with no PHABRICATOR_INSTANCE defined
Summary: See <https://discourse.phabricator-community.org/t/phd-status-calls-to-undefined-method-when-theres-no-instance/2918>. This call should be `logInfo()`.

Test Plan:
  - Purged `PHABRICATOR_INSTANCE` from my environment. In a Phacility development environment, it comes from loading `services/`.
  - Ran `bin/phd stop` with all daemons already stopped.
    - Before: bad call.
    - After: helpful error.
  - Ran some other `bin/phd start`, `bin/phd status`, etc., to kick the tires.
  - Grepped for remaining `writeInfo()` calls (found none).

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D20649
2019-07-12 09:15:17 -07:00
epriestley
41ea204144 Update one straggling "CAN_INTERACT" check in comment removal
Summary: See rPaacc62463d61. D20551 added some `CAN_INTERACT` checks, but `CAN_INTERACT` needs to be checked with `canInteract()` to fall back to `CAN_VIEW` properly. D20558 cleaned up most of this but missed one callsite; fix that up too.

Test Plan: Removed a comment on a commit.

Reviewers: amckinley, 20after4

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D20648
2019-07-11 16:09:52 -07:00
epriestley
099919366b Fix "add more metadata" fatal in Pholio
Summary: Ref T13332. This fix isn't terribly satisfying, but resolves the issue: this behavior may attempt to build HTML blocks with metadata after Javascript footer rendering has started. Use `hsprintf()` to flatten the markup earlier.

Test Plan: Put a `T123` reference in the description of a Pholio image, then loaded a mock.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13332

Differential Revision: https://secure.phabricator.com/D20647
2019-07-11 15:55:56 -07:00
Austin McKinley
2c435433e0 Start fleshing out PhabricatorAuthProviderViewController
Summary:
Ref D20645. Start making this view a little more useful:

{F6573605}

Test Plan: Mk. 1 eyeball

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Differential Revision: https://secure.phabricator.com/D20646
2019-07-10 10:45:31 -07:00
Austin McKinley
3c43222525 Fix paging fatal with flagged objects
Summary: Fixes T13331. Just adds a generic `withIDs()` method to `PhabricatorFlagQuery`.

Test Plan: Flagged > 100 objects, observed fatal attempting to page. Next page loads as expected after fix.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin

Maniphest Tasks: T13331

Differential Revision: https://secure.phabricator.com/D20642
2019-07-05 14:25:06 -07:00
epriestley
45f4211541 Fix URI escaping, which should actually be "%s", not "%p"
See <https://discourse.phabricator-community.org/t/projects-workboards-links-issue/2896>.

The documentation on `urisprintf()` isn't very clear here, I'll update it in
a followup. "%p" is for cases like encoding a branch name (which may contain
slashes) as a single path component in a URI.
2019-07-04 11:00:04 -07:00
epriestley
02315c4c48 Fix double-close on dialogs leading to Javascript console error
Summary:
Ref T13302. The "Close/Cancel" button is currently running two copies of the "dismiss dialog" code, since it's techncally a link with a valid HREF attribute.

An alternate formulation of this is perhaps `if (JX.Stratcom.pass()) { return; }` ("let other handlers react to this event; if something kills it, stop processing"), but `pass()` is inherently someone spooky/fragile so try to get away without it.

Test Plan: Opened the Javascript console, clicked "Edit Task" on a workboard, clicked "Close" on the dialog. Before: event was double-handled leading to a JS error in the console. After: dialog closes uneventfully.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13302

Differential Revision: https://secure.phabricator.com/D20640
2019-07-03 12:38:49 -07:00
epriestley
fc795994f3 Remove obsolete "options" from workboard "updateCard()" call
Summary: Depends on D20637. Ref T4900. This is some ancient dead code that nothing uses.

Test Plan: Grepped for `updateCard()` to verify it's private. Searched for "options" and "dirtyColumn" and got no hits.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20638
2019-07-03 10:06:13 -07:00
epriestley
2de8a23adb Remove remnants of clumsy old URI state handling from workboards
Summary:
Depends on D20636. Ref T4900. Previously, some workflows didn't know how to identify the default state for the board, so they needed explicit ("force") parameters.

Everything uses the same state management code now so we can rip out the old stuff.

Test Plan: Changed board filters, selected a custom filter, edited a custom filter.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20637
2019-07-03 10:05:34 -07:00
epriestley
58e2fa0d47 Differentiate between "Move Tasks to Column..." and "Move Tasks to Project..." in the workboard UI
Summary:
Depends on D20635. Ref T4900. Fixes T13316.

Currently, "Move Tasks to Column..." first prompts you to select a project, then prompts you for a column. The first step is prefilled with the current project, so the common case (moving to another column on the same board) requires you to confirm that you aren't doing an off-project move by clicking "Continue", then you can select a column.

This isn't a huge inconvenience and the workflow isn't terribly common, but it's surprising enough that it has come up a few times as a stumbling block. Particularly, we're suggesting to users that they're about to pick a column, then we're asking them to pick a project. The prompt also says "Project: XYZ", not "Project: Keep in current project" or something like that.

Smooth this out by splitting the action into two better-cued flows:

  - "Move Tasks to Project..." is the current flow: pick a project, then pick a column.
    - The project selection no longer defaults to the current project, since we now expect you to usually use this flow to move tasks to a different project.
  - "Move Tasks to Column..." prompts you to select a column on the same board.
    - This just skips step 1 of the workflow.
    - This now defaults to the current column, which isn't a useful selection, but is more clear.

In both cases, the action cue ("Move tasks to X...") now matches what the dialog actually asks you for ("Pick an X").

Test Plan:
  - Moved tasks across projects and columns within the same project.
  - Hit all (I think?) the error cases and got sensible error and recovery behavior.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13316, T4900

Differential Revision: https://secure.phabricator.com/D20636
2019-07-03 10:02:44 -07:00
epriestley
24b466cd62 Move workboard "Move Tasks to Column..." workflow to a separate controller
Summary: Depends on D20634. Ref T4900. Ref T13316. I'm planning to do a bit of additional cleanup here in followups, but this separates the main workflow out of the common controller.

Test Plan:
  - Used "Move Tasks to Column..." to move some tasks on a board.
  - Tried to move an empty column, hit an error.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13316, T4900

Differential Revision: https://secure.phabricator.com/D20635
2019-07-02 15:16:38 -07:00
epriestley
ec352b1b31 Move workboard "Bulk Edit Tasks" workflow to a separate controller
Summary: Depends on D20633. Ref T4900. Separate the "Bulk Edit Tasks..." flow out of the main workboard controller.

Test Plan:
  - Used "Bulk Edit Tasks" on a column with some tasks, got an appropraite edit operation.
  - Used "Bulk Edit Tasks" on an empty column, got an error.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20634
2019-07-02 15:04:38 -07:00
epriestley
9ea7227f0f Move workboard "View as Query" workflow to a separate controller
Summary:
Depends on D20632. Ref T4900. As with other workflows on the board controller, this one is currently in the giant main "do everything" method. Move it to a separate controller.

This makes one material improvement: previously, we built the full board and did layout on all the cards before building the query. However, we do not actually need to do this: we don't need the cards. Instead, just do layout without handing over any card PHIDs. This is slightly faster, particularly on large boards.

Test Plan:
  - Clicked "View as Query" on a board, got a query page for the column.
  - Applied a custom filter, then clicked "View as Query" on a board. Got a query page merging the two filters.
  - Applied a custom filter, then clicked "Veiw as Query" on a board, in a subproject column. Got a query page merging the two filters, respecting the project-ness of the column.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20633
2019-07-02 15:00:36 -07:00
epriestley
577020aea9 Move workboard "filter" workflow to a separate controller
Summary:
Depends on D20629. Ref T4900. Currently, the "Advanced Filter..." workflow on workboards (where you build a custom query) is inline in the main board controller.

This is because the filter flow depends on some of the board view state: we want to start with the current filter applied to the board, and preserve other state after you change the filter.

Now that `ViewState` can handle state management, we can separate this stuff out pretty easily.

Test Plan:
  - Changed filters on a board.
  - Applied a custom filter to a board.
  - Changed the ordering of a board, then applied a custom filter. Verified "Cancel" and "Apply Filter" both preserve the order state.
  - Changed the ordering of a board, then applied a custom filter, intentionally making a mistake in configuring the filter by entering an invalid date. Saw a dialog with an error. After correcting the error, saw state preserved properly.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20632
2019-07-02 14:39:34 -07:00
epriestley
9e096cd274 Give the workboard "default" workflows more modern state handling
Summary:
Depends on D20628. Ref T4900. Currently, the "Save Current Order/Filter As Default" flows on workboards duplicate some state construction, and require parameters to be passed to them explicitly.

Now that state management is separate, they can reuse a bit more code and be made to look more like other similar controllers.

Test Plan:
  - Changed the default order of a workboard.
  - Changed the default filter of a workboard.
  - Changed the order of a board to something non-default, then changed the filter, then saved the new filter as the default. Saw the modified order preserved and the modified filter removed, so I ended up in the right ("most correct") place: on the board, with my custom order in a URI parameter, and no filter URI parameter so I could see my new default filter behavior. This is an edge case that's not terribly important to get right, but we do get it right.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20629
2019-07-02 14:36:15 -07:00
epriestley
9c190d68ed Separate workboard view state (ordering, filtering, hidden columns) from the View controller
Summary:
Depends on D20627. Ref T4900. If a user orders a board by "Sort by Title", then toggles the visibility of hidden columns, we want to keep the board sorted by title. To accomplish this, we pass the board state around to all the workflows here.

Pull the "bag of state properties" code out of the View controller. This class basically:

  - reads state from a request (order, hidden, filter);
  - manages defaults;
  - provides the application with the current settings; and
  - generates URIs with "?order=X&hidden=Y&filter=Z" to preserve state.

This is still a little questionable/transitional since some of the controllers need more cleanup.

Test Plan:
Toggled state, order, filters, clicked around various workflows and saw the filters preserved.

A lot of these workflows are pretty serious edge cases. For example, here's a feature this implements:

  - Changed workboard order to "Title".
  - Selected "Bulk Edit Tasks..." in an empty column and command-clicked it to open the link in a new window.
  - Hovered over "Cancel".
  - Saw the link properly generate with "?order=title", preserving the order.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20628
2019-07-02 14:34:33 -07:00
epriestley
0ae9e2c75d Remove property "id" from Workboard View controller
Summary: Depends on D20626. Ref T4900. On this controller, "id" is a separate property, but serves little purpose and complicates separating state management. Remove it.

Test Plan: Bulk edited a column, managed filters, did show/hide on columns, edited a column.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20627
2019-07-02 05:17:01 -07:00
epriestley
df29b82ad6 Remove unused property "slug" from Workboard View controller
Summary:
Ref T4900. The Workboard view controller currently has a lot of different responsibilities (it's ~1,500 lines long) because it has to manage the board filter/sort state.

I'd like to split it up and make it easier to move some workboard features (like "move all tasks in column...") to other Controllers, so we can have smaller controllers implementing specific workflows.

I think the state handling isn't really all that bad, it just needs to be separated a little better than it currently is.

To start with, remove the unused "slug" property.

Test Plan: Searched for "slug", got no hits. This class is final and the property is private, so this is certainly unused.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T4900

Differential Revision: https://secure.phabricator.com/D20626
2019-07-02 05:16:34 -07:00
epriestley
d22f6d219b Lightly modernize OAuth server application view pages
Summary: Depends on D20624. Fixes T13330. The OAuth client pages are using some out-of-date rendering conventions; update them to modern conventions.

Test Plan:
Viewed a page, saw a modern header layout + curtain:

{F6534135}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13330

Differential Revision: https://secure.phabricator.com/D20625
2019-07-02 05:15:37 -07:00
epriestley
0e2cb6e7c4 Fix missing URI for "OAuthServerClient" object handles, causing dialog with no button
Summary:
Ref T13330. Handles for "OAuthServerClient" objects currently do not have a URI, which causes some obscure fallout like a missing "Close" button when examining their transactions.

Add a URI.

Test Plan:
  - Viewed an OAuth server client detail page.
  - Edited a policy, changing it to a custom policy.
  - Clicked "Custom Policy" in the resulting transaction to view a dialog explaining the changes.
  - Before change: dialog has no close button.
  - After change: dialog has a close button.

{F6534121}

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13330

Differential Revision: https://secure.phabricator.com/D20624
2019-07-02 05:14:14 -07:00
epriestley
d6dc5d8e68 Fix the "x" link in tokenizer tokens incorrectly closing dialogs
Summary:
See <https://discourse.phabricator-community.org/t/removing-tags-or-subscribers-from-a-maniphest-modal-causes-the-modal-to-close/2874>.

My Javascript is rusty: `'' + null == 'null'`. Same for `undefined`. Use an explicit typecheck instead.

Test Plan: Clicked the "x" in a tokenizer token in a dialog, saw the token removed instead of the dialog closed.

Reviewers: amckinley

Reviewed By: amckinley

Differential Revision: https://secure.phabricator.com/D20623
2019-06-28 12:38:51 -07:00
epriestley
159fd44203 Correct transaction strengths after inconsitent scaling by 100 vs 1000
Summary:
See D20540. I mistakenly multiplied some strenghts by 100 and others by 1000 when converting them to integers for `PhutilSortVector`.

Multiply them all by 100 (that is, divide the ones which were multiplied by 1000 by 10) to put things back the way they were.

Test Plan: quick mafs

Reviewers: amckinley, richardvanvelzen

Reviewed By: richardvanvelzen

Differential Revision: https://secure.phabricator.com/D20622
2019-06-26 07:19:33 -07:00
epriestley
987e104610 Bump the remarkup cache version after JIRA/Asana rule changes
Summary: See PHI1319. Ref T13291. Bump the remarkup cache version, since the old JIRA / Asana rules may exist in the partial cached representation of remarkup blocks from older versions.

Test Plan: Typed some comments with various formatting, saw remarkup work fine.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13291

Differential Revision: https://secure.phabricator.com/D20619
2019-06-25 14:56:29 -07:00
epriestley
eaa60334ec Limit the read buffer size in bin/storage dump
Summary:
Ref T13328. Currently, we read from `mysqldump` something like this:

```
until (done) {
  for (100 ms) {
    mysqldump > in-memory-buffer;
  }

  in-memory-buffer > disk;
}
```

This general structure isn't great. In this use case, where we're streaming a large amount of data from a source to a sink, we'd prefer to have a "select()"-like way to interact with futures, so our code is called after every read (or maybe once some small buffer fills up, if we want to do the writes in larger chunks).

We don't currently have this (`FutureIterator` can wake up every X milliseconds, or on future exit, but, today, can not wake for readable futures), so we may buffer an arbitrary amount of data into memory (however much data `mysqldump` can write in 100ms).

Reduce the update frequency from 100ms to 10ms, and limit the buffer size to 32MB. This effectively imposes an artificial 3,200MB/sec limit on throughput, but hopefully that's fast enough that we'll have a "wake on readable" mechanism by the time it's a problem.

Test Plan:
  - Replaced `mysqldump` with `cat /dev/zero` as the source command, to get fast input.
  - Ran `bin/storage dump` with `var_dump()` on the buffer size.
  - Before change: saw arbitrarily large buffers (300MB+).
  - After change: saw consistent maximum buffer size of 32MB.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13328

Differential Revision: https://secure.phabricator.com/D20617
2019-06-25 07:17:14 -07:00
epriestley
da0dfc057d Make "bin/files" parsing of working set arguments more consistent
Summary:
Fixes T13326. In D20571, I slightly generalized construction of an iterator over a set of files, but missed some code in other "bin/files ..." commands which was also affected.

Today, basically all of these workflows define their own "--all" and "names" flags. Pull these definitions up and implement them more consistently.

Test Plan: Ran multiple different `bin/files` commands with different combinations of arguments, saw consistent handling of iterator construction.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13326

Differential Revision: https://secure.phabricator.com/D20614
2019-06-24 16:02:39 -07:00
epriestley
a3397fb876 Consider "all account members are disabled" to be a permanent failure when billing a Phortune subscription
Summary:
Fixes T13327. Currently, when we try to bill an account and all members are disabled, we fail temporarily and the task retries forever.

At least for now, just treat this as a permanent failure.

Test Plan:
  - Used `bin/phortune invoice` to generate a normal invoice for a regular subscription.
  - Disabled all the account members, then tried again. Got a helpful permanent failure:

```
$ ./bin/phortune invoice --subscription PHID-PSUB-kbedwt5cyepoc6tohjq5 --auto-range
Set current time to Mon, Jun 24, 2:47 PM.
Preparing to invoice subscription "localb.phacility.com" from Fri, May 31, 10:14 AM to Sun, Jun 30, 10:14 AM.
 WARNING
Manually invoicing will double bill payment accounts if the range overlaps an
existing or future invoice. This script is intended for testing and
development, and should not be part of routine billing operations. If you
continue, you may incorrectly overcharge customers.

    Really invoice this subscription? [y/N] y

[2019-06-24 14:47:57] EXCEPTION: (PhabricatorWorkerPermanentFailureException) All members of the account ("PHID-ACNT-qp54y3unedoaxgkkjpj4") for this subscription ("PHID-PSUB-kbedwt5cyepoc6tohjq5") are disabled. at [<phabricator>/src/applications/phortune/worker/PhortuneSubscriptionWorker.php:88]
arcanist(head=experimental, ref.master=d92fa96366c0, ref.experimental=db4cd55d4673), corgi(head=master, ref.master=6371578c9d32), instances(head=stable, ref.master=ba9e4a19df1c, ref.stable=37fb1f4917c7), libcore(), phabricator(head=master, ref.master=65bc481c91de, custom=11), phutil(head=master, ref.master=7adfe4e4f4a3), services(head=master, ref.master=5424383159ac)
  #0 PhortuneSubscriptionWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:124]
  #1 PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:163]
  #2 PhabricatorWorker::scheduleTask(string, array, array) called at [<phabricator>/src/applications/phortune/management/PhabricatorPhortuneManagementInvoiceWorkflow.php:169]
  #3 PhabricatorPhortuneManagementInvoiceWorkflow::execute(PhutilArgumentParser) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:457]
  #4 PhutilArgumentParser::parseWorkflowsFull(array) called at [<phutil>/src/parser/argument/PhutilArgumentParser.php:349]
  #5 PhutilArgumentParser::parseWorkflows(array) called at [<phabricator>/scripts/setup/manage_phortune.php:21]
$
```

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13327

Differential Revision: https://secure.phabricator.com/D20613
2019-06-24 15:29:31 -07:00
epriestley
65bc481c91 Remove "phd.pid-directory" configuration and stop passing "piddir" to daemons
Summary: Ref T13321. The daemons no longer write PID files, so we no longer need to pass any of this stuff to them.

Test Plan: Grepped for affected symbols.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13321

Differential Revision: https://secure.phabricator.com/D20608
2019-06-24 11:28:58 -07:00
epriestley
2498e373b9 Make "phd start" and "phd reload" use the process list, not PID files
Summary:
Ref T13321. This gets rid of the last pidfile readers in Phabricator; we just use the process list instead.

These commands always only work on the current instance since they don't make much sense otherwise.

Test Plan: Ran `bin/phd start` and `bin/phd reload` with and without daemons running.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13321

Differential Revision: https://secure.phabricator.com/D20606
2019-06-24 11:27:25 -07:00
epriestley
08b9e70bea Make "bin/phd status" report local daemons from the process list, not a mess of local/remote information
Summary:
Ref T13321. Fixes T11037. Realign "bin/phd status" to just mean "show daemon processes on this host".

The value of `bin/phd status` as a mixed remote/local command isn't clear, and the current output is a confusing mess (see T11037).

This also continues letting us move away from PID files.

Test Plan: Ran `bin/phd status`, saw sensible local process status.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13321, T11037

Differential Revision: https://secure.phabricator.com/D20604
2019-06-24 11:25:53 -07:00
epriestley
b99c240aa3 Deprecate "bin/phd ... --gently" and update documentation
Summary:
Ref T13321. Previously, the behavior was:

  - `bin/phd stop --gently`: Stop all daemons with PID files that belong to the current instance.
  - `bin/phd stop`: Stop all daemons with PID files that belong to the current instance. Complain if there are more processes.
  - `bin/phd stop --force`: Stop all processes that look like daemons, ignoring instances.

The new behavior is:

  - `bin/phd stop`: Stop all processes that look like daemons and belong to the current instance.
  - `bin/phd stop --force`: Stop all processes that look like daemons, period.

Test Plan: Grep / documentation only.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13321

Differential Revision: https://secure.phabricator.com/D20602
2019-06-24 11:16:00 -07:00