1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 08:12:40 +01:00
phorge-phorge/src/applications/phortune/controller/PhortuneMerchantEditController.php

180 lines
5.3 KiB
PHP
Raw Normal View History

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 PhortuneMerchantEditController
extends PhortuneMerchantController {
private $id;
public function willProcessRequest(array $data) {
$this->id = idx($data, 'id');
}
public function processRequest() {
$request = $this->getRequest();
$viewer = $request->getUser();
if ($this->id) {
$merchant = id(new PhortuneMerchantQuery())
->setViewer($viewer)
->withIDs(array($this->id))
->requireCapabilities(
array(
PhabricatorPolicyCapability::CAN_VIEW,
PhabricatorPolicyCapability::CAN_EDIT,
))
->executeOne();
if (!$merchant) {
return new Aphront404Response();
}
$is_new = false;
} else {
$this->requireApplicationCapability(
PhortuneMerchantCapability::CAPABILITY);
$merchant = PhortuneMerchant::initializeNewMerchant($viewer);
$merchant->attachMemberPHIDs(array($viewer->getPHID()));
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
$is_new = true;
}
if ($is_new) {
$title = pht('Create Merchant');
$button_text = pht('Create Merchant');
$cancel_uri = $this->getApplicationURI('merchant/');
} else {
$title = pht(
'Edit Merchant %d %s',
$merchant->getID(),
$merchant->getName());
$button_text = pht('Save Changes');
$cancel_uri = $this->getApplicationURI(
'/merchant/'.$merchant->getID().'/');
}
$e_name = true;
$v_name = $merchant->getName();
$v_desc = $merchant->getDescription();
$v_members = $merchant->getMemberPHIDs();
$e_members = 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 19:55:16 +02:00
$validation_exception = null;
if ($request->isFormPost()) {
$v_name = $request->getStr('name');
$v_desc = $request->getStr('desc');
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
$v_view = $request->getStr('viewPolicy');
$v_edit = $request->getStr('editPolicy');
$v_members = $request->getArr('memberPHIDs');
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
$type_name = PhortuneMerchantTransaction::TYPE_NAME;
$type_desc = PhortuneMerchantTransaction::TYPE_DESCRIPTION;
$type_edge = PhabricatorTransactions::TYPE_EDGE;
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
$type_view = PhabricatorTransactions::TYPE_VIEW_POLICY;
$edge_members = PhortuneMerchantHasMemberEdgeType::EDGECONST;
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
$xactions = array();
$xactions[] = id(new PhortuneMerchantTransaction())
->setTransactionType($type_name)
->setNewValue($v_name);
$xactions[] = id(new PhortuneMerchantTransaction())
->setTransactionType($type_desc)
->setNewValue($v_desc);
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
$xactions[] = id(new PhortuneMerchantTransaction())
->setTransactionType($type_view)
->setNewValue($v_view);
$xactions[] = id(new PhortuneMerchantTransaction())
->setTransactionType($type_edge)
->setMetadataValue('edge:type', $edge_members)
->setNewValue(
array(
'=' => array_fuse($v_members),
));
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
$editor = id(new PhortuneMerchantEditor())
->setActor($viewer)
->setContentSourceFromRequest($request)
->setContinueOnNoEffect(true);
try {
$editor->applyTransactions($merchant, $xactions);
$id = $merchant->getID();
$merchant_uri = $this->getApplicationURI("merchant/{$id}/");
return id(new AphrontRedirectResponse())->setURI($merchant_uri);
} catch (PhabricatorApplicationTransactionValidationException $ex) {
$validation_exception = $ex;
$e_name = $ex->getShortMessage($type_name);
$e_mbmers = $ex->getShortMessage($type_edge);
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
$merchant->setViewPolicy($v_view);
}
}
$policies = id(new PhabricatorPolicyQuery())
->setViewer($viewer)
->setObject($merchant)
->execute();
$form = id(new AphrontFormView())
->setUser($viewer)
->appendChild(
id(new AphrontFormTextControl())
->setName('name')
->setLabel(pht('Name'))
->setValue($v_name)
->setError($e_name))
->appendChild(
id(new PhabricatorRemarkupControl())
->setUser($viewer)
->setName('desc')
->setLabel(pht('Description'))
->setValue($v_desc))
Convert all tokenizers to take token/scalar inputs Summary: Ref T7689. Ref T4100. This advances the goals of removing `loadViewerHandles()` (only 67 callsites remain!) and letting tokenizers some day take token functions like `viewer()` and `members(differential)`. Test Plan: - Sent a new message; used "To". - I simplified the cancel URI construction slightly because it's moot in all normal cases. - Edited a thread; used "Add Participants". - Searched rooms; used "Participants". - Searched countdowns; used "Authors". - Created a diff; used "Repository". - Edited a revision; edited "Projects"; edited "Reveiwers"; edited "Subscribers". - Searched for revisions; edited "responsible users"; "authors"; "reviwers"; "subscribers"; "repositories". - Added revision comments; edited "Add Reveiwers"; "Add Subscribers". - Commented on a commit; edited "Add Auditors"; "Add subscribers". - Edited a commit; edited "Projects". - Edited a repository; edited "Projects". - Searched feed, used "include Users"; "include Proejcts". - Searched files, used "authors". - Edited initiative; edited "Projects". - Searched backers; used "Backers". - Searched initiatives; used "Owners". - Edited build plans; edited "Run Command". - Searched Herald; used "Authors". - Added signature exemption in Legalpad. - Searhced legalpad; used "creators"; used "contributors". - Searched signatures; used "documents"; used "signers". - Created meme. - Searched macros; used "Authors". - Used "Projects" in Maniphest reports. - Used Maniphest comment actions. - Edited Maniphest tasks; edited "Assigned To"; edited "CC"; edited "projects". - Used "parent" in Maniphest task creation workflow. - Searched for projects; used "assigned to"; "in any projec"; "in all projects"; "not in projects"; "in users' projects"; "authors"; "subscribers". - Edited Maniphest bug filing domains, used "Default Author". - Searched for OAuth applications, used "Creators". - Edited Owners pacakge; edited "Primary Owner"; edited "Owners". - Searched for Owners packages; used "Owner". - OMG this UI is OLD - Edited a paste; edited "Projects". - Searched for paste; used "Authors". - Searched user activity log; used "Actors"; used "Users". - Edited a mock; edited "Projects"; edited "CC". - Searched for mocks; used "Authors". - Edited Phortune account; edited "Members". - Edited Phortune merchant account; edited "Members". - Searched Phrequent; used "Users". - Edited Ponder question; sued "projects". - Searched Ponder; used "Authors"; used "Answered By". - Added project members. - Searched for projects; used "Members". - Edited a Releeph product; edited "Pushers". - Searched pull requests; searched "Requestors". - Edited an arcanist project; used "Uses Symbols From". - Searhced push logs; used "Repositories"; used "Pushers". - Searched repositories; used "In nay project". - Used global search; used Authors/owners/Subscribers/In Any Project. - Edited a slowvote; used "Projects". - Searched slovotes; used "Authors". - Created a custom "Users" field; edited and searched for it. - Made a whole lot of typos in this list. ^^^^^^ Did not test: - Lint is nontrivial to test locally, I'll test it in production. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T7689 Differential Revision: https://secure.phabricator.com/D12224
2015-03-31 23:10:55 +02:00
->appendControl(
id(new AphrontFormTokenizerControl())
->setDatasource(new PhabricatorPeopleDatasource())
->setLabel(pht('Members'))
->setName('memberPHIDs')
Convert all tokenizers to take token/scalar inputs Summary: Ref T7689. Ref T4100. This advances the goals of removing `loadViewerHandles()` (only 67 callsites remain!) and letting tokenizers some day take token functions like `viewer()` and `members(differential)`. Test Plan: - Sent a new message; used "To". - I simplified the cancel URI construction slightly because it's moot in all normal cases. - Edited a thread; used "Add Participants". - Searched rooms; used "Participants". - Searched countdowns; used "Authors". - Created a diff; used "Repository". - Edited a revision; edited "Projects"; edited "Reveiwers"; edited "Subscribers". - Searched for revisions; edited "responsible users"; "authors"; "reviwers"; "subscribers"; "repositories". - Added revision comments; edited "Add Reveiwers"; "Add Subscribers". - Commented on a commit; edited "Add Auditors"; "Add subscribers". - Edited a commit; edited "Projects". - Edited a repository; edited "Projects". - Searched feed, used "include Users"; "include Proejcts". - Searched files, used "authors". - Edited initiative; edited "Projects". - Searched backers; used "Backers". - Searched initiatives; used "Owners". - Edited build plans; edited "Run Command". - Searched Herald; used "Authors". - Added signature exemption in Legalpad. - Searhced legalpad; used "creators"; used "contributors". - Searched signatures; used "documents"; used "signers". - Created meme. - Searched macros; used "Authors". - Used "Projects" in Maniphest reports. - Used Maniphest comment actions. - Edited Maniphest tasks; edited "Assigned To"; edited "CC"; edited "projects". - Used "parent" in Maniphest task creation workflow. - Searched for projects; used "assigned to"; "in any projec"; "in all projects"; "not in projects"; "in users' projects"; "authors"; "subscribers". - Edited Maniphest bug filing domains, used "Default Author". - Searched for OAuth applications, used "Creators". - Edited Owners pacakge; edited "Primary Owner"; edited "Owners". - Searched for Owners packages; used "Owner". - OMG this UI is OLD - Edited a paste; edited "Projects". - Searched for paste; used "Authors". - Searched user activity log; used "Actors"; used "Users". - Edited a mock; edited "Projects"; edited "CC". - Searched for mocks; used "Authors". - Edited Phortune account; edited "Members". - Edited Phortune merchant account; edited "Members". - Searched Phrequent; used "Users". - Edited Ponder question; sued "projects". - Searched Ponder; used "Authors"; used "Answered By". - Added project members. - Searched for projects; used "Members". - Edited a Releeph product; edited "Pushers". - Searched pull requests; searched "Requestors". - Edited an arcanist project; used "Uses Symbols From". - Searhced push logs; used "Repositories"; used "Pushers". - Searched repositories; used "In nay project". - Used global search; used Authors/owners/Subscribers/In Any Project. - Edited a slowvote; used "Projects". - Searched slovotes; used "Authors". - Created a custom "Users" field; edited and searched for it. - Made a whole lot of typos in this list. ^^^^^^ Did not test: - Lint is nontrivial to test locally, I'll test it in production. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4100, T7689 Differential Revision: https://secure.phabricator.com/D12224
2015-03-31 23:10:55 +02:00
->setValue($v_members)
->setError($e_members))
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
->appendChild(
id(new AphrontFormPolicyControl())
->setName('viewPolicy')
->setPolicyObject($merchant)
->setCapability(PhabricatorPolicyCapability::CAN_VIEW)
->setPolicies($policies))
->appendChild(
id(new AphrontFormSubmitControl())
->setValue($button_text)
->addCancelButton($cancel_uri));
$crumbs = $this->buildApplicationCrumbs();
if ($is_new) {
$crumbs->addTextCrumb(pht('Create Merchant'));
} else {
$crumbs->addTextCrumb(
pht('Merchant %d', $merchant->getID()),
$this->getApplicationURI('/merchant/'.$merchant->getID().'/'));
$crumbs->addTextCrumb(pht('Edit'));
}
$box = id(new PHUIObjectBoxView())
->setValidationException($validation_exception)
->setHeaderText($title)
->appendChild($form);
return $this->buildApplicationPage(
array(
$crumbs,
$box,
),
array(
'title' => $title,
));
}
}