2012-02-27 13:00:23 -08:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class PhabricatorAuditPreviewController
|
|
|
|
extends PhabricatorAuditController {
|
|
|
|
|
|
|
|
private $id;
|
|
|
|
|
|
|
|
public function willProcessRequest(array $data) {
|
|
|
|
$this->id = $data['id'];
|
|
|
|
}
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$user = $request->getUser();
|
|
|
|
|
|
|
|
$commit = id(new PhabricatorRepositoryCommit())->load($this->id);
|
|
|
|
if (!$commit) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
|
2012-04-23 13:50:04 -07:00
|
|
|
$action = $request->getStr('action');
|
|
|
|
|
|
|
|
$phids = array(
|
|
|
|
$user->getPHID(),
|
|
|
|
$commit->getPHID(),
|
|
|
|
);
|
|
|
|
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
$comments = array();
|
|
|
|
|
|
|
|
if ($action != PhabricatorAuditActionConstants::COMMENT) {
|
|
|
|
$action_comment = id(new PhabricatorAuditComment())
|
|
|
|
->setActorPHID($user->getPHID())
|
|
|
|
->setTargetPHID($commit->getPHID())
|
|
|
|
->setAction($action);
|
|
|
|
|
|
|
|
$auditors = $request->getStrList('auditors');
|
|
|
|
if ($action == PhabricatorAuditActionConstants::ADD_AUDITORS &&
|
|
|
|
$auditors) {
|
|
|
|
|
|
|
|
$action_comment->setMetadata(array(
|
|
|
|
PhabricatorAuditComment::METADATA_ADDED_AUDITORS => $auditors));
|
|
|
|
$phids = array_merge($phids, $auditors);
|
|
|
|
}
|
|
|
|
|
|
|
|
$ccs = $request->getStrList('ccs');
|
|
|
|
if ($action == PhabricatorAuditActionConstants::ADD_CCS && $ccs) {
|
|
|
|
$action_comment->setMetadata(array(
|
|
|
|
PhabricatorAuditComment::METADATA_ADDED_CCS => $ccs));
|
|
|
|
$phids = array_merge($phids, $ccs);
|
|
|
|
}
|
|
|
|
|
|
|
|
$comments[] = $action_comment;
|
2012-04-23 13:50:04 -07:00
|
|
|
}
|
|
|
|
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
$content = $request->getStr('content');
|
|
|
|
if (strlen($content)) {
|
|
|
|
$comments[] = id(new PhabricatorAuditComment())
|
|
|
|
->setActorPHID($user->getPHID())
|
|
|
|
->setTargetPHID($commit->getPHID())
|
|
|
|
->setAction(PhabricatorAuditActionConstants::COMMENT)
|
|
|
|
->setContent($content);
|
2012-04-23 13:50:04 -07:00
|
|
|
}
|
|
|
|
|
2012-10-23 17:46:44 -07:00
|
|
|
$engine = new PhabricatorMarkupEngine();
|
|
|
|
$engine->setViewer($user);
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
foreach ($comments as $comment) {
|
|
|
|
$engine->addObject(
|
|
|
|
$comment,
|
|
|
|
PhabricatorAuditComment::MARKUP_FIELD_BODY);
|
|
|
|
}
|
2012-10-23 17:46:44 -07:00
|
|
|
$engine->process();
|
|
|
|
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
$views = array();
|
|
|
|
foreach ($comments as $comment) {
|
|
|
|
$view = id(new DiffusionCommentView())
|
|
|
|
->setMarkupEngine($engine)
|
|
|
|
->setUser($user)
|
|
|
|
->setComment($comment)
|
|
|
|
->setIsPreview(true);
|
2012-02-27 13:00:23 -08:00
|
|
|
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
$phids = array_merge($phids, $view->getRequiredHandlePHIDs());
|
|
|
|
$views[] = $view;
|
|
|
|
}
|
2012-04-23 13:50:04 -07:00
|
|
|
|
2012-09-04 19:02:56 -07:00
|
|
|
$handles = $this->loadViewerHandles($phids);
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
|
|
|
|
foreach ($views as $view) {
|
|
|
|
$view->setHandles($handles);
|
|
|
|
}
|
2012-02-27 13:00:23 -08:00
|
|
|
|
|
|
|
id(new PhabricatorDraft())
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
->setAuthorPHID($user->getPHID())
|
2012-02-27 13:00:23 -08:00
|
|
|
->setDraftKey('diffusion-audit-'.$this->id)
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
->setDraft($content)
|
2012-10-01 15:50:47 -07:00
|
|
|
->replaceOrDelete();
|
2012-02-27 13:00:23 -08:00
|
|
|
|
Write separate comments for every action in Audit
Summary:
Ref T4896. Depends on D10023. Prepares the code for the final migration.
The transaction table stores one row per distinct effect (e.g., add CCs) rather than one row per user action (e.g., "add CCs + comment"). We can double-read that table as long as the code doesn't expect transactions/comments to have multiple different effects, and doesn't try to write any such rows.
Everywhere that we were writing a big "X + Y" comment, write two separate "X" and "Y" comments instead. Like D10023, this disrupts the UI a little (you get more boxes), but that will be resolved once the rendering code swaps over. Otherwise, this retains the existing behavior.
Test Plan:
- Used `diffusion.createcomment` to add comments, raise concern, and accept.
- Previewed commenting, adding auditors/ccs, accepting, raising concern.
- Actually performed commenting, adding auditors/ccs, accepting, raising concern.
- Added a user with mentions.
- Added an explicit CC and a mention user.
Reviewers: btrahan, joshuaspence
Reviewed By: joshuaspence
Subscribers: epriestley
Maniphest Tasks: T4896
Differential Revision: https://secure.phabricator.com/D10052
2014-07-28 15:00:18 -07:00
|
|
|
return id(new AphrontAjaxResponse())->setContent(hsprintf('%s', $views));
|
2012-02-27 13:00:23 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|