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 19:55:16 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhortuneMerchantViewController
|
|
|
|
extends PhortuneMerchantController {
|
|
|
|
|
|
|
|
private $id;
|
|
|
|
|
|
|
|
public function willProcessRequest(array $data) {
|
|
|
|
$this->id = $data['id'];
|
|
|
|
}
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$viewer = $request->getUser();
|
|
|
|
|
|
|
|
$merchant = id(new PhortuneMerchantQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withIDs(array($this->id))
|
|
|
|
->executeOne();
|
|
|
|
if (!$merchant) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
2014-10-07 23:41:41 +02:00
|
|
|
$crumbs->addTextCrumb($merchant->getName());
|
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 19:55:16 +02:00
|
|
|
|
|
|
|
$title = pht(
|
|
|
|
'Merchant %d %s',
|
|
|
|
$merchant->getID(),
|
|
|
|
$merchant->getName());
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setObjectName(pht('Merchant %d', $merchant->getID()))
|
|
|
|
->setHeader($merchant->getName())
|
|
|
|
->setUser($viewer)
|
|
|
|
->setPolicyObject($merchant);
|
|
|
|
|
|
|
|
$properties = $this->buildPropertyListView($merchant);
|
|
|
|
$actions = $this->buildActionListView($merchant);
|
|
|
|
$properties->setActionList($actions);
|
|
|
|
|
2014-10-07 23:41:41 +02:00
|
|
|
$providers = $this->buildProviderList($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 19:55:16 +02:00
|
|
|
$box = id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
|
|
|
->appendChild($properties);
|
|
|
|
|
|
|
|
$xactions = id(new PhortuneMerchantTransactionQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withObjectPHIDs(array($merchant->getPHID()))
|
|
|
|
->execute();
|
|
|
|
|
|
|
|
$timeline = id(new PhabricatorApplicationTransactionView())
|
|
|
|
->setUser($viewer)
|
|
|
|
->setObjectPHID($merchant->getPHID())
|
|
|
|
->setTransactions($xactions);
|
|
|
|
|
|
|
|
return $this->buildApplicationPage(
|
|
|
|
array(
|
|
|
|
$crumbs,
|
|
|
|
$box,
|
2014-10-07 23:41:41 +02:00
|
|
|
$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 19:55:16 +02:00
|
|
|
$timeline,
|
|
|
|
),
|
|
|
|
array(
|
|
|
|
'title' => $title,
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildPropertyListView(PhortuneMerchant $merchant) {
|
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
|
|
|
|
$view = id(new PHUIPropertyListView())
|
|
|
|
->setUser($viewer)
|
|
|
|
->setObject($merchant);
|
|
|
|
|
|
|
|
return $view;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildActionListView(PhortuneMerchant $merchant) {
|
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
$id = $merchant->getID();
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$merchant,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
|
|
$view = id(new PhabricatorActionListView())
|
|
|
|
->setUser($viewer)
|
|
|
|
->setObject($merchant);
|
|
|
|
|
|
|
|
$view->addAction(
|
|
|
|
id(new PhabricatorActionView())
|
|
|
|
->setName(pht('Edit Merchant'))
|
|
|
|
->setIcon('fa-pencil')
|
|
|
|
->setDisabled(!$can_edit)
|
|
|
|
->setWorkflow(!$can_edit)
|
|
|
|
->setHref($this->getApplicationURI("merchant/edit/{$id}/")));
|
|
|
|
|
|
|
|
return $view;
|
|
|
|
}
|
|
|
|
|
2014-10-07 23:41:41 +02:00
|
|
|
private function buildProviderList(PhortuneMerchant $merchant) {
|
|
|
|
$viewer = $this->getRequest()->getUser();
|
|
|
|
$id = $merchant->getID();
|
|
|
|
|
|
|
|
$can_edit = PhabricatorPolicyFilter::hasCapability(
|
|
|
|
$viewer,
|
|
|
|
$merchant,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT);
|
|
|
|
|
|
|
|
$provider_list = id(new PHUIObjectItemListView())
|
|
|
|
->setNoDataString(pht('This merchant has no payment providers.'));
|
|
|
|
|
|
|
|
$providers = id(new PhortunePaymentProviderConfigQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withMerchantPHIDs(array($merchant->getPHID()))
|
|
|
|
->execute();
|
|
|
|
foreach ($providers as $provider_config) {
|
|
|
|
$provider = $provider_config->buildProvider();
|
|
|
|
$provider_id = $provider_config->getID();
|
|
|
|
|
|
|
|
$item = id(new PHUIObjectItemView())
|
|
|
|
->setObjectName(pht('Provider %d', $provider_id))
|
|
|
|
->setHeader($provider->getName());
|
|
|
|
|
|
|
|
$item->addAction(
|
|
|
|
id(new PHUIListItemView())
|
|
|
|
->setIcon('fa-pencil')
|
|
|
|
->setHref($this->getApplicationURI("/provider/edit/{$provider_id}"))
|
|
|
|
->setWorkflow(!$can_edit)
|
|
|
|
->setDisabled(!$can_edit));
|
|
|
|
|
|
|
|
$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)
|
|
|
|
->setIcon(id(new PHUIIconView())->setIconFont('fa-plus'));
|
|
|
|
|
|
|
|
$header = id(new PHUIHeaderView())
|
|
|
|
->setHeader(pht('Payment Providers'))
|
|
|
|
->addActionLink($add_action);
|
|
|
|
|
|
|
|
return id(new PHUIObjectBoxView())
|
|
|
|
->setHeader($header)
|
|
|
|
->appendChild($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 19:55:16 +02:00
|
|
|
}
|