2012-02-24 22:00:48 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
final class ManiphestBatchEditController extends ManiphestController {
|
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
public function handleRequest(AphrontRequest $request) {
|
|
|
|
$viewer = $this->getViewer();
|
|
|
|
|
Add capabilities for editing task triage details (priority, assignee, etc)
Summary:
This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions.
Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces.
Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
|
|
|
$this->requireApplicationCapability(
|
2014-07-25 00:20:39 +02:00
|
|
|
ManiphestBulkEditCapability::CAPABILITY);
|
Add capabilities for editing task triage details (priority, assignee, etc)
Summary:
This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions.
Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces.
Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$project = null;
|
|
|
|
$board_id = $request->getInt('board');
|
|
|
|
if ($board_id) {
|
|
|
|
$project = id(new PhabricatorProjectQuery())
|
|
|
|
->setViewer($viewer)
|
|
|
|
->withIDs(array($board_id))
|
|
|
|
->executeOne();
|
|
|
|
if (!$project) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
|
|
|
}
|
2012-02-24 22:00:48 +01:00
|
|
|
|
|
|
|
$task_ids = $request->getArr('batch');
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
if (!$task_ids) {
|
|
|
|
$task_ids = $request->getStrList('batch');
|
|
|
|
}
|
|
|
|
|
2013-09-25 22:44:14 +02:00
|
|
|
$tasks = id(new ManiphestTaskQuery())
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
->setViewer($viewer)
|
2013-09-25 22:44:14 +02:00
|
|
|
->withIDs($task_ids)
|
|
|
|
->requireCapabilities(
|
|
|
|
array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
))
|
2014-12-11 01:27:30 +01:00
|
|
|
->needSubscriberPHIDs(true)
|
2014-12-18 22:53:45 +01:00
|
|
|
->needProjectPHIDs(true)
|
2013-09-25 22:44:14 +02:00
|
|
|
->execute();
|
2012-02-24 22:00:48 +01:00
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
if ($project) {
|
|
|
|
$cancel_uri = '/project/board/'.$project->getID().'/';
|
|
|
|
$redirect_uri = $cancel_uri;
|
|
|
|
} else {
|
|
|
|
$cancel_uri = '/maniphest/';
|
|
|
|
$redirect_uri = '/maniphest/?ids='.implode(',', mpull($tasks, 'getID'));
|
|
|
|
}
|
|
|
|
|
2012-02-24 22:00:48 +01:00
|
|
|
$actions = $request->getStr('actions');
|
|
|
|
if ($actions) {
|
|
|
|
$actions = json_decode($actions, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($request->isFormPost() && is_array($actions)) {
|
|
|
|
foreach ($tasks as $task) {
|
2013-09-23 23:32:22 +02:00
|
|
|
$field_list = PhabricatorCustomField::getObjectFields(
|
|
|
|
$task,
|
|
|
|
PhabricatorCustomField::ROLE_EDIT);
|
|
|
|
$field_list->readFieldsFromStorage($task);
|
|
|
|
|
2012-02-24 22:00:48 +01:00
|
|
|
$xactions = $this->buildTransactions($actions, $task);
|
|
|
|
if ($xactions) {
|
2013-09-23 23:32:22 +02:00
|
|
|
// TODO: Set content source to "batch edit".
|
|
|
|
|
2013-10-22 01:58:37 +02:00
|
|
|
$editor = id(new ManiphestTransactionEditor())
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
->setActor($viewer)
|
2013-09-23 23:32:22 +02:00
|
|
|
->setContentSourceFromRequest($request)
|
|
|
|
->setContinueOnNoEffect(true)
|
2013-09-23 23:32:32 +02:00
|
|
|
->setContinueOnMissingFields(true)
|
2013-09-23 23:32:22 +02:00
|
|
|
->applyTransactions($task, $xactions);
|
2012-02-24 22:00:48 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
return id(new AphrontRedirectResponse())->setURI($redirect_uri);
|
2012-02-24 22:00:48 +01:00
|
|
|
}
|
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$handles = ManiphestTaskListView::loadTaskHandles($viewer, $tasks);
|
2012-02-24 22:00:48 +01:00
|
|
|
|
|
|
|
$list = new ManiphestTaskListView();
|
|
|
|
$list->setTasks($tasks);
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$list->setUser($viewer);
|
2012-02-24 22:00:48 +01:00
|
|
|
$list->setHandles($handles);
|
|
|
|
|
|
|
|
$template = new AphrontTokenizerTemplateView();
|
|
|
|
$template = $template->render();
|
|
|
|
|
2014-07-11 02:28:29 +02:00
|
|
|
$projects_source = new PhabricatorProjectDatasource();
|
2014-07-18 00:44:29 +02:00
|
|
|
$mailable_source = new PhabricatorMetaMTAMailableDatasource();
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$mailable_source->setViewer($viewer);
|
2015-04-19 17:23:56 +02:00
|
|
|
$owner_source = new ManiphestAssigneeDatasource();
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$owner_source->setViewer($viewer);
|
2014-07-11 02:28:29 +02:00
|
|
|
|
2012-02-24 22:00:48 +01:00
|
|
|
require_celerity_resource('maniphest-batch-editor');
|
|
|
|
Javelin::initBehavior(
|
|
|
|
'maniphest-batch-editor',
|
|
|
|
array(
|
|
|
|
'root' => 'maniphest-batch-edit-form',
|
|
|
|
'tokenizerTemplate' => $template,
|
|
|
|
'sources' => array(
|
2012-03-21 22:01:04 +01:00
|
|
|
'project' => array(
|
2015-04-16 23:46:10 +02:00
|
|
|
'src' => $projects_source->getDatasourceURI(),
|
|
|
|
'placeholder' => $projects_source->getPlaceholderText(),
|
|
|
|
'browseURI' => $projects_source->getBrowseURI(),
|
2012-03-21 22:01:04 +01:00
|
|
|
),
|
|
|
|
'owner' => array(
|
2015-04-16 23:46:10 +02:00
|
|
|
'src' => $owner_source->getDatasourceURI(),
|
|
|
|
'placeholder' => $owner_source->getPlaceholderText(),
|
|
|
|
'browseURI' => $owner_source->getBrowseURI(),
|
|
|
|
'limit' => 1,
|
2012-03-21 22:01:04 +01:00
|
|
|
),
|
2015-04-16 23:46:10 +02:00
|
|
|
'cc' => array(
|
|
|
|
'src' => $mailable_source->getDatasourceURI(),
|
|
|
|
'placeholder' => $mailable_source->getPlaceholderText(),
|
|
|
|
'browseURI' => $mailable_source->getBrowseURI(),
|
2014-10-07 15:01:04 +02:00
|
|
|
),
|
2012-02-24 22:00:48 +01:00
|
|
|
),
|
|
|
|
'input' => 'batch-form-actions',
|
2012-03-21 22:01:04 +01:00
|
|
|
'priorityMap' => ManiphestTaskPriority::getTaskPriorityMap(),
|
|
|
|
'statusMap' => ManiphestTaskStatus::getTaskStatusMap(),
|
2012-02-24 22:00:48 +01:00
|
|
|
));
|
|
|
|
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
$form = id(new AphrontFormView())
|
|
|
|
->setUser($viewer)
|
|
|
|
->addHiddenInput('board', $board_id)
|
|
|
|
->setID('maniphest-batch-edit-form');
|
2012-02-24 22:00:48 +01:00
|
|
|
|
|
|
|
foreach ($tasks as $task) {
|
|
|
|
$form->appendChild(
|
2013-01-18 03:39:02 +01:00
|
|
|
phutil_tag(
|
2012-02-24 22:00:48 +01:00
|
|
|
'input',
|
|
|
|
array(
|
|
|
|
'type' => 'hidden',
|
|
|
|
'name' => 'batch[]',
|
|
|
|
'value' => $task->getID(),
|
2013-01-18 03:39:02 +01:00
|
|
|
)));
|
2012-02-24 22:00:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
$form->appendChild(
|
2013-01-18 03:39:02 +01:00
|
|
|
phutil_tag(
|
2012-02-24 22:00:48 +01:00
|
|
|
'input',
|
|
|
|
array(
|
|
|
|
'type' => 'hidden',
|
|
|
|
'name' => 'actions',
|
|
|
|
'id' => 'batch-form-actions',
|
2013-01-18 03:39:02 +01:00
|
|
|
)));
|
2012-02-24 22:00:48 +01:00
|
|
|
$form->appendChild(
|
2014-11-07 23:16:30 +01:00
|
|
|
id(new PHUIFormInsetView())
|
2014-11-20 00:23:37 +01:00
|
|
|
->setTitle(pht('Actions'))
|
2013-01-25 21:57:17 +01:00
|
|
|
->setRightButton(javelin_tag(
|
2012-02-24 22:00:48 +01:00
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => '#',
|
|
|
|
'class' => 'button green',
|
|
|
|
'sigil' => 'add-action',
|
|
|
|
'mustcapture' => true,
|
|
|
|
),
|
2013-03-13 07:30:03 +01:00
|
|
|
pht('Add Another Action')))
|
2013-01-25 21:57:17 +01:00
|
|
|
->setContent(javelin_tag(
|
2012-02-24 22:00:48 +01:00
|
|
|
'table',
|
|
|
|
array(
|
|
|
|
'sigil' => 'maniphest-batch-actions',
|
|
|
|
'class' => 'maniphest-batch-actions-table',
|
|
|
|
),
|
2012-03-16 01:10:19 +01:00
|
|
|
'')))
|
2012-02-24 22:00:48 +01:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSubmitControl())
|
2013-03-13 07:30:03 +01:00
|
|
|
->setValue(pht('Update Tasks'))
|
Add a "Batch Edit Tasks..." action to workboard columns
Summary:
Ref T5523. Adds a new workflow to make some kinds of bulk workboard operations easier.
New dropdown action:
{F376848}
This brings you into the existing bulk edit flow:
{F376849}
When you save an edit, you're taken back to the board:
{F376850}
If you try to edit a column with nothing in it, you get an error:
{F376851}
Note that the selected workboard filter is applied before choosing tasks, so if your filter is set to "open tasks" we only batch edit the open (i.e., currently visible) tasks in the column. I think this is more powerful (it lets you use filtering to select task subsets) but might not be completely obvious in all cases (although I do think it's more obvious than the alternative rule -- just an issue of neither rule being completely obvious).
Test Plan:
- Batch edited tasks in a column.
- Used "Batch Edit Tasks..." to move tasks to a different workboard by removing + adding a project.
- Batch edited a column with filtered-out tasks, verified only visible tasks were edited.
- Batch edited a column with no visible tasks, received error.
- Used the batch editor normally (Maniphest -> Maniphest, no boards).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: johnny-bit, cburroughs, epriestley
Projects: #prioritized
Maniphest Tasks: T5523
Differential Revision: https://secure.phabricator.com/D12475
2015-04-20 19:05:08 +02:00
|
|
|
->addCancelButton($cancel_uri));
|
2013-09-13 20:29:08 +02:00
|
|
|
|
|
|
|
$title = pht('Batch Editor');
|
2012-02-24 22:00:48 +01:00
|
|
|
|
2013-09-13 20:29:08 +02:00
|
|
|
$crumbs = $this->buildApplicationCrumbs();
|
2013-12-19 02:47:34 +01:00
|
|
|
$crumbs->addTextCrumb($title);
|
2012-02-24 22:00:48 +01:00
|
|
|
|
2014-11-20 00:23:37 +01:00
|
|
|
$task_box = id(new PHUIObjectBoxView())
|
|
|
|
->setHeaderText(pht('Selected Tasks'))
|
|
|
|
->appendChild($list);
|
|
|
|
|
2013-09-25 20:23:29 +02:00
|
|
|
$form_box = id(new PHUIObjectBoxView())
|
2014-11-20 00:23:37 +01:00
|
|
|
->setHeaderText(pht('Batch Editor'))
|
2013-09-13 20:29:08 +02:00
|
|
|
->setForm($form);
|
2012-02-24 22:00:48 +01:00
|
|
|
|
2013-09-13 20:29:08 +02:00
|
|
|
return $this->buildApplicationPage(
|
|
|
|
array(
|
|
|
|
$crumbs,
|
2014-11-20 00:23:37 +01:00
|
|
|
$task_box,
|
2013-09-13 20:29:08 +02:00
|
|
|
$form_box,
|
|
|
|
),
|
2012-02-24 22:00:48 +01:00
|
|
|
array(
|
2013-09-13 20:29:08 +02:00
|
|
|
'title' => $title,
|
2012-02-24 22:00:48 +01:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
private function buildTransactions($actions, ManiphestTask $task) {
|
2012-03-21 22:01:04 +01:00
|
|
|
$value_map = array();
|
|
|
|
$type_map = array(
|
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 23:25:28 +02:00
|
|
|
'add_comment' => PhabricatorTransactions::TYPE_COMMENT,
|
2013-09-25 20:16:43 +02:00
|
|
|
'assign' => ManiphestTransaction::TYPE_OWNER,
|
|
|
|
'status' => ManiphestTransaction::TYPE_STATUS,
|
|
|
|
'priority' => ManiphestTransaction::TYPE_PRIORITY,
|
2014-12-18 23:17:16 +01:00
|
|
|
'add_project' => PhabricatorTransactions::TYPE_EDGE,
|
|
|
|
'remove_project' => PhabricatorTransactions::TYPE_EDGE,
|
2014-12-11 01:27:30 +01:00
|
|
|
'add_ccs' => PhabricatorTransactions::TYPE_SUBSCRIBERS,
|
|
|
|
'remove_ccs' => PhabricatorTransactions::TYPE_SUBSCRIBERS,
|
2012-03-21 22:01:04 +01:00
|
|
|
);
|
2012-03-21 12:37:01 +01:00
|
|
|
|
2012-07-28 00:25:32 +02:00
|
|
|
$edge_edit_types = array(
|
|
|
|
'add_project' => true,
|
|
|
|
'remove_project' => true,
|
2013-04-05 19:34:43 +02:00
|
|
|
'add_ccs' => true,
|
|
|
|
'remove_ccs' => true,
|
2012-07-28 00:25:32 +02:00
|
|
|
);
|
|
|
|
|
2012-02-24 22:00:48 +01:00
|
|
|
$xactions = array();
|
|
|
|
foreach ($actions as $action) {
|
2012-03-21 22:01:04 +01:00
|
|
|
if (empty($type_map[$action['action']])) {
|
|
|
|
throw new Exception("Unknown batch edit action '{$action}'!");
|
|
|
|
}
|
2012-02-24 22:00:48 +01:00
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
$type = $type_map[$action['action']];
|
2012-02-24 22:00:48 +01:00
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
// Figure out the current value, possibly after modifications by other
|
|
|
|
// batch actions of the same type. For example, if the user chooses to
|
|
|
|
// "Add Comment" twice, we should add both comments. More notably, if the
|
|
|
|
// user chooses "Remove Project..." and also "Add Project...", we should
|
|
|
|
// avoid restoring the removed project in the second transaction.
|
2012-03-21 12:37:01 +01:00
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
if (array_key_exists($type, $value_map)) {
|
|
|
|
$current = $value_map[$type];
|
|
|
|
} else {
|
|
|
|
switch ($type) {
|
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 23:25:28 +02:00
|
|
|
case PhabricatorTransactions::TYPE_COMMENT:
|
2012-03-21 22:01:04 +01:00
|
|
|
$current = null;
|
|
|
|
break;
|
2013-09-25 20:16:43 +02:00
|
|
|
case ManiphestTransaction::TYPE_OWNER:
|
2012-03-21 22:01:04 +01:00
|
|
|
$current = $task->getOwnerPHID();
|
|
|
|
break;
|
2013-09-25 20:16:43 +02:00
|
|
|
case ManiphestTransaction::TYPE_STATUS:
|
2012-03-21 22:01:04 +01:00
|
|
|
$current = $task->getStatus();
|
|
|
|
break;
|
2013-09-25 20:16:43 +02:00
|
|
|
case ManiphestTransaction::TYPE_PRIORITY:
|
2012-03-21 22:01:04 +01:00
|
|
|
$current = $task->getPriority();
|
|
|
|
break;
|
2014-12-18 23:17:16 +01:00
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
2012-03-21 12:37:01 +01:00
|
|
|
$current = $task->getProjectPHIDs();
|
2012-03-21 22:01:04 +01:00
|
|
|
break;
|
2014-12-11 01:27:30 +01:00
|
|
|
case PhabricatorTransactions::TYPE_SUBSCRIBERS:
|
|
|
|
$current = $task->getSubscriberPHIDs();
|
2013-04-05 19:34:43 +02:00
|
|
|
break;
|
2012-03-21 22:01:04 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if the value is meaningful / provided, and normalize it if
|
|
|
|
// necessary. This discards, e.g., empty comments and empty owner
|
|
|
|
// changes.
|
|
|
|
|
|
|
|
$value = $action['value'];
|
|
|
|
switch ($type) {
|
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 23:25:28 +02:00
|
|
|
case PhabricatorTransactions::TYPE_COMMENT:
|
2012-03-21 22:01:04 +01:00
|
|
|
if (!strlen($value)) {
|
|
|
|
continue 2;
|
|
|
|
}
|
|
|
|
break;
|
2013-09-25 20:16:43 +02:00
|
|
|
case ManiphestTransaction::TYPE_OWNER:
|
2012-03-21 22:01:04 +01:00
|
|
|
if (empty($value)) {
|
|
|
|
continue 2;
|
|
|
|
}
|
|
|
|
$value = head($value);
|
2015-04-19 17:23:56 +02:00
|
|
|
$no_owner = ManiphestNoOwnerDatasource::FUNCTION_TOKEN;
|
|
|
|
if ($value === ManiphestNoOwnerDatasource::FUNCTION_TOKEN) {
|
2012-03-21 22:01:04 +01:00
|
|
|
$value = null;
|
2012-03-21 12:37:01 +01:00
|
|
|
}
|
2012-03-21 22:01:04 +01:00
|
|
|
break;
|
2014-12-18 23:17:16 +01:00
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
2012-03-21 22:01:04 +01:00
|
|
|
if (empty($value)) {
|
|
|
|
continue 2;
|
|
|
|
}
|
|
|
|
break;
|
2014-12-11 01:27:30 +01:00
|
|
|
case PhabricatorTransactions::TYPE_SUBSCRIBERS:
|
2013-04-05 19:34:43 +02:00
|
|
|
if (empty($value)) {
|
|
|
|
continue 2;
|
|
|
|
}
|
|
|
|
break;
|
2012-03-21 22:01:04 +01:00
|
|
|
}
|
|
|
|
|
2012-07-28 00:25:32 +02:00
|
|
|
// If the edit doesn't change anything, go to the next action. This
|
|
|
|
// check is only valid for changes like "owner", "status", etc, not
|
|
|
|
// for edge edits, because we should still apply an edit like
|
|
|
|
// "Remove Projects: A, B" to a task with projects "A, B".
|
2012-03-21 22:01:04 +01:00
|
|
|
|
2012-07-28 00:25:32 +02:00
|
|
|
if (empty($edge_edit_types[$action['action']])) {
|
|
|
|
if ($value == $current) {
|
|
|
|
continue;
|
|
|
|
}
|
2012-03-21 22:01:04 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
// Apply the value change; for most edits this is just replacement, but
|
|
|
|
// some need to merge the current and edited values (add/remove project).
|
|
|
|
|
|
|
|
switch ($type) {
|
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 23:25:28 +02:00
|
|
|
case PhabricatorTransactions::TYPE_COMMENT:
|
2012-03-21 22:01:04 +01:00
|
|
|
if (strlen($current)) {
|
|
|
|
$value = $current."\n\n".$value;
|
|
|
|
}
|
|
|
|
break;
|
2014-12-18 23:17:16 +01:00
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
2014-12-11 01:27:30 +01:00
|
|
|
$is_remove = $action['action'] == 'remove_project';
|
2012-03-21 12:37:01 +01:00
|
|
|
|
|
|
|
$current = array_fill_keys($current, true);
|
2012-02-24 22:00:48 +01:00
|
|
|
$value = array_fill_keys($value, true);
|
|
|
|
|
|
|
|
$new = $current;
|
|
|
|
$did_something = false;
|
|
|
|
|
|
|
|
if ($is_remove) {
|
|
|
|
foreach ($value as $phid => $ignored) {
|
|
|
|
if (isset($new[$phid])) {
|
|
|
|
unset($new[$phid]);
|
|
|
|
$did_something = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
foreach ($value as $phid => $ignored) {
|
|
|
|
if (empty($new[$phid])) {
|
|
|
|
$new[$phid] = true;
|
|
|
|
$did_something = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$did_something) {
|
2012-03-21 22:01:04 +01:00
|
|
|
continue 2;
|
2012-02-24 22:00:48 +01:00
|
|
|
}
|
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
$value = array_keys($new);
|
2014-12-11 01:27:30 +01:00
|
|
|
break;
|
|
|
|
case PhabricatorTransactions::TYPE_SUBSCRIBERS:
|
|
|
|
$is_remove = $action['action'] == 'remove_ccs';
|
|
|
|
|
|
|
|
$current = array_fill_keys($current, true);
|
|
|
|
|
|
|
|
$new = array();
|
|
|
|
$did_something = false;
|
|
|
|
|
|
|
|
if ($is_remove) {
|
|
|
|
foreach ($value as $phid) {
|
|
|
|
if (isset($current[$phid])) {
|
|
|
|
$new[$phid] = true;
|
|
|
|
$did_something = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if ($new) {
|
|
|
|
$value = array('-' => array_keys($new));
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
$new = array();
|
|
|
|
foreach ($value as $phid) {
|
|
|
|
$new[$phid] = true;
|
|
|
|
$did_something = true;
|
|
|
|
}
|
|
|
|
if ($new) {
|
|
|
|
$value = array('+' => array_keys($new));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!$did_something) {
|
|
|
|
continue 2;
|
|
|
|
}
|
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
break;
|
|
|
|
}
|
2012-03-21 12:37:01 +01:00
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
$value_map[$type] = $value;
|
|
|
|
}
|
2012-03-21 12:37:01 +01:00
|
|
|
|
2013-09-24 19:49:06 +02:00
|
|
|
$template = 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 23:25:28 +02:00
|
|
|
|
2012-03-21 22:01:04 +01:00
|
|
|
foreach ($value_map as $type => $value) {
|
|
|
|
$xaction = clone $template;
|
|
|
|
$xaction->setTransactionType($type);
|
|
|
|
|
|
|
|
switch ($type) {
|
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 23:25:28 +02:00
|
|
|
case PhabricatorTransactions::TYPE_COMMENT:
|
2013-09-23 23:32:22 +02:00
|
|
|
$xaction->attachComment(
|
|
|
|
id(new ManiphestTransactionComment())
|
|
|
|
->setContent($value));
|
2012-03-21 22:01:04 +01:00
|
|
|
break;
|
2014-12-18 23:17:16 +01:00
|
|
|
case PhabricatorTransactions::TYPE_EDGE:
|
2014-07-18 00:43:40 +02:00
|
|
|
$project_type = PhabricatorProjectObjectHasProjectEdgeType::EDGECONST;
|
|
|
|
$xaction
|
|
|
|
->setMetadataValue('edge:type', $project_type)
|
|
|
|
->setNewValue(
|
|
|
|
array(
|
|
|
|
'=' => array_fuse($value),
|
|
|
|
));
|
|
|
|
break;
|
2012-03-21 22:01:04 +01:00
|
|
|
default:
|
|
|
|
$xaction->setNewValue($value);
|
2012-02-24 22:00:48 +01:00
|
|
|
break;
|
|
|
|
}
|
2012-03-21 22:01:04 +01:00
|
|
|
|
|
|
|
$xactions[] = $xaction;
|
2012-02-24 22:00:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return $xactions;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|