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
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhortuneMerchantViewController
|
|
|
|
extends PhortuneMerchantController {
|
|
|
|
|
2015-08-01 15:43:47 -07:00
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$viewer = $request->getViewer();
|
|
|
|
$id = $request->getURIData('id');
|
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
|
|
|
|
|
|
|
$merchant = id(new PhortuneMerchantQuery())
|
|
|
|
->setViewer($viewer)
|
2015-08-01 15:43:47 -07:00
|
|
|
->withIDs(array($id))
|
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
|
|
|
->executeOne();
|
|
|
|
if (!$merchant) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
2014-10-07 14:41:41 -07:00
|
|
|
$crumbs->addTextCrumb($merchant->getName());
|
2016-03-23 11:03:30 -07:00
|
|
|
$crumbs->setBorder(true);
|
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
|
|
|
|
|
|
|
$title = pht(
|
|
|
|
'Merchant %d %s',
|
|
|
|
$merchant->getID(),
|
|
|
|
$merchant->getName());
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader($merchant->getName())
|
|
|
|
->setUser($viewer)
|
2016-03-23 11:03:30 -07:00
|
|
|
->setPolicyObject($merchant)
|
|
|
|
->setHeaderIcon('fa-bank');
|
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
|
|
|
|
2014-10-08 08:31:24 -07:00
|
|
|
$providers = id(new PhortunePaymentProviderConfigQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withMerchantPHIDs(array($merchant->getPHID()))
|
|
|
|
->execute();
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$details = $this->buildDetailsView($merchant, $providers);
|
|
|
|
$description = $this->buildDescriptionView($merchant);
|
|
|
|
$curtain = $this->buildCurtainView($merchant);
|
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
|
|
|
|
2014-10-08 08:31:24 -07:00
|
|
|
$provider_list = $this->buildProviderList(
|
|
|
|
$merchant,
|
|
|
|
$providers);
|
2014-10-07 14:41:41 -07:00
|
|
|
|
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
|
|
|
$timeline = $this->buildTransactionTimeline(
|
|
|
|
$merchant,
|
|
|
|
new PhortuneMerchantTransactionQuery());
|
|
|
|
$timeline->setShouldTerminate(true);
|
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
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$view = id(new PHUITwoColumnView())
|
|
|
|
->setHeader($header)
|
|
|
|
->setCurtain($curtain)
|
|
|
|
->setMainColumn(array(
|
|
|
|
$details,
|
|
|
|
$description,
|
2014-10-08 08:31:24 -07:00
|
|
|
$provider_list,
|
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
|
|
|
$timeline,
|
|
|
|
));
|
2016-03-23 11:03:30 -07:00
|
|
|
|
|
|
|
return $this->newPage()
|
|
|
|
->setTitle($title)
|
|
|
|
->setCrumbs($crumbs)
|
|
|
|
->appendChild($view);
|
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
|
|
|
}
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
private function buildDetailsView(
|
2014-10-08 08:31:24 -07:00
|
|
|
PhortuneMerchant $merchant,
|
|
|
|
array $providers) {
|
|
|
|
|
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
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
|
|
|
|
$view = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer)
|
|
|
|
->setObject($merchant);
|
|
|
|
|
2014-10-08 08:31:24 -07:00
|
|
|
$status_view = new PHUIStatusListView();
|
|
|
|
|
|
|
|
$have_any = false;
|
|
|
|
$any_test = false;
|
|
|
|
foreach ($providers as $provider_config) {
|
|
|
|
$provider = $provider_config->buildProvider();
|
|
|
|
if ($provider->isEnabled()) {
|
|
|
|
$have_any = true;
|
|
|
|
}
|
|
|
|
if (!$provider->isAcceptingLivePayments()) {
|
|
|
|
$any_test = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($have_any) {
|
|
|
|
$status_view->addItem(
|
|
|
|
id(new PHUIStatusItemView())
|
|
|
|
->setIcon(PHUIStatusItemView::ICON_ACCEPT, 'green')
|
|
|
|
->setTarget(pht('Accepts Payments'))
|
|
|
|
->setNote(pht('This merchant can accept payments.')));
|
|
|
|
|
|
|
|
if ($any_test) {
|
|
|
|
$status_view->addItem(
|
|
|
|
id(new PHUIStatusItemView())
|
|
|
|
->setIcon(PHUIStatusItemView::ICON_WARNING, 'yellow')
|
|
|
|
->setTarget(pht('Test Mode'))
|
|
|
|
->setNote(pht('This merchant is accepting test payments.')));
|
|
|
|
} else {
|
|
|
|
$status_view->addItem(
|
|
|
|
id(new PHUIStatusItemView())
|
|
|
|
->setIcon(PHUIStatusItemView::ICON_ACCEPT, 'green')
|
|
|
|
->setTarget(pht('Live Mode'))
|
|
|
|
->setNote(pht('This merchant is accepting live payments.')));
|
|
|
|
}
|
|
|
|
} else if ($providers) {
|
|
|
|
$status_view->addItem(
|
|
|
|
id(new PHUIStatusItemView())
|
|
|
|
->setIcon(PHUIStatusItemView::ICON_REJECT, 'red')
|
|
|
|
->setTarget(pht('No Enabled Providers'))
|
|
|
|
->setNote(
|
|
|
|
pht(
|
|
|
|
'All of the payment providers for this merchant are '.
|
|
|
|
'disabled.')));
|
|
|
|
} else {
|
|
|
|
$status_view->addItem(
|
|
|
|
id(new PHUIStatusItemView())
|
|
|
|
->setIcon(PHUIStatusItemView::ICON_WARNING, 'yellow')
|
|
|
|
->setTarget(pht('No Providers'))
|
|
|
|
->setNote(
|
|
|
|
pht(
|
|
|
|
'This merchant does not have any payment providers configured '.
|
|
|
|
'yet, so it can not accept payments. Add a provider.')));
|
|
|
|
}
|
|
|
|
|
|
|
|
$view->addProperty(pht('Status'), $status_view);
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
return id(new PHUIObjectBoxView())
|
2016-04-06 15:20:53 -07:00
|
|
|
->setHeaderText(pht('Details'))
|
2016-03-23 11:03:30 -07:00
|
|
|
->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
|
|
|
|
->appendChild($view);
|
|
|
|
}
|
2014-10-13 11:13:50 -07:00
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
private function buildDescriptionView(PhortuneMerchant $merchant) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
$view = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer);
|
2014-10-08 08:31:24 -07:00
|
|
|
|
|
|
|
$description = $merchant->getDescription();
|
|
|
|
if (strlen($description)) {
|
2016-02-16 13:52:12 -08:00
|
|
|
$description = new PHUIRemarkupView($viewer, $description);
|
2014-10-08 08:31:24 -07:00
|
|
|
$view->addTextContent($description);
|
2016-03-23 11:03:30 -07:00
|
|
|
return id(new PHUIObjectBoxView())
|
2016-04-06 15:20:53 -07:00
|
|
|
->setHeaderText(pht('Description'))
|
2016-03-23 11:03:30 -07:00
|
|
|
->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
|
|
|
|
->appendChild($view);
|
2014-10-08 08:31:24 -07:00
|
|
|
}
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
return null;
|
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
|
|
|
}
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
private function buildCurtainView(PhortuneMerchant $merchant) {
|
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
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
$id = $merchant->getID();
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$merchant,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$curtain = $this->newCurtainView($merchant);
|
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
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$curtain->addAction(
|
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
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Edit Merchant'))
|
|
|
|
->setIcon('fa-pencil')
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit)
|
|
|
|
->setHref($this->getApplicationURI("merchant/edit/{$id}/")));
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$curtain->addAction(
|
2014-10-08 14:40:02 -07:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('View Orders'))
|
|
|
|
->setIcon('fa-shopping-cart')
|
|
|
|
->setHref($this->getApplicationURI("merchant/orders/{$id}/"))
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit));
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$curtain->addAction(
|
2015-01-27 14:50:20 -08:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('View Subscriptions'))
|
|
|
|
->setIcon('fa-moon-o')
|
2015-01-30 11:28:49 -08:00
|
|
|
->setHref($this->getApplicationURI("merchant/{$id}/subscription/"))
|
2015-01-27 14:50:20 -08:00
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit));
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$curtain->addAction(
|
2015-04-20 10:05:22 -07:00
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('New Invoice'))
|
|
|
|
->setIcon('fa-fax')
|
|
|
|
->setHref($this->getApplicationURI("merchant/{$id}/invoice/new/"))
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit));
|
|
|
|
|
2016-03-23 11:03:30 -07:00
|
|
|
$member_phids = $merchant->getMemberPHIDs();
|
|
|
|
$handles = $viewer->loadHandles($member_phids);
|
|
|
|
|
|
|
|
$member_list = id(new PHUIObjectItemListView())
|
|
|
|
->setSimple(true);
|
|
|
|
|
|
|
|
foreach ($member_phids as $member_phid) {
|
|
|
|
$image_uri = $handles[$member_phid]->getImageURI();
|
|
|
|
$image_href = $handles[$member_phid]->getURI();
|
|
|
|
$person = $handles[$member_phid];
|
|
|
|
|
|
|
|
$member = id(new PHUIObjectItemView())
|
|
|
|
->setImageURI($image_uri)
|
|
|
|
->setHref($image_href)
|
|
|
|
->setHeader($person->getFullName());
|
|
|
|
|
|
|
|
$member_list->addItem($member);
|
|
|
|
}
|
|
|
|
|
|
|
|
$curtain->newPanel()
|
|
|
|
->setHeaderText(pht('Members'))
|
|
|
|
->appendChild($member_list);
|
|
|
|
|
|
|
|
return $curtain;
|
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
|
|
|
}
|
|
|
|
|
2014-10-08 08:31:24 -07:00
|
|
|
private function buildProviderList(
|
|
|
|
PhortuneMerchant $merchant,
|
|
|
|
array $providers) {
|
|
|
|
|
2014-10-07 14:41:41 -07:00
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
$id = $merchant->getID();
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$merchant,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
|
|
$provider_list = id(new PHUIObjectItemListView())
|
2015-03-26 13:16:09 -07:00
|
|
|
->setFlush(true)
|
2014-10-07 14:41:41 -07:00
|
|
|
->setNoDataString(pht('This merchant has no payment providers.'));
|
|
|
|
|
|
|
|
foreach ($providers as $provider_config) {
|
|
|
|
$provider = $provider_config->buildProvider();
|
|
|
|
$provider_id = $provider_config->getID();
|
|
|
|
|
|
|
|
$item = id(new PHUIObjectItemView())
|
|
|
|
->setHeader($provider->getName());
|
|
|
|
|
2014-10-08 08:31:24 -07:00
|
|
|
if ($provider->isEnabled()) {
|
|
|
|
if ($provider->isAcceptingLivePayments()) {
|
2015-05-28 15:17:34 -07:00
|
|
|
$item->setStatusIcon('fa-check green');
|
2014-10-08 08:31:24 -07:00
|
|
|
} else {
|
2015-05-28 15:17:34 -07:00
|
|
|
$item->setStatusIcon('fa-warning yellow');
|
2014-10-08 08:31:24 -07:00
|
|
|
$item->addIcon('fa-exclamation-triangle', pht('Test Mode'));
|
|
|
|
}
|
|
|
|
|
|
|
|
$item->addAttribute($provider->getConfigureProvidesDescription());
|
|
|
|
} else {
|
|
|
|
// Don't show disabled providers to users who can't manage the merchant
|
|
|
|
// account.
|
|
|
|
if (!$can_edit) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
$item->setDisabled(true);
|
|
|
|
$item->addAttribute(
|
|
|
|
phutil_tag('em', array(), pht('This payment provider is disabled.')));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
if ($can_edit) {
|
|
|
|
$edit_uri = $this->getApplicationURI(
|
|
|
|
"/provider/edit/{$provider_id}/");
|
|
|
|
$disable_uri = $this->getApplicationURI(
|
|
|
|
"/provider/disable/{$provider_id}/");
|
|
|
|
|
|
|
|
if ($provider->isEnabled()) {
|
|
|
|
$disable_icon = 'fa-times';
|
|
|
|
$disable_name = pht('Disable');
|
|
|
|
} else {
|
|
|
|
$disable_icon = 'fa-check';
|
|
|
|
$disable_name = pht('Enable');
|
|
|
|
}
|
|
|
|
|
|
|
|
$item->addAction(
|
|
|
|
id(new PHUIListItemView())
|
|
|
|
->setIcon($disable_icon)
|
|
|
|
->setHref($disable_uri)
|
|
|
|
->setName($disable_name)
|
|
|
|
->setWorkflow(true));
|
|
|
|
|
|
|
|
$item->addAction(
|
|
|
|
id(new PHUIListItemView())
|
|
|
|
->setIcon('fa-pencil')
|
|
|
|
->setHref($edit_uri)
|
|
|
|
->setName(pht('Edit')));
|
|
|
|
}
|
2014-10-07 14:41:41 -07:00
|
|
|
|
|
|
|
$provider_list->addItem($item);
|
|
|
|
}
|
|
|
|
|
|
|
|
$add_action = id(new PHUIButtonView())
|
|
|
|
->setTag('a')
|
|
|
|
->setHref($this->getApplicationURI('provider/edit/?merchantID='.$id))
|
|
|
|
->setText(pht('Add Payment Provider'))
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit)
|
2016-01-27 20:38:01 -08:00
|
|
|
->setIcon('fa-plus');
|
2014-10-07 14:41:41 -07:00
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Payment Providers'))
|
|
|
|
->addActionLink($add_action);
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
2016-03-23 11:03:30 -07:00
|
|
|
->setBackground(PHUIObjectBoxView::BLUE_PROPERTY)
|
[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:43:34 -07:00
|
|
|
->setObjectList($provider_list);
|
2014-10-07 14:41:41 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
}
|