07d640d2b6
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 |
||
|---|---|---|
| bin | ||
| conf | ||
| externals | ||
| resources | ||
| scripts | ||
| src | ||
| support | ||
| webroot | ||
| .arcconfig | ||
| .arclint | ||
| .editorconfig | ||
| .gitignore | ||
| LICENSE | ||
| NOTICE | ||
| README.md | ||
Phabricator is an open source collection of web applications which help software companies build better software.
Phabricator includes applications for:
- reviewing and auditing source code;
- hosting and browsing repositories;
- assembling a party to venture forth;
- tracking bugs;
- managing projects;
- writing stuff down and reading it later;
- hiding stuff from coworkers; and
- also some other things.
You can learn more about the project (and find links to documentation and resources) at Phabricator.org
Phabricator is developed and maintained by Phacility. The first version of Phabricator was originally built at Facebook.
BUG REPORTS Please update your install to HEAD before filing bug reports. You can follow our bug reporting guide or and file the issue in Maniphest.
FEATURE REQUESTS We're big fans of feature requests that state core problems, not just 'add this'. We've compiled a short guide to effective upstream requests here.
SECURITY ISSUES Phabricator participates in HackerOne and may pay out for various issues reported there. You can find out more information on our HackerOne page.
PULL REQUESTS We do not accept pull requests through GitHub. If you would like to contribute code, please read our Contributor's Guide for more information.
LICENSE Phabricator is released under the Apache 2.0 license except as otherwise noted.