Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
$status_map = array(
|
|
|
|
0 => 'open',
|
|
|
|
1 => 'resolved',
|
|
|
|
2 => 'wontfix',
|
|
|
|
3 => 'invalid',
|
|
|
|
4 => 'duplicate',
|
|
|
|
5 => 'spite',
|
|
|
|
);
|
|
|
|
|
|
|
|
$conn_w = id(new ManiphestTask())->establishConnection('w');
|
|
|
|
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating tasks to new status constants...')."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
foreach (new LiskMigrationIterator(new ManiphestTask()) as $task) {
|
|
|
|
$id = $task->getID();
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating %s...', "T{$id}")."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
|
|
|
|
$status = $task->getStatus();
|
|
|
|
if (isset($status_map[$status])) {
|
|
|
|
queryfx(
|
|
|
|
$conn_w,
|
|
|
|
'UPDATE %T SET status = %s WHERE id = %d',
|
|
|
|
$task->getTableName(),
|
|
|
|
$status_map[$status],
|
|
|
|
$id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Done.')."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
|
|
|
|
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating task transactions to new status constants...')."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
foreach (new LiskMigrationIterator(new ManiphestTransaction()) as $xaction) {
|
|
|
|
$id = $xaction->getID();
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating %d...', $id)."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
|
2017-05-15 19:23:20 +02:00
|
|
|
$xn_type = ManiphestTaskStatusTransaction::TRANSACTIONTYPE;
|
|
|
|
if ($xaction->getTransactionType() == $xn_type) {
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
$old = $xaction->getOldValue();
|
|
|
|
if ($old !== null && isset($status_map[$old])) {
|
|
|
|
$old = $status_map[$old];
|
|
|
|
}
|
|
|
|
|
|
|
|
$new = $xaction->getNewValue();
|
|
|
|
if (isset($status_map[$new])) {
|
|
|
|
$new = $status_map[$new];
|
|
|
|
}
|
|
|
|
|
|
|
|
queryfx(
|
|
|
|
$conn_w,
|
|
|
|
'UPDATE %T SET oldValue = %s, newValue = %s WHERE id = %d',
|
|
|
|
$xaction->getTableName(),
|
|
|
|
json_encode($old),
|
|
|
|
json_encode($new),
|
|
|
|
$id);
|
|
|
|
}
|
|
|
|
}
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Done.')."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
|
|
|
|
$conn_w = id(new PhabricatorSavedQuery())->establishConnection('w');
|
|
|
|
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating searches to new status constants...')."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
foreach (new LiskMigrationIterator(new PhabricatorSavedQuery()) as $query) {
|
|
|
|
$id = $query->getID();
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Migrating %d...', $id)."\n";
|
Use string constants, not integer constants, to represent task status internally
Summary:
Ref T1812. I think integer constants are going to be confusing and error prone for users to interact with. For example, because we use 0-5, adding a second "open" status like "needs verification" without disrupting the existing statuses would require users to define a status with, e.g., constant `6`, but order it between constants `0` and `1`. And if they later remove statuses, they need to avoid reusing existing constants.
Instead, use more manageable string constants like "open", "resolved", etc.
We must migrate three tables:
- The task table itself, to update task status.
- The transaction table, to update historic status changes.
- The saved query table, to update saved queries which specify status sets.
Test Plan:
- Saved a query with complicated status filters.
- Ran migrations.
- Looked at the query, at existing tasks, and at task transactions.
- Forced migrations to run again to verify idempotentcy/safety.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1812
Differential Revision: https://secure.phabricator.com/D8583
2014-03-25 21:58:14 +01:00
|
|
|
|
|
|
|
if ($query->getEngineClassName() !== 'ManiphestTaskSearchEngine') {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
$params = $query->getParameters();
|
|
|
|
$statuses = idx($params, 'statuses', array());
|
|
|
|
if ($statuses) {
|
|
|
|
$changed = false;
|
|
|
|
foreach ($statuses as $key => $status) {
|
|
|
|
if (isset($status_map[$status])) {
|
|
|
|
$statuses[$key] = $status_map[$status];
|
|
|
|
$changed = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($changed) {
|
|
|
|
$params['statuses'] = $statuses;
|
|
|
|
|
|
|
|
queryfx(
|
|
|
|
$conn_w,
|
|
|
|
'UPDATE %T SET parameters = %s WHERE id = %d',
|
|
|
|
$query->getTableName(),
|
|
|
|
json_encode($params),
|
|
|
|
$id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2015-05-22 09:27:56 +02:00
|
|
|
echo pht('Done.')."\n";
|