Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class FundInitiativeEditor
|
|
|
|
extends PhabricatorApplicationTransactionEditor {
|
|
|
|
|
|
|
|
public function getEditorApplicationClass() {
|
|
|
|
return 'PhabricatorFundApplication';
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getEditorObjectsDescription() {
|
|
|
|
return pht('Fund Initiatives');
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getTransactionTypes() {
|
|
|
|
$types = parent::getTransactionTypes();
|
|
|
|
|
|
|
|
$types[] = FundInitiativeTransaction::TYPE_NAME;
|
|
|
|
$types[] = FundInitiativeTransaction::TYPE_DESCRIPTION;
|
2014-10-08 14:32:42 +02:00
|
|
|
$types[] = FundInitiativeTransaction::TYPE_RISKS;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
$types[] = FundInitiativeTransaction::TYPE_STATUS;
|
2014-10-06 19:36:43 +02:00
|
|
|
$types[] = FundInitiativeTransaction::TYPE_BACKER;
|
2014-10-10 20:29:31 +02:00
|
|
|
$types[] = FundInitiativeTransaction::TYPE_REFUND;
|
2014-10-07 23:41:59 +02:00
|
|
|
$types[] = FundInitiativeTransaction::TYPE_MERCHANT;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
$types[] = PhabricatorTransactions::TYPE_VIEW_POLICY;
|
|
|
|
$types[] = PhabricatorTransactions::TYPE_EDIT_POLICY;
|
|
|
|
|
|
|
|
return $types;
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getCustomTransactionOldValue(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
PhabricatorApplicationTransaction $xaction) {
|
|
|
|
switch ($xaction->getTransactionType()) {
|
|
|
|
case FundInitiativeTransaction::TYPE_NAME:
|
|
|
|
return $object->getName();
|
|
|
|
case FundInitiativeTransaction::TYPE_DESCRIPTION:
|
|
|
|
return $object->getDescription();
|
2014-10-08 14:32:42 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_RISKS:
|
|
|
|
return $object->getRisks();
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_STATUS:
|
|
|
|
return $object->getStatus();
|
2014-10-06 19:36:43 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_BACKER:
|
2014-10-10 20:29:31 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_REFUND:
|
2014-10-06 19:36:43 +02:00
|
|
|
return null;
|
2014-10-07 23:41:59 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_MERCHANT:
|
|
|
|
return $object->getMerchantPHID();
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return parent::getCustomTransactionOldValue($object, $xaction);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getCustomTransactionNewValue(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
PhabricatorApplicationTransaction $xaction) {
|
|
|
|
|
|
|
|
switch ($xaction->getTransactionType()) {
|
|
|
|
case FundInitiativeTransaction::TYPE_NAME:
|
|
|
|
case FundInitiativeTransaction::TYPE_DESCRIPTION:
|
2014-10-08 14:32:42 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_RISKS:
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_STATUS:
|
2014-10-06 19:36:43 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_BACKER:
|
2014-10-10 20:29:31 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_REFUND:
|
2014-10-07 23:41:59 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_MERCHANT:
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
return $xaction->getNewValue();
|
|
|
|
}
|
|
|
|
|
|
|
|
return parent::getCustomTransactionNewValue($object, $xaction);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function applyCustomInternalTransaction(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
PhabricatorApplicationTransaction $xaction) {
|
|
|
|
|
2014-10-10 20:29:31 +02:00
|
|
|
$type = $xaction->getTransactionType();
|
|
|
|
switch ($type) {
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_NAME:
|
|
|
|
$object->setName($xaction->getNewValue());
|
|
|
|
return;
|
|
|
|
case FundInitiativeTransaction::TYPE_DESCRIPTION:
|
|
|
|
$object->setDescription($xaction->getNewValue());
|
|
|
|
return;
|
2014-10-08 14:32:42 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_RISKS:
|
|
|
|
$object->setRisks($xaction->getNewValue());
|
|
|
|
return;
|
2014-10-07 23:41:59 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_MERCHANT:
|
|
|
|
$object->setMerchantPHID($xaction->getNewValue());
|
|
|
|
return;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_STATUS:
|
|
|
|
$object->setStatus($xaction->getNewValue());
|
|
|
|
return;
|
2014-10-06 19:36:43 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_BACKER:
|
2014-10-10 20:29:31 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_REFUND:
|
|
|
|
$amount = $xaction->getMetadataValue(
|
|
|
|
FundInitiativeTransaction::PROPERTY_AMOUNT);
|
|
|
|
$amount = PhortuneCurrency::newFromString($amount);
|
|
|
|
|
|
|
|
if ($type == FundInitiativeTransaction::TYPE_REFUND) {
|
|
|
|
$total = $object->getTotalAsCurrency()->subtract($amount);
|
|
|
|
} else {
|
|
|
|
$total = $object->getTotalAsCurrency()->add($amount);
|
2014-10-08 14:31:48 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$object->setTotalAsCurrency($total);
|
2014-10-06 19:36:43 +02:00
|
|
|
return;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case PhabricatorTransactions::TYPE_SUBSCRIBERS:
|
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
return parent::applyCustomInternalTransaction($object, $xaction);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function applyCustomExternalTransaction(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
PhabricatorApplicationTransaction $xaction) {
|
|
|
|
|
2014-10-10 20:29:31 +02:00
|
|
|
$type = $xaction->getTransactionType();
|
|
|
|
switch ($type) {
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_NAME:
|
|
|
|
case FundInitiativeTransaction::TYPE_DESCRIPTION:
|
2014-10-08 14:32:42 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_RISKS:
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_STATUS:
|
2014-10-07 23:41:59 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_MERCHANT:
|
2014-10-10 20:29:31 +02:00
|
|
|
return;
|
2014-10-06 19:36:43 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_BACKER:
|
2014-10-10 20:29:31 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_REFUND:
|
|
|
|
$backer = id(new FundBackerQuery())
|
|
|
|
->setViewer($this->requireActor())
|
|
|
|
->withPHIDs(array($xaction->getNewValue()))
|
|
|
|
->executeOne();
|
|
|
|
if (!$backer) {
|
|
|
|
throw new Exception(pht('Unable to load FundBacker!'));
|
|
|
|
}
|
|
|
|
|
|
|
|
$subx = array();
|
|
|
|
|
|
|
|
if ($type == FundInitiativeTransaction::TYPE_BACKER) {
|
|
|
|
$subx[] = id(new FundBackerTransaction())
|
|
|
|
->setTransactionType(FundBackerTransaction::TYPE_STATUS)
|
|
|
|
->setNewValue(FundBacker::STATUS_PURCHASED);
|
|
|
|
} else {
|
|
|
|
$amount = $xaction->getMetadataValue(
|
|
|
|
FundInitiativeTransaction::PROPERTY_AMOUNT);
|
|
|
|
$subx[] = id(new FundBackerTransaction())
|
|
|
|
->setTransactionType(FundBackerTransaction::TYPE_STATUS)
|
|
|
|
->setNewValue($amount);
|
|
|
|
}
|
|
|
|
|
|
|
|
$editor = id(new FundBackerEditor())
|
|
|
|
->setActor($this->requireActor())
|
|
|
|
->setContentSource($this->getContentSource())
|
|
|
|
->setContinueOnMissingFields(true)
|
|
|
|
->setContinueOnNoEffect(true);
|
|
|
|
|
|
|
|
$editor->applyTransactions($backer, $subx);
|
2014-10-06 19:36:43 +02:00
|
|
|
return;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
case PhabricatorTransactions::TYPE_SUBSCRIBERS:
|
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
return parent::applyCustomExternalTransaction($object, $xaction);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function validateTransaction(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
$type,
|
|
|
|
array $xactions) {
|
|
|
|
|
|
|
|
$errors = parent::validateTransaction($object, $type, $xactions);
|
|
|
|
|
|
|
|
switch ($type) {
|
|
|
|
case FundInitiativeTransaction::TYPE_NAME:
|
|
|
|
$missing = $this->validateIsEmptyTextField(
|
|
|
|
$object->getName(),
|
|
|
|
$xactions);
|
|
|
|
|
|
|
|
if ($missing) {
|
|
|
|
$error = new PhabricatorApplicationTransactionValidationError(
|
|
|
|
$type,
|
|
|
|
pht('Required'),
|
|
|
|
pht('Initiative name is required.'),
|
|
|
|
nonempty(last($xactions), null));
|
|
|
|
|
|
|
|
$error->setIsMissingFieldError(true);
|
|
|
|
$errors[] = $error;
|
|
|
|
}
|
|
|
|
break;
|
2014-10-07 23:41:59 +02:00
|
|
|
case FundInitiativeTransaction::TYPE_MERCHANT:
|
|
|
|
$missing = $this->validateIsEmptyTextField(
|
|
|
|
$object->getName(),
|
|
|
|
$xactions);
|
|
|
|
if ($missing) {
|
|
|
|
$error = new PhabricatorApplicationTransactionValidationError(
|
|
|
|
$type,
|
|
|
|
pht('Required'),
|
|
|
|
pht('Payable merchant is required.'),
|
|
|
|
nonempty(last($xactions), null));
|
|
|
|
|
|
|
|
$error->setIsMissingFieldError(true);
|
|
|
|
$errors[] = $error;
|
|
|
|
} else if ($xactions) {
|
|
|
|
$merchant_phid = last($xactions)->getNewValue();
|
|
|
|
|
|
|
|
// Make sure the actor has permission to edit the merchant they're
|
|
|
|
// selecting. You aren't allowed to send payments to an account you
|
|
|
|
// do not control.
|
|
|
|
$merchants = id(new PhortuneMerchantQuery())
|
|
|
|
->setViewer($this->requireActor())
|
|
|
|
->withPHIDs(array($merchant_phid))
|
|
|
|
->requireCapabilities(
|
|
|
|
array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
))
|
|
|
|
->execute();
|
|
|
|
if (!$merchants) {
|
|
|
|
$error = new PhabricatorApplicationTransactionValidationError(
|
|
|
|
$type,
|
|
|
|
pht('Invalid'),
|
|
|
|
pht(
|
|
|
|
'You must specify a merchant account you control as the '.
|
|
|
|
'recipient of funds from this initiative.'),
|
|
|
|
last($xactions));
|
|
|
|
$errors[] = $error;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
break;
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return $errors;
|
|
|
|
}
|
|
|
|
|
2014-10-10 20:29:42 +02:00
|
|
|
protected function shouldSendMail(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
array $xactions) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getMailTagsMap() {
|
|
|
|
return array(
|
|
|
|
FundInitiativeTransaction::MAILTAG_BACKER =>
|
|
|
|
pht('Someone backs an initiative.'),
|
|
|
|
FundInitiativeTransaction::MAILTAG_STATUS =>
|
|
|
|
pht("An initiative's status changes."),
|
|
|
|
FundInitiativeTransaction::MAILTAG_OTHER =>
|
|
|
|
pht('Other initiative activity not listed above occurs.'),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function buildMailTemplate(PhabricatorLiskDAO $object) {
|
|
|
|
$monogram = $object->getMonogram();
|
|
|
|
$name = $object->getName();
|
|
|
|
|
|
|
|
return id(new PhabricatorMetaMTAMail())
|
|
|
|
->setSubject("{$monogram}: {$name}")
|
|
|
|
->addHeader('Thread-Topic', $monogram);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
protected function getMailTo(PhabricatorLiskDAO $object) {
|
|
|
|
return array($object->getOwnerPHID());
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function getMailSubjectPrefix() {
|
|
|
|
return 'Fund';
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function buildReplyHandler(PhabricatorLiskDAO $object) {
|
|
|
|
return id(new FundInitiativeReplyHandler())
|
|
|
|
->setMailReceiver($object);
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function shouldPublishFeedStory(
|
|
|
|
PhabricatorLiskDAO $object,
|
|
|
|
array $xactions) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-10-13 20:14:02 +02:00
|
|
|
protected function supportsSearch() {
|
|
|
|
return true;
|
|
|
|
}
|
Scaffolding for Fund
Summary:
Ref T5835. This is all pretty boilerplate, and does not interact with Phortune at all yet.
You can create "Initiatives", which have a title and description, and support most of the expected infrastructure (policies, transactions, mentions, edges, appsearch, remakrup, etc).
Only notable decisions:
- Initiatives have an explicit owner. I think it's good to have a single clearly-responsible user behind an initiative.
- I think that's it?
Test Plan:
- Created an initiative.
- Edited an initiative.
- Changed application policy defaults.
- Searched for initiatives.
- Subscribed to an initiative.
- Opened/closed an initiative.
- Used `I123` and `{I123}` in remarkup.
- Destroyed an initiative.
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T5835
Differential Revision: https://secure.phabricator.com/D10481
2014-09-11 22:38:58 +02:00
|
|
|
|
|
|
|
}
|