2011-02-08 10:53:59 -08:00
|
|
|
<?php
|
|
|
|
|
|
2011-07-04 13:04:22 -07:00
|
|
|
/**
|
|
|
|
|
* @group maniphest
|
|
|
|
|
*/
|
2012-03-09 15:46:25 -08:00
|
|
|
final class ManiphestTransactionSaveController extends ManiphestController {
|
2011-02-08 10:53:59 -08:00
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
|
$request = $this->getRequest();
|
|
|
|
|
$user = $request->getUser();
|
|
|
|
|
|
|
|
|
|
$task = id(new ManiphestTask())->load($request->getStr('taskID'));
|
|
|
|
|
if (!$task) {
|
|
|
|
|
return new Aphront404Response();
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-22 11:55:10 -07:00
|
|
|
$transactions = array();
|
|
|
|
|
|
2011-02-08 10:53:59 -08:00
|
|
|
$action = $request->getStr('action');
|
|
|
|
|
|
2011-05-22 11:55:10 -07:00
|
|
|
// If we have drag-and-dropped files, attach them first in a separate
|
|
|
|
|
// transaction. These can come in on any transaction type, which is why we
|
|
|
|
|
// handle them separately.
|
|
|
|
|
$files = array();
|
|
|
|
|
|
|
|
|
|
// Look for drag-and-drop uploads first.
|
|
|
|
|
$file_phids = $request->getArr('files');
|
|
|
|
|
if ($file_phids) {
|
|
|
|
|
$files = id(new PhabricatorFile())->loadAllWhere(
|
|
|
|
|
'phid in (%Ls)',
|
|
|
|
|
$file_phids);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// This means "attach a file" even though we store other types of data
|
|
|
|
|
// as 'attached'.
|
|
|
|
|
if ($action == ManiphestTransactionType::TYPE_ATTACH) {
|
|
|
|
|
if (!empty($_FILES['file'])) {
|
|
|
|
|
$err = idx($_FILES['file'], 'error');
|
|
|
|
|
if ($err != UPLOAD_ERR_NO_FILE) {
|
2011-07-08 00:17:00 -04:00
|
|
|
$file = PhabricatorFile::newFromPHPUpload(
|
|
|
|
|
$_FILES['file'],
|
|
|
|
|
array(
|
|
|
|
|
'authorPHID' => $user->getPHID(),
|
|
|
|
|
));
|
2011-05-22 11:55:10 -07:00
|
|
|
$files[] = $file;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// If we had explicit or drag-and-drop files, create a transaction
|
|
|
|
|
// for those before we deal with whatever else might have happened.
|
|
|
|
|
$file_transaction = null;
|
|
|
|
|
if ($files) {
|
|
|
|
|
$files = mpull($files, 'getPHID', 'getPHID');
|
|
|
|
|
$new = $task->getAttached();
|
|
|
|
|
foreach ($files as $phid) {
|
2013-07-22 08:02:56 -07:00
|
|
|
if (empty($new[PhabricatorFilePHIDTypeFile::TYPECONST])) {
|
|
|
|
|
$new[PhabricatorFilePHIDTypeFile::TYPECONST] = array();
|
2011-05-22 11:55:10 -07:00
|
|
|
}
|
2013-07-22 08:02:56 -07:00
|
|
|
$new[PhabricatorFilePHIDTypeFile::TYPECONST][$phid] = array();
|
2011-05-22 11:55:10 -07:00
|
|
|
}
|
2013-09-24 10:49:06 -07:00
|
|
|
$transaction = new ManiphestTransaction();
|
2011-05-22 11:55:10 -07:00
|
|
|
$transaction
|
|
|
|
|
->setTransactionType(ManiphestTransactionType::TYPE_ATTACH);
|
|
|
|
|
$transaction->setNewValue($new);
|
|
|
|
|
$transactions[] = $transaction;
|
|
|
|
|
}
|
|
|
|
|
|
2011-07-14 10:55:02 -07:00
|
|
|
// Compute new CCs added by @mentions. Several things can cause CCs to
|
|
|
|
|
// be added as side effects: mentions, explicit CCs, users who aren't
|
|
|
|
|
// CC'd interacting with the task, and ownership changes. We build up a
|
|
|
|
|
// list of all the CCs and then construct a transaction for them at the
|
|
|
|
|
// end if necessary.
|
|
|
|
|
$added_ccs = PhabricatorMarkupEngine::extractPHIDsFromMentions(
|
2011-07-09 16:17:36 -07:00
|
|
|
array(
|
|
|
|
|
$request->getStr('comments'),
|
|
|
|
|
));
|
|
|
|
|
|
2013-09-24 10:49:06 -07:00
|
|
|
$cc_transaction = new ManiphestTransaction();
|
2011-07-14 10:55:02 -07:00
|
|
|
$cc_transaction
|
|
|
|
|
->setTransactionType(ManiphestTransactionType::TYPE_CCS);
|
|
|
|
|
$force_cc_transaction = false;
|
|
|
|
|
|
2013-09-24 10:49:06 -07:00
|
|
|
$transaction = new ManiphestTransaction();
|
2011-02-08 10:53:59 -08:00
|
|
|
$transaction
|
|
|
|
|
->setTransactionType($action);
|
|
|
|
|
|
|
|
|
|
switch ($action) {
|
|
|
|
|
case ManiphestTransactionType::TYPE_STATUS:
|
|
|
|
|
$transaction->setNewValue($request->getStr('resolution'));
|
|
|
|
|
break;
|
|
|
|
|
case ManiphestTransactionType::TYPE_OWNER:
|
|
|
|
|
$assign_to = $request->getArr('assign_to');
|
|
|
|
|
$assign_to = reset($assign_to);
|
|
|
|
|
$transaction->setNewValue($assign_to);
|
|
|
|
|
break;
|
2011-02-20 20:08:16 -08:00
|
|
|
case ManiphestTransactionType::TYPE_PROJECTS:
|
|
|
|
|
$projects = $request->getArr('projects');
|
|
|
|
|
$projects = array_merge($projects, $task->getProjectPHIDs());
|
|
|
|
|
$projects = array_filter($projects);
|
|
|
|
|
$projects = array_unique($projects);
|
|
|
|
|
$transaction->setNewValue($projects);
|
|
|
|
|
break;
|
2011-02-08 10:53:59 -08:00
|
|
|
case ManiphestTransactionType::TYPE_CCS:
|
2011-07-14 10:55:02 -07:00
|
|
|
// Accumulate the new explicit CCs into the array that we'll add in
|
|
|
|
|
// the CC transaction later.
|
|
|
|
|
$added_ccs = array_merge($added_ccs, $request->getArr('ccs'));
|
|
|
|
|
|
|
|
|
|
// Transfer any comments over to the CC transaction.
|
|
|
|
|
$cc_transaction->setComments($transaction->getComments());
|
|
|
|
|
|
|
|
|
|
// Make sure we include this transaction, even if the user didn't
|
|
|
|
|
// actually add any CC's, because we'll discard their comment otherwise.
|
|
|
|
|
$force_cc_transaction = true;
|
|
|
|
|
|
|
|
|
|
// Throw away the primary transaction.
|
|
|
|
|
$transaction = null;
|
2011-02-08 10:53:59 -08:00
|
|
|
break;
|
|
|
|
|
case ManiphestTransactionType::TYPE_PRIORITY:
|
|
|
|
|
$transaction->setNewValue($request->getInt('priority'));
|
|
|
|
|
break;
|
2011-02-20 20:08:16 -08:00
|
|
|
case ManiphestTransactionType::TYPE_ATTACH:
|
Migrate all Maniphest transaction data to new storage
Summary:
Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except:
- The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so:
- When migrating, "edit" + "comment" transactions need to be split in two.
- When editing now, we should no longer combine these transaction types.
- These changes are pretty straightforward and low-impact.
- This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though.
Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other.
Test Plan:
- Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly.
- Droped the test data and performed the migration.
- Looked at the resulting data for obvious discrepancies.
- Looked at a bunch of tasks and their transaction history.
- Used Conduit to pull transaction data.
- Edited task description and clicked "View Details" on transaction.
- Used batch editor.
- Made a bunch more edits.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2217
Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 14:25:28 -07:00
|
|
|
// Nuke this, we created it above.
|
|
|
|
|
$transaction = null;
|
|
|
|
|
break;
|
|
|
|
|
case PhabricatorTransactions::TYPE_COMMENT:
|
|
|
|
|
// Nuke this, we're going to create it below.
|
|
|
|
|
$transaction = null;
|
2011-02-20 20:08:16 -08:00
|
|
|
break;
|
2011-02-08 10:53:59 -08:00
|
|
|
default:
|
|
|
|
|
throw new Exception('unknown action');
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-22 11:55:10 -07:00
|
|
|
if ($transaction) {
|
|
|
|
|
$transactions[] = $transaction;
|
|
|
|
|
}
|
2011-02-09 12:57:38 -08:00
|
|
|
|
Migrate all Maniphest transaction data to new storage
Summary:
Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except:
- The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so:
- When migrating, "edit" + "comment" transactions need to be split in two.
- When editing now, we should no longer combine these transaction types.
- These changes are pretty straightforward and low-impact.
- This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though.
Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other.
Test Plan:
- Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly.
- Droped the test data and performed the migration.
- Looked at the resulting data for obvious discrepancies.
- Looked at a bunch of tasks and their transaction history.
- Used Conduit to pull transaction data.
- Edited task description and clicked "View Details" on transaction.
- Used batch editor.
- Made a bunch more edits.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2217
Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 14:25:28 -07:00
|
|
|
if ($request->getStr('comments')) {
|
2013-09-24 10:49:06 -07:00
|
|
|
$transactions[] = id(new ManiphestTransaction())
|
Migrate all Maniphest transaction data to new storage
Summary:
Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except:
- The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so:
- When migrating, "edit" + "comment" transactions need to be split in two.
- When editing now, we should no longer combine these transaction types.
- These changes are pretty straightforward and low-impact.
- This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though.
Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other.
Test Plan:
- Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly.
- Droped the test data and performed the migration.
- Looked at the resulting data for obvious discrepancies.
- Looked at a bunch of tasks and their transaction history.
- Used Conduit to pull transaction data.
- Edited task description and clicked "View Details" on transaction.
- Used batch editor.
- Made a bunch more edits.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2217
Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 14:25:28 -07:00
|
|
|
->setTransactionType(PhabricatorTransactions::TYPE_COMMENT)
|
2013-09-23 14:33:09 -07:00
|
|
|
->attachComment(
|
|
|
|
|
id(new ManiphestTransactionComment())
|
|
|
|
|
->setContent($request->getStr('comments')));
|
Migrate all Maniphest transaction data to new storage
Summary:
Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except:
- The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so:
- When migrating, "edit" + "comment" transactions need to be split in two.
- When editing now, we should no longer combine these transaction types.
- These changes are pretty straightforward and low-impact.
- This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though.
Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other.
Test Plan:
- Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly.
- Droped the test data and performed the migration.
- Looked at the resulting data for obvious discrepancies.
- Looked at a bunch of tasks and their transaction history.
- Used Conduit to pull transaction data.
- Edited task description and clicked "View Details" on transaction.
- Used batch editor.
- Made a bunch more edits.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T2217
Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 14:25:28 -07:00
|
|
|
}
|
|
|
|
|
|
2011-07-14 10:55:02 -07:00
|
|
|
// When you interact with a task, we add you to the CC list so you get
|
|
|
|
|
// further updates, and possibly assign the task to you if you took an
|
|
|
|
|
// ownership action (closing it) but it's currently unowned. We also move
|
|
|
|
|
// previous owners to CC if ownership changes. Detect all these conditions
|
|
|
|
|
// and create side-effect transactions for them.
|
|
|
|
|
|
|
|
|
|
$implicitly_claimed = false;
|
2011-02-09 12:57:38 -08:00
|
|
|
switch ($action) {
|
|
|
|
|
case ManiphestTransactionType::TYPE_OWNER:
|
|
|
|
|
if ($task->getOwnerPHID() == $transaction->getNewValue()) {
|
|
|
|
|
// If this is actually no-op, don't generate the side effect.
|
|
|
|
|
break;
|
|
|
|
|
}
|
2011-07-14 10:55:02 -07:00
|
|
|
// Otherwise, when a task is reassigned, move the previous owner to CC.
|
|
|
|
|
$added_ccs[] = $task->getOwnerPHID();
|
2011-02-09 12:57:38 -08:00
|
|
|
break;
|
2011-03-29 14:27:31 -07:00
|
|
|
case ManiphestTransactionType::TYPE_STATUS:
|
|
|
|
|
if (!$task->getOwnerPHID() &&
|
|
|
|
|
$request->getStr('resolution') !=
|
|
|
|
|
ManiphestTaskStatus::STATUS_OPEN) {
|
2011-07-14 10:55:02 -07:00
|
|
|
// Closing an unassigned task. Assign the user as the owner of
|
|
|
|
|
// this task.
|
2013-09-24 10:49:06 -07:00
|
|
|
$assign = new ManiphestTransaction();
|
2011-03-29 14:27:31 -07:00
|
|
|
$assign->setTransactionType(ManiphestTransactionType::TYPE_OWNER);
|
|
|
|
|
$assign->setNewValue($user->getPHID());
|
|
|
|
|
$transactions[] = $assign;
|
2011-07-14 10:55:02 -07:00
|
|
|
|
|
|
|
|
$implicitly_claimed = true;
|
2011-03-29 14:27:31 -07:00
|
|
|
}
|
|
|
|
|
break;
|
2011-02-09 12:57:38 -08:00
|
|
|
}
|
|
|
|
|
|
2011-07-09 16:17:36 -07:00
|
|
|
|
2011-07-14 10:55:02 -07:00
|
|
|
$user_owns_task = false;
|
|
|
|
|
if ($implicitly_claimed) {
|
|
|
|
|
$user_owns_task = true;
|
|
|
|
|
} else {
|
|
|
|
|
if ($action == ManiphestTransactionType::TYPE_OWNER) {
|
|
|
|
|
if ($transaction->getNewValue() == $user->getPHID()) {
|
|
|
|
|
$user_owns_task = true;
|
|
|
|
|
}
|
|
|
|
|
} else if ($task->getOwnerPHID() == $user->getPHID()) {
|
|
|
|
|
$user_owns_task = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!$user_owns_task) {
|
|
|
|
|
// If we aren't making the user the new task owner and they aren't the
|
2013-09-23 14:33:09 -07:00
|
|
|
// existing task owner, add them to CC unless they're aleady CC'd.
|
|
|
|
|
if (!in_array($user->getPHID(), $task->getCCPHIDs())) {
|
|
|
|
|
$added_ccs[] = $user->getPHID();
|
|
|
|
|
}
|
2011-07-14 10:55:02 -07:00
|
|
|
}
|
2011-05-22 11:55:10 -07:00
|
|
|
|
2011-07-14 10:55:02 -07:00
|
|
|
if ($added_ccs || $force_cc_transaction) {
|
|
|
|
|
// We've added CCs, so include a CC transaction. It's safe to do this even
|
|
|
|
|
// if we're just "adding" CCs which already exist, because the
|
|
|
|
|
// ManiphestTransactionEditor is smart enough to ignore them.
|
|
|
|
|
$all_ccs = array_merge($task->getCCPHIDs(), $added_ccs);
|
|
|
|
|
$cc_transaction->setNewValue($all_ccs);
|
|
|
|
|
$transactions[] = $cc_transaction;
|
2011-07-09 16:17:36 -07:00
|
|
|
}
|
2011-05-22 11:55:10 -07:00
|
|
|
|
2011-08-31 13:25:13 -07:00
|
|
|
$event = new PhabricatorEvent(
|
|
|
|
|
PhabricatorEventType::TYPE_MANIPHEST_WILLEDITTASK,
|
|
|
|
|
array(
|
|
|
|
|
'task' => $task,
|
|
|
|
|
'new' => false,
|
|
|
|
|
'transactions' => $transactions,
|
|
|
|
|
));
|
|
|
|
|
$event->setUser($user);
|
|
|
|
|
$event->setAphrontRequest($request);
|
2011-11-09 17:23:33 -08:00
|
|
|
PhutilEventEngine::dispatchEvent($event);
|
2011-08-31 13:25:13 -07:00
|
|
|
|
|
|
|
|
$task = $event->getValue('task');
|
|
|
|
|
$transactions = $event->getValue('transactions');
|
|
|
|
|
|
2013-09-23 14:33:09 -07:00
|
|
|
$editor = id(new ManiphestTransactionEditorPro())
|
|
|
|
|
->setActor($user)
|
|
|
|
|
->setContentSourceFromRequest($request)
|
|
|
|
|
->setContinueOnMissingFields(true)
|
|
|
|
|
->applyTransactions($task, $transactions);
|
2011-02-08 10:53:59 -08:00
|
|
|
|
2011-05-10 16:18:47 -07:00
|
|
|
$draft = id(new PhabricatorDraft())->loadOneWhere(
|
|
|
|
|
'authorPHID = %s AND draftKey = %s',
|
|
|
|
|
$user->getPHID(),
|
|
|
|
|
$task->getPHID());
|
|
|
|
|
if ($draft) {
|
|
|
|
|
$draft->delete();
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-22 13:07:12 -07:00
|
|
|
$event = new PhabricatorEvent(
|
|
|
|
|
PhabricatorEventType::TYPE_MANIPHEST_DIDEDITTASK,
|
|
|
|
|
array(
|
|
|
|
|
'task' => $task,
|
|
|
|
|
'new' => false,
|
|
|
|
|
'transactions' => $transactions,
|
|
|
|
|
));
|
|
|
|
|
$event->setUser($user);
|
|
|
|
|
$event->setAphrontRequest($request);
|
|
|
|
|
PhutilEventEngine::dispatchEvent($event);
|
|
|
|
|
|
2011-02-08 10:53:59 -08:00
|
|
|
return id(new AphrontRedirectResponse())
|
|
|
|
|
->setURI('/T'.$task->getID());
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
}
|