1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-24 06:20:56 +01:00
Commit graph

221 commits

Author SHA1 Message Date
Chad Little
a4784e03ff [Redesign] Add Table, Collapse support to ObjectBox
Summary: Converts most all tables to be directly set via `setTable` to an ObjectBox. I think this path is more flexible design wise, as we can change the box based on children, and not just CSS. We also already do this with PropertyList, Forms, ObjectList, and Header. `setCollapsed` is added to ObjectBox to all children objects to bleed to the edges (like diffs).

Test Plan: I did a grep of `appendChild($table)` as well as searches for `PHUIObjectBoxView`, also with manual opening of hundreds of files. I'm sure I missed 5-8 places. If you just appendChild($table) nothing breaks, it just looks a little funny.

Reviewers: epriestley, btrahan

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12955
2015-05-20 12:48:43 -07:00
Bob Trahan
81a475d5a6 Transactions - make implementing TYPE_XXXX_POLICY transactions optional
Summary: Ref T6403. This was actually simple stuff.

Test Plan: changed the edit policy of a paste. changed the edit and join policy of a phame blog.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6403

Differential Revision: https://secure.phabricator.com/D12933
2015-05-19 12:58:18 -07:00
Bob Trahan
16c8d44c37 Transactions - make customization of TYPE_EDGE optional
Summary: Ref T6403. This does TYPE_EDGE since I just had to deal with T8252. Look like this fixes a few editors (maybe) that would have had fatals with mentions like slowvote and ponder.

Test Plan: made a phame post mentioning a task and it worked! joined / left a project, watched / unwatched a project and that worked! blind faith for other sites.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6403

Differential Revision: https://secure.phabricator.com/D12929
2015-05-19 11:26:53 -07:00
epriestley
1970ebcd7b Never generate $0.00 invoices
Summary: Ref T7769. It might possibly make sense to generate these some day, but for now they aren't payable and we have no use for them.

Test Plan:
  - Generated $0.00 invoices, saw code decline to invoice.
  - Generated a $7.99 invoice, got an invoice.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7769

Differential Revision: https://secure.phabricator.com/D12878
2015-05-18 10:28:19 -07:00
Chad Little
46f6c2680e [Redesign] New PHUIObjectItemListView
Summary:
New, cleaner, ObjectItemLists. Lots of minor style tweaks, basic overview:

 - Remove FootIcons
 - Remove Stackable
 - Remove Plain List
 - Add StatusIcon
 - Add setting ObjectList to an ObjectBox
 - Minor retouches to Headers

Mostly, this should give us an idea of life with the new Object Lists. I'll take another application by application pass down the road. This mostly looks at implementation in Maniphest, Differential, Audit, Workboards. Checked a few other areas and dialogs while testing, and everything looks square.

Test Plan: Maniphest, Differential, Homepage, Audit, People, and other applications. Drag reorder, etc.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12865
2015-05-15 13:28:59 -07:00
Joshua Spence
61b178f44e Use PhutilInvalidStateException
Summary: Use `PhutilInvalidStateException`. Depends on D12803.

Test Plan: Unit tests pass.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12829
2015-05-14 07:53:52 +10:00
Joshua Spence
acb45968d8 Use __CLASS__ instead of hard-coding class names
Summary: Use `__CLASS__` instead of hard-coding class names. Depends on D12605.

Test Plan: Eyeball it.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12806
2015-05-14 07:21:13 +10:00
Joshua Spence
70c8649142 Use phutil_json_decode instead of json_decode
Summary: Generally, `phutil_json_decode` should be preferred over `json_decode`.

Test Plan: Eyellballed.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12680
2015-05-05 20:48:55 +10:00
epriestley
2c5760d0ef Allow accounts and merchants to review unpaid invoices in Phortune
Summary:
Ref T6881. Allows accounts to browse all unpaid invoices (although we currently show all of them on the account screen anyway).

Also allows merchants to browse unpaid invoices, which they could not do before. This will let us start suspending instances for nonpayment eventually.

Test Plan:
  - Browsed unpaid invoices as various users.
  - Browsed merchant unpaid invoices.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D12681
2015-05-04 11:06:09 -07:00
epriestley
55e49d7e31 Provide more buildXClause() and buildXClauseParts() on PolicyAwareQuery
Summary:
Ref T4100. Ref T5595. These functions are trivial for now, but move us toward being able to define more default query behavior by default.

Future changes will give these methods meaningful, nontrivial behaviors.

Test Plan: `arc unit --everything`

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5595, T4100

Differential Revision: https://secure.phabricator.com/D12454
2015-04-20 10:06:10 -07:00
epriestley
f5580c7a08 Make buildWhereClause() a method of AphrontCursorPagedPolicyAwareQuery
Summary:
Ref T4100. Ref T5595.

To support a unified "Projects:" query across all applications, a future diff is going to add a set of "Edge Logic" capabilities to `PolicyAwareQuery` which write the required SELECT, JOIN, WHERE, HAVING and GROUP clauses for you.

With the addition of "Edge Logic", we'll have three systems which may need to build components of query claues: ordering/paging, customfields/applicationsearch, and edge logic.

For most clauses, queries don't currently call into the parent explicitly to get default components. I want to move more query construction logic up the class tree so it can be shared.

For most methods, this isn't a problem, but many subclasses define a `buildWhereClause()`. Make all such definitions protected and consistent.

This causes no behavioral changes.

Test Plan: Ran `arc unit --everything`, which does a pretty through job of verifying this statically.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: yelirekim, hach-que, epriestley

Maniphest Tasks: T4100, T5595

Differential Revision: https://secure.phabricator.com/D12453
2015-04-20 10:06:09 -07:00
epriestley
01c99335fd Give Phortune carts a proper isInvoice flag
Summary:
See some earlier discussion in D11593:

> One thing I'm vaguely thinking about is the possibilty that users may be able to invoice one another directly, eventually. For example, we might invoice a contracting client.
> We might need an `isInvoice` flag eventually, but `subscriptionPHID` is a reasonable stand-in for now.

This adds such a flag.

Test Plan:
  - Generated an ad-hoc invoice and verified it showed up in the right place.
  - Used `bin/phortune invoice` to invoice a subscription and verified it worked correctly.
  - Paid an invoice and saw it leave "pending invoices" status.

{F377029}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D12480
2015-04-20 10:05:44 -07:00
epriestley
0195e751c6 Support basic ad-hoc invoices in Phortune
Summary:
This allows a merchant to send a user an invoice for something arbitrary, like services rendered.

Two major missing parts:

  - These don't actually get marked as invoices. I'll fix that in the next diff, but it's not entirely trivial because `subscriptionPHID` is currently overloaded to also mean "is invoice".
  - We don't send email automatically. I don't plan to fix that for now, since all our invoicing needs are covered by personal email.

Test Plan:
Merchants have a new "new invoice" option:

{F376999}

This leads to selecting a user and account, and then you can generate the invoice (only one actual "purchase" / line item for the moment). You can add a longer-form remarkup description to contextualize the billable items:

{F377001}

This sends the invoice and takes you to the merchant order overview screen:

{F377002}

For now, you copy/paste that link into a nice personal enterprisey business-to-business email; the recipient sees this:

{F377003}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D12478
2015-04-20 10:05:22 -07:00
Chad Little
21f0ce7362 Make taller tables the default for AphrontTableView
Summary: I considered at the time just making all tables taller. This removes the special casing and adds the space universally. On first glance all smaller tables look great, but Diffusion seems a little bloated. After a short time period though that went away for me. I do think Diffusion overall needs a UI refresh.

Test Plan: Tested numerous tables in Phortune, Diffusion, etc. Spacing feels more readable.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12328
2015-04-08 08:38:15 -07:00
epriestley
7c5f71b691 Subclass most ReplyHandlers from TransactionReplyHandler
Summary: Ref T7199. Half of these aren't even reachable, but make some progress toward reducing the amount of nonsense and garbage in mail handling.

Test Plan: Tested all reachable handlers with `bin/mail receive-test`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7199

Differential Revision: https://secure.phabricator.com/D12237
2015-04-01 08:39:50 -07:00
epriestley
030e05aa4c Remove reply handler instructions from email
Summary:
Ref T7199. Although this is useful for discovery, it's un-useful enough that we already have an option to disable it, and most applications do not provide any meaningful instructions.

Throwing it away makes it easier to move forward and lets us get rid of a config option.

This is becoming a more advanced/power-user feature anyway, and the new syntax will be significantly more complex and hard to explain with a one-liner. I'm currently thinking that I'll maybe make the "help" menu a dropdown and give it some options like:

  +---+
  | O |
  +---+---------------------+
  | Maniphest Documentation |
  | Maniphest Email Actions |
  +-------------------------+

Then you click the "Email Actions" thing and get a runtime-derived list of available options. Not sure if I'll actually build that, but I think we can fairly throw the in-mail instructions away even if we don't go in that specific direction.

Test Plan: Grepped for `replyHandlerInstructions`, got no hits.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7199

Differential Revision: https://secure.phabricator.com/D12229
2015-03-31 16:48:17 -07:00
epriestley
d403700e1f Convert all tokenizers to take token/scalar inputs
Summary: Ref T7689. Ref T4100. This advances the goals of removing `loadViewerHandles()` (only 67 callsites remain!) and letting tokenizers some day take token functions like `viewer()` and `members(differential)`.

Test Plan:
- Sent a new message; used "To".
  - I simplified the cancel URI construction slightly because it's moot in all normal cases.
- Edited a thread; used "Add Participants".
- Searched rooms; used "Participants".
- Searched countdowns; used "Authors".
- Created a diff; used "Repository".
- Edited a revision; edited "Projects"; edited "Reveiwers"; edited "Subscribers".
- Searched for revisions; edited "responsible users"; "authors"; "reviwers"; "subscribers"; "repositories".
- Added revision comments; edited "Add Reveiwers"; "Add Subscribers".
- Commented on a commit; edited "Add Auditors"; "Add subscribers".
- Edited a commit; edited "Projects".
- Edited a repository; edited "Projects".
- Searched feed, used "include Users"; "include Proejcts".
- Searched files, used "authors".
- Edited initiative; edited "Projects".
- Searched backers; used "Backers".
- Searched initiatives; used "Owners".
- Edited build plans; edited "Run Command".
- Searched Herald; used "Authors".
- Added signature exemption in Legalpad.
- Searhced legalpad; used "creators"; used "contributors".
- Searched signatures; used "documents"; used "signers".
- Created meme.
- Searched macros; used "Authors".
- Used "Projects" in Maniphest reports.
- Used Maniphest comment actions.
- Edited Maniphest tasks; edited "Assigned To"; edited "CC"; edited "projects".
- Used "parent" in Maniphest task creation workflow.
- Searched for projects; used "assigned to"; "in any projec"; "in all projects"; "not in projects"; "in users' projects"; "authors"; "subscribers".
- Edited Maniphest bug filing domains, used "Default Author".
- Searched for OAuth applications, used "Creators".
- Edited Owners pacakge; edited "Primary Owner"; edited "Owners".
- Searched for Owners packages; used "Owner".
  - OMG this UI is OLD
- Edited a paste; edited "Projects".
- Searched for paste; used "Authors".
- Searched user activity log; used "Actors"; used "Users".
- Edited a mock; edited "Projects"; edited "CC".
- Searched for mocks; used "Authors".
- Edited Phortune account; edited "Members".
- Edited Phortune merchant account; edited "Members".
- Searched Phrequent; used "Users".
- Edited Ponder question; sued "projects".
- Searched Ponder; used "Authors"; used "Answered By".
- Added project members.
- Searched for projects; used "Members".
- Edited a Releeph product; edited "Pushers".
- Searched pull requests; searched "Requestors".
- Edited an arcanist project; used "Uses Symbols From".
- Searhced push logs; used "Repositories"; used "Pushers".
- Searched repositories; used "In nay project".
- Used global search; used Authors/owners/Subscribers/In Any Project.
- Edited a slowvote; used "Projects".
- Searched slovotes; used "Authors".
- Created a custom "Users" field; edited and searched for it.
- Made a whole lot of typos in this list. ^^^^^^

Did not test:

- Lint is nontrivial to test locally, I'll test it in production.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4100, T7689

Differential Revision: https://secure.phabricator.com/D12224
2015-03-31 14:10:55 -07:00
epriestley
64dddc76c5 Remove Controller->getHandle() and Controller->loadHandles()
Summary: Ref T7689. Modernize all callsites of these methods.

Test Plan:
- Poked at dashboards.
  - Pretty sure this code is technically unreachable right now.
- Viewed commit; viewed "Audit Status".
- Viewed a fund; viewed "Payable to"; viewed "Owner".
- Viewed herald rules; viewed "Author"; viewed "Applies To".
- Viewed a Legalpad document; viewed "Contributors".
- Viewed Phame post list; viewed blog; viewed post (viewed "Blog", viewed "Blogger").
- Viewed a macro; viewed "Audio".
- Viewed a Phriction page; viewed "Last Author".
- Viewed a Ponder question; viewed "Author".
- Viewed a Ponder answer; viewed header.
  - Behavior changed very slightly here; whatevs.
- Viewed a Countdown; viewed "Author".

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7689

Differential Revision: https://secure.phabricator.com/D12210
2015-03-31 05:48:20 -07:00
epriestley
a8271ecd40 Remove most callsites to Controller->renderHandlesForPHIDs()
Summary: Ref T7689. This moves most of the easy/testable callsites off `Controller->renderHandlesForPHIDs()`.

Test Plan:
- Viewed a file; viewed author; viewed "attached" tab.
- Viewed a mock; viewed attached tasks.
- Viewed a credential; viewed "Used By".
- Viewed a paste; viewed author; viewed forks; viewed forked from.
- Viewed a dashboard; viewed panel list.
- Viewed a dashboard panel; viewed "Appears On".
- Viewed a Phortune account; viewed "Members"; viewed payment methods.
- Viewed a Phortune merchant account; viewed "Members".
- Viewed Phortune account switcher; viewed "Accounts".
  - I just removed "Members:" here since it felt kind of out-of-place anyway.
- Viewed a Phragment fragment, viewed "Latest Version", viewed "Snapshots".
- Viewed a Phargment snapshot, viewed "Fragment".

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: hach-que, epriestley

Maniphest Tasks: T7689

Differential Revision: https://secure.phabricator.com/D12207
2015-03-31 05:48:19 -07:00
Chad Little
c4799b2c45 Basic touchups to Phortune UI
Summary: This is just a quick pass to fix a few bugs and spacing issues, Phortune itself could probably use some more custom UI, but that'll require some thought and abstraction. This also adds a new taller table CSS, which I mayyyy make automatic on tables with few rows, we'll see.

Test Plan: Browsed my Phortune account, tested new spacing on `admin` for 'full effect'

Reviewers: epriestley, btrahan

Reviewed By: btrahan

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12115
2015-03-26 13:16:09 -07:00
epriestley
cc7a9660b6 Don't workflow the "add payment method" button from carts
This doesn't work with the auto-select code.
2015-03-15 13:52:46 -07:00
epriestley
aadec98d43 Correct use of "trigger.this-epoch" vs "trigger.next-epoch"
These parameters were set inconsistently. Use the value that the storage task uses.
Also, allow `bin/phortune invoice` to invoice in the past and future to aid testing.
2015-03-15 13:32:15 -07:00
epriestley
7d69d8ae6a Remove support for Balanced payments
Summary: See <https://www.balancedpayments.com/stripe>. Just get rid of support since Phortune is a prototype anyway.

Test Plan: `grep`, poked around Phortune.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: aurelijus, epriestley

Differential Revision: https://secure.phabricator.com/D12074
2015-03-13 15:47:37 -07:00
Chad Little
076cc6ed7e Change setErrorView to setInfoView in PHUIObjectBoxView
Summary: Renames the method in PHUIObjectBoxView to match the new PHUIInfoView class.

Test Plan: grepped codebase. Went to Calendar and tried a new status.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12005
2015-03-06 17:03:18 -08:00
epriestley
6b65c578c7 Forbid construction of dashboard panels on various Phortune objects
Summary:
Fixes T7102. These panels don't work, aren't meaningful, and don't seem very useful.

We could eventually support providing context to dashboards somehow ("merchant dashboard") but don't have much of an apparent need for this.

Test Plan:
  - Tried to create cart/subscription/charge dashboard panels.
  - Unable to create new ones.
  - The ones from before the change show a relevant error now.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7102

Differential Revision: https://secure.phabricator.com/D11953
2015-03-03 10:39:43 -08:00
epriestley
bb342c60e2 Don't require payment review by default in Phortune
Summary: We've processed some payments without anything going wrong now, and in the Phacility case we control all the payment amounts and the goods are essentially-virtual and billed-after-delivery anyway, so abuse is fairly difficult/pointless and presumably unlikely.

Test Plan: Paid an invoice and saw it go to completed immediately.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11951
2015-03-03 10:39:00 -08:00
epriestley
2d9206a904 Update remaining Phortune merchant views to use Merchant Authority
Summary: See discussion in D11945. This finishes the rest of the merchant views to respect/use merchant authority in order to interact with objects.

Test Plan:
  - As a merchant: accepted, refunded, updated, browsed orders.
  - As a non-merchant: couldn't do any of that stuff for orders I don't own.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11950
2015-03-03 10:38:47 -08:00
epriestley
ab4743b216 Improve Phortune policy behavior
Summary:
Currently, PhortuneAccounts have a very open default policy to allow merchants to see and interact with them.

This has the undesirable side effect of leaking their names in too many places, because all users are allowed to load the handles for the accounts. Although this information is not super sensitive, we shouldn't expose it.

I went through about 5 really messy diffs trying to fix this. It's very complicated because there are a lot of objects and many of them are related to PhortuneAccounts, but PhortuneAccounts are not bound to a specific merchant. This lead to a lot of threading viewers and merchants all over the place through the call stack and some really sketchy diffs with OmnipotentUsers that weren't going anywhere good.

This is the cleanest approach I came up with, by far:

  - Introduce the concept of an "Authority", which gives a user more powers as a viewer. For now, since we only have one use case, this is pretty open-ended.
  - When a viewer is acting as a merchant, grant them authority through the merchant.
  - Have Accounts check if the viewer is acting with merchant authority. This lets us easily implement the rule "merchants can see this stuff" without being too broad.

Then update the Subscription view to respect Merchant Authority.

I partially updated the Cart views to respect it. I'll finish this up in a separate diff, but this seemed like a good checkpoint that introduced the concept without too much extra baggage.

This feels pretty good/clean to me, overall, even ignoring the series of horrible messes I made on my way here.

Test Plan:
  - Verified I can see everything I need to as a merchant (modulo un-updated Cart UIs).
  - Verified I can see nothing when acting as a normal user.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11945
2015-03-03 10:38:25 -08:00
epriestley
d866af32e0 Don't prompt users to autopay with disabled cards
Summary: Also exclude non-merchant cards.

Test Plan: Loaded subscription, saw better options in dropdown.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11943
2015-03-02 18:25:49 -08:00
epriestley
c56ac11bd2 Don't link payment methods to nowhere
Summary: This page doesn't actually exist and we don't really have any content to put on it right now.

Test Plan: No longer saw bogus link in subscriptions.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11942
2015-03-02 18:17:52 -08:00
epriestley
b170d1c15f Make it easier to add payment methods for subscription autopay
Summary:
Fixes T7424. Ref T6308.

Currently, there's no option to just add a card directly from the autopay UI. Add a button so this works.

Also, chip away at T6308 a bit. This isn't perfect but looks a little less out of place.

Test Plan:
{F327637}

- Added a payment method, then set it as autopay.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6308, T7424

Differential Revision: https://secure.phabricator.com/D11935
2015-03-02 13:01:08 -08:00
epriestley
18340d9cef Fix edit URI for Phortune subscriptions
Summary: This generates not-quite-correctly.

Test Plan: Clicked "Edit Subscription" on a Phortune subscription.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11921
2015-03-01 18:20:56 -08:00
Chad Little
c038c643f4 Move PHUIErrorView to PHUIInfoView
Summary: Since this element isn't strictly about errors, re-label as info view instead.

Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 14:45:56 -08:00
Chad Little
64be155551 Set Payment Methods list to flush in Phortune
Summary: Slighlty tidier display.

Test Plan: Go to Phortune, see flush spacing on Payment Methods

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11887
2015-02-25 12:57:58 -08:00
epriestley
ed7823f577 Allow subscriptions to decline to generate an invoice
Summary: This is a useful capability in Phacility for disabled/suspended instances.

Test Plan: Used `bin/phortune invoice` to invoice a disabled instance, saw it decline to invoice.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11837
2015-02-22 05:39:17 -08:00
Bob Trahan
7f1914540f Phortune - require high security sessions for subscription edits
Summary: Ref T7202.

Test Plan: Visited edit subscription page and it worked. Clicked edit link from subscription view page and got to the right place.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7202

Differential Revision: https://secure.phabricator.com/D11803
2015-02-18 11:37:30 -08:00
epriestley
5a9d70707b Fix bad Phortune Subscriptions query
Summary:
Fixes T7285. If the user tries to view a subscription they don't have permission to view, we may filter all the subscriptions out, then still try to load related data. This can fatal because it's invalid.

Instead, bail if we filtered everything.

Test Plan: Subscritption detail page of another user's subscription is now 404 instead of fatal.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T7285

Differential Revision: https://secure.phabricator.com/D11780
2015-02-16 11:17:51 -08:00
epriestley
05377ef48c Expand Subscription handles slightly
Summary: Ref T7150. Show some basic information instead of nothing.

Test Plan: Used these in Instances.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T7150

Differential Revision: https://secure.phabricator.com/D11767
2015-02-14 13:40:01 -08:00
epriestley
532c440e84 Show a better account name in Phortune account handles
Summary: Accounts have proper names now.

Test Plan: Saw a better name on Instances view.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11766
2015-02-13 11:00:29 -08:00
Bob Trahan
d598edc5f3 MetaMTA - update documentation and make config a tad easier
Summary: Fixes T7088. Mainly this updates the documentation but I also snuck in tweaking how the domain reply handler is built. This does two main things -- makes the behavior consistent as some applications who didn't override this behavior would send out emails with reply tos AND makes it easier for us to deprecate the custom domain thing on a per application basis, which is just silly. On that note, the main documentation doesn't get into how this can be overridden, though I left in that mini blurb on the config setting itself. We could deprecate this harder and LOCK things if you want as well.

Test Plan: read docs, looked good. reasoned through re-factor

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7088

Differential Revision: https://secure.phabricator.com/D11725
2015-02-12 11:05:39 -08:00
Bob Trahan
5a9df1a225 Policy - filter app engines where the user can't see the application from panel editing
Summary: Fixes T7118. This does the basic "filter the list" thing, though it ends up being a little manual since I guess this hasn't come up before? There is also potential weird behavior if the user was using an app and lost access to it - they will have nothing selected on edit - but I think this is actually correct behavior in this circumstance.

Test Plan:
used a user who couldn't get access to the "quick create" apps and noted that the dropdown list on dashboard panel create was missing the expected engines

ran `arc unit --everything` to verify abstract method implemented everywhere

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7118

Differential Revision: https://secure.phabricator.com/D11687
2015-02-04 15:47:48 -08:00
Chad Little
3da38c74da PHUIErrorView
Summary: Clean up the error view styling.

Test Plan:
Tested as many as I could find, built additional tests in UIExamples

{F280452}

{F280453}

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11605
2015-02-01 20:14:56 -08:00
epriestley
58b3c5614b Mail account owners when they have an invoice due
Summary: Ref T6881. If we can't automatically bill an invoice, send the account owners a mail explaining why and asking them to pay it.

Test Plan: {F279596}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11602
2015-02-01 12:33:03 -08:00
epriestley
f6015dbb56 Improve the usability of Phortune
Summary:
Ref T6881.

  - Fix dead links.
  - Let implementations provide more information.
  - Provide more information to implementations.

Test Plan: Links work, invoices show billing periods, fewer "Subscription 6" crumbs, all is well in the world.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11601
2015-02-01 12:32:48 -08:00
epriestley
77db15c47b Automatically bill subscriptions when a payment method is available
Summary:
Ref T6881.

  - Allow users to set a default payment method for a subscription, which we'll try to autobill (not all payment methods are autobillable, so we can't require this in the general case, and a charge might fail anyway).
  - If a subscription has an autopay method, try to automatically bill it.
  - Otherwise, we'll send them an email like "hey here's a bill, it couldn't autopay for some reasons, go pay it and fix those if you want".
  - (That email doesn't exist yet but there's a comment about it.)
  - Also some UI cleanup.

Test Plan:
  - Used `bin/phortune invoice` to autobill myself some fake test money.

{F279416}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11596
2015-02-01 12:31:46 -08:00
epriestley
93e6a9b3ca Allow subscriptions to cost amounts other than one dollar and twenty three cents
Summary: Ref T6881. Sometimes, goods and services cost arbitrary amounts.

Test Plan: See next diff.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11594
2015-02-01 06:08:47 -08:00
epriestley
07d640d2b6 Show invoices on account information page
Summary:
Ref T6881. This is basically just some UX.

Right now, if we invoice you, you can //technically// pay it but since we don't tell you about it and don't show it in the UI you'd have to guess the ID by manipulating the URI. We should probably be at least a little more aggressive about billing.

In the common case when we generate a cart/order, we don't show it to the user or merchant in Phortune until the user takes a payment action (basically, Phortune doesn't recognize the cart until you actually check out with it). In the current use case in Fund (and other reasonable use cases) an un-acted-upon cart hasn't been ordered yet, and is just a place for the application to store state as it hands off the workflow to Phortune.

Even if we had a real "Shop for physical goods" app, I think the same rule would apply -- the application itself would probably track and show your current cart, but it wouldn't make sense to put it into your order history in Phortune until you actually buy it.

Since invoices from subscriptions are essentially identical to not-yet-ordered-carts, that mean they also did not show up in the UI (although I think this is also desirable).

This change carves out a place for them:

  - Add an "invoices" section with unpaid invoices.
  - The UI shows that you have unpaid invoices.
  - Invoices have a slightly different rendering, inclduing an alluring "Pay Now" button.

Some considerations:

  - One thing I'm vaguely thinking about is the possibilty that users may be able to invoice one another directly, eventually. For example, we might invoice a contracting client.
  - Considering this, I thought about making these carts have a special status like `STATUS_DUE`, which replaces `STATUS_READY`, or a flag like `isInvoice`.
  - However, this approach was pretty involved and made the //billing// logic more complicated, so I backed off. The ultimate approach here puts more of the complexity into the display logic, which feels better to me.
  - We might need an `isInvoice` flag eventually, but `subscriptionPHID` is a reasonable stand-in for now.
  - The OrderTable serving double duty for rendering subscriptions feels a little muddy, but I think splitting it into two highly-redundant classes would be worse.

Test Plan:
{F279348}

{F279349}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11593
2015-02-01 06:08:34 -08:00
Chad Little
8b06804394 Remove getIconName from all applications
Summary: Not used anymore

Test Plan: grep for 'getIconName'

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11582
2015-01-30 12:11:21 -08:00
epriestley
d1e793a292 Kind of generate a bill for users
Summary:
Ref T6881. This generates a product, purchase and invoice for users, and there's sort of some UI for them. Stuff it doesn't do yet:

  - Try to autobill when we have a CC;
  - actually tell the user they should pay it;
  - ask the application for anything like "how much should we charge", or tell the application anything like "the user paid".

However, these work:

  - You can //technically// pay the invoices.
  - You can see the invoices you paid in the past.

Test Plan: Used `bin/phriction invoice` to double-bill myself over and over again. Paid one of the invoices.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11580
2015-01-30 11:52:50 -08:00
epriestley
d804598f17 Add some of a billing daemon skeleton
Summary:
Ref T6881. This adds the worker, and a script to make it easier to test. It doesn't actually invoice anything.

I'm intentionally allowing the script to double-bill since it makes testing way easier (by letting you bill the same period over and over again), and provides a tool for recovery if billing screws up.

(This diff isn't very interesting, just trying to avoid a 5K-line diff at the end.)

Test Plan: Used `bin/phortune invoice ...` to get the worker to print out some date ranges which it would theoretically invoice.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11577
2015-01-30 11:29:05 -08:00
epriestley
a65244c449 Build a very basic subscription detail page in Phortune
Summary:
Ref T6881.

  - Add a subscription detail page.

Minor cosmetics:

  - Fix glyph, from "X" (old "X marks the spot" icon) to "diamond" (new gem icon).
  - Name the initial account "Default Account" instead of "Personal Account", since this seems more general.

Test Plan:
{F278623}

And I got two full days to test that Jan 30/31 -> Feb 28 billing logic!

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11576
2015-01-30 11:28:49 -08:00
epriestley
4adc2d8a72 Make it possible for applications to generate concrete subscriptions
Summary:
Ref T6881. This still doesn't "work" in any reasonable sense of the word, but gets us a bit further.

I'll build out the Phortune UI a little bit next, then look at implementing the Worker to do actual billing.

Test Plan:
  - Allocated an instance and saw a Subscription generate properly.
  - Saw subscription show up in the Phortune UI, albeit in a very limited way.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11575
2015-01-30 11:28:13 -08:00
epriestley
7720b799e4 Add boilerplate scaffolding for Phortune subscriptions
Summary:
Ref T6881. This roughs in the major objects, support classes, and controllers.

  - Show subscriptions on account detail.
  - Browse all account subscriptions.
  - Link to active subsciptions from merchant detail.

Test Plan: Clicked around in the UI. There's no way to create subscriptions yet, so I basically just kicked the tires on this. I probably missed a few things that I'll clean up in followups.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6881

Differential Revision: https://secure.phabricator.com/D11482
2015-01-27 14:50:20 -08:00
Chad Little
5d8bb61dde Add FontIcon bridge to AppIcons
Summary: Select a similar or better FontAwesome icon to represent each application

Test Plan: Visual inspection

Reviewers: epriestley, btrahan

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11489
2015-01-24 23:43:01 -08:00
Joshua Spence
d6b882a804 Fix visiblity of LiskDAO::getConfiguration()
Summary: Ref T6822.

Test Plan: `grep`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: hach-que, Korvin, epriestley

Maniphest Tasks: T6822

Differential Revision: https://secure.phabricator.com/D11370
2015-01-14 06:54:13 +11:00
Chad Little
790d250967 Move ActionList mobile links to better location
Summary: Ref T5752, moves mobile action menus to the object box instead of crumbs.

Test Plan: View action menus at tablet, desktop, and mobile break points. Verify clicking buttons works as expected opening menu.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T5752

Differential Revision: https://secure.phabricator.com/D11340
2015-01-12 07:24:35 -08:00
Joshua Spence
e7f8e79742 Fix method visibility for PhabricatorController subclasses
Summary: Ref T6822.

Test Plan: Visual inspection. These methods are only called from within `PhabricatorController` subclasses.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6822

Differential Revision: https://secure.phabricator.com/D11241
2015-01-07 07:34:59 +11:00
Joshua Spence
e448386d39 Fix method visibility for PhabricatorApplicationSearchEngine methods
Summary: Ref T6822.

Test Plan: Visual inspection. These methods are only called from within the `PhabricatorApplicationSearchEngine` class.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6822

Differential Revision: https://secure.phabricator.com/D11242
2015-01-07 07:34:52 +11:00
Joshua Spence
cdf11c9fd1 Remove unused Phortune exceptions
Summary: These classes are no longer used after D10649.

Test Plan: `grep`

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11168
2015-01-03 23:50:32 +11:00
Bob Trahan
6ab3f06b6e Transactions - adding willRenderTimeline to handle tricky cases
Summary: Fixes T6693.

Test Plan:
Made a bunch of comments on a diff with differential, being sure to leave inlines here and there. This reproduced the issue in T6693. With this patch this issue no longer reproduces!

Successfully "showed older changes" in Maniphest too.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6693

Differential Revision: https://secure.phabricator.com/D10931
2014-12-04 13:58:52 -08:00
Bob Trahan
f6e635c8d2 Transactions - deploy buildTransactionTimeline to remaining applications
Summary:
Ref T4712. Specifically...

- Differential
 - needed getApplicationTransactionViewObject() implemented
- Audit
 - needed getApplicationTransactionViewObject() implemented
- Repository
 - one object needed PhabricatorApplicationTransactionInterface implemented
 - setShouldTerminate(true)
- Ponder
 - BONUS BUG FIX - leaving a comment on an answer had a bad redirect URI
 - both PonderQuestion and PonderAnswer needed PhabricatorApplicationTransactionInterface implemented
 - setShouldTerminate(true) on both "history" controllers
 - left a "TODO" on buildAnswers on the question view controller, which is non-standard and should be re-written eventually
- Phortune
 - BONUS BUG FIX - fix new user "createNewAccount" code to not fatal
 - PhortuneAccount, PhortuneMerchant, and PhortuneCart needed PhabricatorApplicationTransactionInterface implemented
 - setShouldTerminate(true) on Account view, merchant view, and cart view controller
- Fund
- Legalpad
- Nuance
  - NuanceSource needed PhabricatorApplicationTransactionInterface implemented
- Releeph (this product is kind of a mess...)
  - HACKQUEST - had to manually create an arcanist project to even be able to make a "product" and get started...!
  - BONUS BUG FIX - make sure to "setName" on product edit
  - ReleephProject (should be ReleepProduct...?), ReleephBranch, and ReleepRequest needed PhabricatorApplicationTransactionInterface implemented
- Harbormaster
  - HarbormasterBuildable, HarbormasterBuild, HarbormasterBuildPlan, and HarbormasterBuildStep all needed PhabricatorApplicationTransactionInterface implemented
  - setShouldTerminate(true) all over the place

Test Plan: foreach application, viewed the timeline(s) and made sure they still rendered

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T4712

Differential Revision: https://secure.phabricator.com/D10925
2014-12-03 15:35:47 -08:00
epriestley
10b86c2aa3 Don't show meme Remarkup hint button if Macro application is not usable
Summary: See <https://phabricator.wikimedia.org/T906>. This behavior is a bug; we should remove the button if the user can't use the application.

Test Plan:
- With Macro uninstalled, did these things verifying the button vanished:
  - Sent a user a message.
  - Edited a revision.
  - Edited repository basic information.
  - Edited an initiative.
  - Edited a Harbormaster build step.
  - Added task comments.
  - Edited profile blurb.
  - Edited blog description.
  - Commented on Pholio mock.
  - Uploaded Pholio image.
  - Edited Phortune merchant.
  - Edited Phriction document.
  - Edited Ponder answer.
  - Edited Ponder question.
  - Edited Slowvote poll.
  - Edited a comment.
- Reinstalled Macro and saw button come back.
- Used button to put silly text on a funny picture.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D10900
2014-11-24 15:25:25 -08:00
Chad Little
1ac84c1b59 Add addLinkSection to MailBody to properly format URIs
Summary: Fixes T6343. Grepped for all callsites and added addLinkSection where needed.

Test Plan: Tested Differential, Maniphest, Conpherence, Ponder and Macro. Inspect HTML mail for anchor tags. Inspect text mails for non-disruption.

Reviewers: epriestley, btrahan

Reviewed By: btrahan

Subscribers: talshiri, Korvin, epriestley

Maniphest Tasks: T6343

Differential Revision: https://secure.phabricator.com/D10762
2014-10-30 15:24:10 -07:00
epriestley
796921021b Build AlmanacService
Summary: Ref T5833. See that task for functional goals and some discussion of design.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10713
2014-10-17 05:01:57 -07:00
epriestley
9352c76e81 Decouple some aspects of request routing and construction
Summary:
Ref T5702. This is a forward-looking change which provides some very broad API improvements but does not implement them. In particular:

  - Controllers no longer require `$request` to construct. This is mostly for T5702, directly, but simplifies things in general. Instead, we call `setRequest()` before using a controller. Only a small number of sites activate controllers, so this is less code overall, and more consistent with most constructors not having any parameters or effects.
  - `$request` now offers `getURIData($key, ...)`. This is an alternate way of accessing `$data` which is currently only available on `willProcessRequest(array $data)`. Almost all controllers which implement this method do so in order to read one or two things out of the URI data. Instead, let them just read this data directly when processing the request.
  - Introduce `handleRequest(AphrontRequest $request)` and deprecate (very softly) `processRequest()`. The majority of `processRequest()` calls begin `$request = $this->getRequest()`, which is avoided with the more practical signature.
  - Provide `getViewer()` on `$request`, and a convenience `getViewer()` on `$controller`. This fixes `$viewer = $request->getUser();` into `$viewer = $request->getViewer();`, and converts the `$request + $viewer` two-liner into a single `$this->getViewer()`.

Test Plan:
  - Browsed around in general.
  - Hit special controllers (redirect, 404).
  - Hit AuditList controller (uses new style).

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5702

Differential Revision: https://secure.phabricator.com/D10698
2014-10-17 05:01:40 -07:00
Chad Little
87679d4295 Add actions to crumbs in fund/phortune
Summary: These were missing. Sorry, need to fix this interface someday.

Test Plan: pay for stuff on mobile

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D10708
2014-10-15 12:17:25 -07:00
epriestley
384fd24627 Send mail about cart/order changes from Phortune
Summary: Ref T2787. When order statuses change, send merchants and users email about it.

Test Plan: Used `bin/mail` to review mail.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10694
2014-10-13 11:16:44 -07:00
epriestley
214b5b7158 Add cart transactions to Phortune
Summary: Ref T2787. I mostly just want these in place so I can glue emails to them, but they're also useful on their own.

Test Plan: {F216515}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10688
2014-10-13 11:16:27 -07:00
epriestley
8ba2a1fd44 Show only recent orders and charges on Phortune account profile page
Summary: Ref T2787. Currently, we show all orders/charges, which won't scale well. Show the 10 most recent and link to full order/charge history.

Test Plan: {F216325}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10685
2014-10-13 11:14:50 -07:00
epriestley
7fc7b89bb4 Remove some dead Phortune code
Summary: Ref T2787. This stuff is now irrelevant and/or has no callsites.

Test Plan: `grep`, poked around

Reviewers: chad, btrahan

Reviewed By: chad, btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10684
2014-10-13 11:14:33 -07:00
epriestley
2172f59ed5 Support logged-out users in Fund
Summary: Ref T5835. Sprinkle `shouldAllowPublic()` around to let logged-out users gain access.

Test Plan: Viewed an initiative while logged out.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5835

Differential Revision: https://secure.phabricator.com/D10683
2014-10-13 11:14:17 -07:00
epriestley
2d0ee77bd4 Give Phortune merchants explicit members
Summary:
Ref T2787. Make this a little more concrete with explicit membership instead of a general edit policy. In particular, we need to know who to email when orders happen, and can't reasonably do that with an edit policy.

I imagine this might eventually get more nuanced (e.g., users who can only approve orders vs users who can manage the merchant itself) but that's a long ways away.

Test Plan: {F216284}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10681
2014-10-13 11:13:50 -07:00
epriestley
159e56d58a Make Phortune account members editable and modernize the edge constant
Summary:
Ref T2787.

  - Account members can add and remove other members (major use case is corporate accounts).
  - Use a modern edge constant setup.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10678
2014-10-10 15:00:06 -07:00
epriestley
44415c5473 Make Fund transactions more informative and complete
Summary: Ref T5835. Show backing amounts in transactions. Account for and show refunds.

Test Plan: {F215869}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5835

Differential Revision: https://secure.phabricator.com/D10676
2014-10-10 11:29:31 -07:00
epriestley
38927d5704 Add a "Review" status to Phortune
Summary: Ref T2787. Allow merchants to flag orders for review. For now, all orders are flagged for review. Eventually, I could imagine Herald rules for coarse things (e.g., require review of all orders over $1,000, or require review of all orders by users not on a whitelist) and maybe examining fraud data for the providers which support it.

Test Plan: {F215848}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10675
2014-10-10 11:29:13 -07:00
epriestley
fe5bc764b3 Support multiple payment accounts and account switching in Phortune
Summary: Ref T2787. Support multiple payment accounts so you can have personal vs company payment accounts.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10673
2014-10-09 16:59:03 -07:00
epriestley
f53861aa9d Smooth out Phortune purchase completion flow
Summary:
Ref T2787. Currently, we dump the user back into the application. Instead, give them a confirmation screen and then let them continue.

Also fix a couple of unit tests I adjusted the underlying behavior of somewhat-recently in libphutil.

Test Plan: {F215498}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10672
2014-10-09 16:58:26 -07:00
epriestley
f41ae2228a Implement Phortune charge updates
Summary: Ref T2787. These don't necessarily do a ton yet, but we can get PayPal out of hold, at least.

Test Plan: Updated charges from all providers. Cleared a PayPal hold.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10670
2014-10-09 16:57:52 -07:00
epriestley
2a2fb62229 Add a HOLD state to Phortune and handle unusual states better
Summary:
Ref T2787. When Paypal comes back to us with funds on hold, dead-end the transaction but handle it properly.

Generally, smooth out the user interaction on weird states.

Implement refudnds/cancels for Paypal.

Test Plan: {F215230}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10667
2014-10-09 04:30:47 -07:00
epriestley
ad991b0197 Handle Phortune charge failures cleanly
Summary:
Ref T2787. Currently, we kill a cart and dead-end the workflow on a charge failure.

Instead, fail the charge and reset the cart so the user can try using a valid payment instrument like a normal checkout workflow would.

Some shakiness/smoothing on WePay for the moment; PayPal is still made up since we don't have a "Hold" state yet.

Test Plan: {F215214}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10666
2014-10-08 17:23:02 -07:00
epriestley
f4604ae147 Implement refunds for Balanced in Phortune
Summary: Ref T2787. Does refunds for Balanced.

Test Plan: {F215205}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10665
2014-10-08 15:33:36 -07:00
epriestley
1e8c314c81 Mostly implement order refunds and cancellations
Summary:
Ref T2787. This has some rough edges but basically works.

  - Users can cancel orders that are in incomplete states (or in complete states, if the application allows them to -- for example, some future application might allow cancellation of billed-but-not-shipped orders).
  - Merchant controllers can partially or fully refund orders from any state after payment.

Test Plan: This is still rough around the edges, but issued Stripe and WePay refunds.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: chad, epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10664
2014-10-08 15:33:25 -07:00
epriestley
b6c65719e4 Allow merchant controllers to review orders in Phortune
Summary: Ref T2787. Sets the stage for administrating / cancelling / refunding orders and hold orders.

Test Plan:
{F215140}

{F215141}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10663
2014-10-08 14:40:02 -07:00
epriestley
19db3fbb60 Allow merchants to disable payment providers and show more UI info
Summary:
Ref T2787.

  - Allow merchants to disable payment providers.
  - Show more useful information about providers on the payments page.
  - Make test vs live more clear.
  - Show merchant status.
  - Add a description to merchants to flesh them out a bit -- the merchant areas of responsibilities seem to be fitting well with accounts, etc.

Test Plan: {F215109}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10662
2014-10-08 08:31:24 -07:00
epriestley
65421a9e3e Make Phortune account page a little more usable
Summary: Ref T2787. Minor UI improvements.

Test Plan: {F214945}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: chad, epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10658
2014-10-08 05:32:01 -07:00
epriestley
608465da1e Track total funding amount on Fund initiatives
Summary: Ref T5835. Show total funding amount and payable merchant on initiatives.

Test Plan: {F214936}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5835

Differential Revision: https://secure.phabricator.com/D10657
2014-10-08 05:31:48 -07:00
epriestley
89a6ed98e7 Use real icons for payment providers
Summary: Ref T2787. Uses the real icons. Straightens out the add payment flow a tiny bit.

Test Plan: {F214922}

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10654
2014-10-07 15:07:01 -07:00
epriestley
9c4b8a0fb2 Adjust payment workflows to deal with merchants and configurable providers in Phortune
Summary:
Ref T2787. Builds on D10649 by rebining existing objects (carts, charges, etc) to merchantPHIDs and providerPHIDs instead of an implicit global merchant and weird global artifacts (providerType / providerKey).

Basically:

  - When you create something that users can pay for, you specify a merchant to control where the payment goes.
  - Accounts are install-wide, but payment methods are bound to merchants. This seems to do a reasonable job of balancing usability and technical concerns.
  - Replace a bunch of weird links between objects with standard PHIDs.
  - Improve "add payment method" flow.

Test Plan: Went through the Fund flow with Stripe and WePay, funding an initiative.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10652
2014-10-07 14:41:59 -07:00
epriestley
9aa5a8cb7b Make payment providers a configurable property of Merchants in Phortune
Summary:
Ref T2787. Instead of making providers global configuration, make them a thing on merchants with web configuration.

Payment methods and some of the pyament workflow needs to be retooled a bit after this, but this seemed like a reasonable cutoff point for this diff.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10649
2014-10-07 14:41:41 -07:00
Joshua Spence
3cf9a5820f Minor formatting changes
Summary: Apply some autofix linter rules.

Test Plan: `arc lint` and `arc unit`

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D10585
2014-10-08 08:39:49 +11:00
epriestley
fcd2025a85 Add Merchants to Phortune
Summary:
Ref T2787. Currently, you add payment providers (Stripe, Paypal, etc) in global configuration.

Generally, this approach is cumbersome, limiting, and often hard for users to figure out. It also doesn't provide a natural way to segment payment receivers or provide web access to administrative payment functions like issuing refunds, canceling orders, etc. I think that stuff definitely needs to be in the web UI, and the rule for access to it can't reasonably just be "all administrators" in a lot of reasonable cases.

The only real advantage is that it prevents an attacker from adjusting settings and pointing something at an account they control. But this attack can be mitigated through notifications, some sort of CLI-only merchant lock, payment accounts being relatively identifiable, etc.

So introduce "merchants", which are basically payable entities. An individual merchant will have attached Paypal, Stripe, etc., accounts, and access rules. When you buy something in an application, the merchant to pay is also specified. They also provide an umbrella for dealing with permissions down the line.

This may get a //little// cumbersome because if there are several merchants your saved card information is not shared across them. I think that will be fine in the normal case (most installs will have only one merchant). Even if it isn't and we leave providers global, I think introducing this is the right call from a web UI / permissions point of view. I'll play around with it in the next couple of diffs and figure out exactly where the line goes.

Test Plan: Listed, created, edited, viewed merchants.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10648
2014-10-07 10:55:16 -07:00
epriestley
61b1fe78c7 Modernize Phortune PHID constants
Summary:
Ref T2787. These were still stuck in the stone ages.

(The handles are pretty skeletal but most aren't used anywehre.)

Test Plan: Funded an initiative without anything breaking. Grepped for removed constants.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10647
2014-10-06 16:48:16 -07:00
epriestley
19c1c07d35 Give Balanced provider complete workflow logic in Phortune
Summary: Ref T2787. Like Stripe, this one is pretty easy to get working correctly on the "good" path and fataling out in a safe way on bad paths.

Test Plan: Funded an initiative with Balanced.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10645
2014-10-06 16:48:02 -07:00
epriestley
31817b9097 Disable Phortune Paypal payment provider
Summary:
Ref T2787. For test charges, Paypal is putting the charge in a "payment review" state. Dealing with this state requires way more infrastructure than other providers: we're supposed to pause delivery, then poll Paypal every 6 hours to see if the review has resolved.

Since I can't seem to generate normal test charges, I can't test Paypal for now. Disable it until we have more infrastructure.

(This diff gets us further along, up to the point where I hit this issue.)

Test Plan: Read documentation, rolled eyes.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10644
2014-10-06 14:51:51 -07:00
epriestley
83e1a1ddb2 Give Stripe complete payment workflow logic in Phortune
Summary:
Ref T2787. This basically already works correctly since the hard logic is external to the provider on API providers. Tweak a couple of things.

Failures still just fail the cart completely, for now.

Test Plan: Completed a charge with Stripe.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10640
2014-10-06 14:21:11 -07:00
epriestley
4ef547f8d6 Give WePay complete payment logic in Phortune
Summary:
Ref T2787. This doesn't get all the edge cases quite correct, but is generally a safe, complete payment workflow:

  - Shares the actual charging state logic.
  - Makes it appropriately stateful with locking and transactions.
  - Gets the main flow correct.
  - Detects failure cases, just tends to blow up rather than help the user resolve them.

Test Plan:
  - Charged with WePay.
  - Charged with Infinite Free Money.
  - Resumed an abandoned cart.
  - Hit all failure states where we just dead-end the cart. Not ideal, but (seemingly) complete/safe/correct.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10639
2014-10-06 14:20:40 -07:00
epriestley
0beb8228da Give applications control over Phortune cart logic
Summary: Ref T2787. Similar to D10634, give applications more control over the cart workflow. For now this just means they get to pick exit URIs, but in the future they can manage more details of cart behavior.

Test Plan: Funded an initiative and got returned to the initiative instead of dead-ending in Phortune.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10638
2014-10-06 14:19:08 -07:00
epriestley
35dc510e18 Add more structure to Phortune product purchasing flow
Summary:
Ref T2787. When a user purchases a product in Phortune, transition the cart through a purchased state and invoke product callbacks so applications can respond to the workflow.

Also shore up some stuff like preventing negative amounts of funding.

Test Plan: Backed an initiative and saw it show up on the initiative after completing the purcahsing workflow.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10635
2014-10-06 10:36:43 -07:00
epriestley
e9615b74a5 Move Phortune product logic into applications
Summary: Ref T2787. `Product` is currently a fairly heavy object, but as Phortune develops it makes a lot of sense to make it a lighter object and put more product logic in applications. Convert it into a fairly lightweight reference to applications. The idea is that Phortune is mostly providing a cart flow, and applications manage the details of products.

Test Plan: Funded an initiative for $1.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10634
2014-10-06 10:30:06 -07:00
epriestley
f86f9dc512 Make Currency a more formal type
Summary:
Ref T2787. Phortune currently stores a bunch of stuff as `...inUSDCents`. This ends up being pretty cumbersome and I worry it will create a huge headache down the road (and possibly not that far off if we do Coinbase/Bitcoin soon). Even now, it's more of a pain than I figured it would be.

Instead:

  - Provide an application-level serialization mechanism.
  - Provide currency serialization.
  - Store currency in an abstract way (currently, as "1.23 USD") that can handle currencies in the future.
  - Change all `...inUSDCents` to `..asCurrency`.
  - This generally simplifies all the application code.
  - Also remove some columns which don't make sense or don't make sense anymore. Notably, `Product` is going to get more abstract and mostly be provided by applications.

Test Plan:
  - Created a new product.
  - Purchased a product.
  - Backed an initiative.
  - Ran unit tests.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T2787

Differential Revision: https://secure.phabricator.com/D10633
2014-10-06 10:26:48 -07:00