1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-21 04:50:55 +01:00
phorge-phorge/src/applications/phortune/view/PhortuneOrderTableView.php

174 lines
3.9 KiB
PHP
Raw Normal View History

<?php
final class PhortuneOrderTableView extends AphrontView {
private $carts;
private $handles;
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 15:08:34 +01:00
private $noDataString;
private $isInvoices;
private $isMerchantView;
public function setHandles(array $handles) {
$this->handles = $handles;
return $this;
}
public function getHandles() {
return $this->handles;
}
public function setCarts(array $carts) {
$this->carts = $carts;
return $this;
}
public function getCarts() {
return $this->carts;
}
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 15:08:34 +01:00
public function setIsInvoices($is_invoices) {
$this->isInvoices = $is_invoices;
return $this;
}
public function getIsInvoices() {
return $this->isInvoices;
}
public function setNoDataString($no_data_string) {
$this->noDataString = $no_data_string;
return $this;
}
public function getNoDataString() {
return $this->noDataString;
}
public function setIsMerchantView($is_merchant_view) {
$this->isMerchantView = $is_merchant_view;
return $this;
}
public function getIsMerchantView() {
return $this->isMerchantView;
}
public function render() {
$carts = $this->getCarts();
$handles = $this->getHandles();
$viewer = $this->getUser();
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 15:08:34 +01:00
$is_invoices = $this->getIsInvoices();
$is_merchant = $this->getIsMerchantView();
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 15:08:34 +01:00
$rows = array();
$rowc = array();
foreach ($carts as $cart) {
$cart_link = $handles[$cart->getPHID()]->renderLink();
$purchases = $cart->getPurchases();
if (count($purchases) == 1) {
$purchase = head($purchases);
$purchase_name = $handles[$purchase->getPHID()]->renderLink();
$purchases = array();
} else {
$purchase_name = '';
}
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 15:08:34 +01:00
if ($is_invoices) {
$merchant_link = $handles[$cart->getMerchantPHID()]->renderLink();
} else {
$merchant_link = null;
}
$rowc[] = '';
$rows[] = array(
$cart->getID(),
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 15:08:34 +01:00
$merchant_link,
phutil_tag(
'strong',
array(),
$cart_link),
$purchase_name,
phutil_tag(
'strong',
array(),
$cart->getTotalPriceAsCurrency()->formatForDisplay()),
PhortuneCart::getNameForStatus($cart->getStatus()),
phabricator_datetime($cart->getDateModified(), $viewer),
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 15:08:34 +01:00
phabricator_datetime($cart->getDateCreated(), $viewer),
phutil_tag(
'a',
array(
'href' => $cart->getCheckoutURI(),
'class' => 'small green button',
),
pht('Pay Now')),
);
foreach ($purchases as $purchase) {
$id = $purchase->getID();
$price = $purchase->getTotalPriceAsCurrency()->formatForDisplay();
$rowc[] = '';
$rows[] = array(
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 15:08:34 +01:00
'',
'',
$handles[$purchase->getPHID()]->renderLink(),
$price,
'',
'',
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 15:08:34 +01:00
'',
'',
);
}
}
$table = id(new AphrontTableView($rows))
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 15:08:34 +01:00
->setNoDataString($this->getNoDataString())
->setRowClasses($rowc)
->setHeaders(
array(
pht('ID'),
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 15:08:34 +01:00
pht('Merchant'),
$is_invoices ? pht('Invoice') : pht('Order'),
pht('Purchase'),
pht('Amount'),
pht('Status'),
pht('Updated'),
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 15:08:34 +01:00
pht('Invoice Date'),
null,
))
->setColumnClasses(
array(
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 15:08:34 +01:00
'',
'',
'',
'wide',
'right',
'',
'right',
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 15:08:34 +01:00
'right',
'action',
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 15:08:34 +01:00
))
->setColumnVisibility(
array(
true,
$is_invoices,
true,
true,
true,
!$is_invoices,
!$is_invoices,
$is_invoices,
// We show "Pay Now" for due invoices, but not if the viewer is the
// merchant, since it doesn't make sense for them to pay.
($is_invoices && !$is_merchant),
));
return $table;
}
}