Change Details

Script For Copying Points From a Custom Field ------------------------------------------------------- This script emits SQL you can use to copy an existing custom "Points" field into the new first-class "Points" field. To run this script: - Put it in `phabricator/` - Make it executable with `chmod +x copy_points.php` - Run it as `./copy_points.php` - It will walk you through giving it the information it needs, primarily a `--field <field key>` argument to pick which field to copy from. The script just emits SQL. It does not touch the database, so running it won't make any actual changes. Here's an example run: ``` $ ./copy_points.php --field std:maniphest:birthday UPDATE `phabricator_maniphest`.`maniphest_task` SET points = 238 WHERE id = 216; ``` Generally, the migration process will probably look something like this: - Run the script. - Look at the output SQL to make sure it seems OK. - Load a couple of tasks to double-check (e.g., for the output above, load `T216` in the web UI and make sure it should have 238 points). - Pipe the SQL into MySQL to actually run it. That might look like this: ``` $ ./copy_points.php --field whatever > points.sql $ cat points.sql # Look at the results and sanity check them. $ cat points.sql | mysql -u root ``` The script will not copy points to tasks that already have a "points" value. If you make a mistake (for example, copy the wrong field) and need to wipe out all the "new" points values in all tasks so you can do another copy of everything, you can use this query: ```lang=sql /* DANGEROUS! DESTROYS DATA! */ UPDATE phabricator_maniphest.maniphest_task SET points = null; ``` That will destroy the "new" points, but leave any custom points untouched. Then you can use `copy_points.php` again to do a fresh copy. Here's the actual script: {P1940} --- > **Migration Tools**: There are currently no tools to move existing projects underneath other projects (e.g., convert existing project "A" to be a subproject of "B"). We may build these if there's interest. | Registering my interest for being able to move projects into being sub-projects. See https://phabricator.wikimedia.org/project/profile/483/ for an example of using faked sub-projects (with, collectively, thousands of tasks) which I'd love if possible to make "real" without making ten thousand bulk edits, modifying long-dead tasks and melting people's inboxes. Should I file a specific task? Yeah, why don't you file a separate task for the importer thing. I saw https://phabricator.wikimedia.org/T123078 on WMF recently, too. I think there will probably be enough demand for this to bring something formal upstream, but maybe only a few installs care (or everyone has different weird requirements) and we can just throw a script up somewhere and not have to maintain it.

Script For Copying Points From a Custom Field ------------------------------------------------------- This script emits SQL you can use to copy an existing custom "Points" field into the new first-class "Points" field. To run this script: - Put it in `phabricator/` - Make it executable with `chmod +x copy_points.php` - Run it as `./copy_points.php` - It will walk you through giving it the information it needs, primarily a `--field <field key>` argument to pick which field to copy from. The script just prints SQL statements to stdout. It does not touch the database, so **running it won't make any actual changes** to the data. Here's an example run: ``` $ ./copy_points.php --field std:maniphest:birthday UPDATE `phabricator_maniphest`.`maniphest_task` SET points = 238 WHERE id = 216; ``` Generally, the migration process will probably look something like this: - Run the script. - Look at the output SQL to make sure it seems OK. - Load a couple of tasks to double-check (e.g., for the output above, load `T216` in the web UI and make sure it should have 238 points). - Pipe the SQL into MySQL to actually run it. That might look like this: ``` $ ./copy_points.php --field whatever > points.sql $ cat points.sql # Look at the results and sanity check them. $ cat points.sql | mysql -u root ``` The script will not copy points to tasks that already have a "points" value. If you make a mistake (for example, copy the wrong field) and need to wipe out all the "new" points values in all tasks so you can do another copy of everything, you can use this query: ```lang=sql /* DANGEROUS! DESTROYS DATA! */ UPDATE phabricator_maniphest.maniphest_task SET points = null; ``` That will destroy the "new" points, but leave any custom points untouched. Then you can use `copy_points.php` again to do a fresh copy. Here's the actual script: {P1940} --- > **Migration Tools**: There are currently no tools to move existing projects underneath other projects (e.g., convert existing project "A" to be a subproject of "B"). We may build these if there's interest. | Registering my interest for being able to move projects into being sub-projects. See https://phabricator.wikimedia.org/project/profile/483/ for an example of using faked sub-projects (with, collectively, thousands of tasks) which I'd love if possible to make "real" without making ten thousand bulk edits, modifying long-dead tasks and melting people's inboxes. Should I file a specific task? Yeah, why don't you file a separate task for the importer thing. I saw https://phabricator.wikimedia.org/T123078 on WMF recently, too. I think there will probably be enough demand for this to bring something formal upstream, but maybe only a few installs care (or everyone has different weird requirements) and we can just throw a script up somewhere and not have to maintain it.

Script For Copying Points From a Custom Field ------------------------------------------------------- This script emits SQL you can use to copy an existing custom "Points" field into the new first-class "Points" field. To run this script: - Put it in `phabricator/` - Make it executable with `chmod +x copy_points.php` - Run it as `./copy_points.php` - It will walk you through giving it the information it needs, primarily a `--field <field key>` argument to pick which field to copy from. The script just emiprints SQL statements to stdout. It does not touch the database, so **running it won't make any actual changes** to the data. Here's an example run: ``` $ ./copy_points.php --field std:maniphest:birthday UPDATE `phabricator_maniphest`.`maniphest_task` SET points = 238 WHERE id = 216; ``` Generally, the migration process will probably look something like this: - Run the script. - Look at the output SQL to make sure it seems OK. - Load a couple of tasks to double-check (e.g., for the output above, load `T216` in the web UI and make sure it should have 238 points). - Pipe the SQL into MySQL to actually run it. That might look like this: ``` $ ./copy_points.php --field whatever > points.sql $ cat points.sql # Look at the results and sanity check them. $ cat points.sql | mysql -u root ``` The script will not copy points to tasks that already have a "points" value. If you make a mistake (for example, copy the wrong field) and need to wipe out all the "new" points values in all tasks so you can do another copy of everything, you can use this query: ```lang=sql /* DANGEROUS! DESTROYS DATA! */ UPDATE phabricator_maniphest.maniphest_task SET points = null; ``` That will destroy the "new" points, but leave any custom points untouched. Then you can use `copy_points.php` again to do a fresh copy. Here's the actual script: {P1940} --- > **Migration Tools**: There are currently no tools to move existing projects underneath other projects (e.g., convert existing project "A" to be a subproject of "B"). We may build these if there's interest. | Registering my interest for being able to move projects into being sub-projects. See https://phabricator.wikimedia.org/project/profile/483/ for an example of using faked sub-projects (with, collectively, thousands of tasks) which I'd love if possible to make "real" without making ten thousand bulk edits, modifying long-dead tasks and melting people's inboxes. Should I file a specific task? Yeah, why don't you file a separate task for the importer thing. I saw https://phabricator.wikimedia.org/T123078 on WMF recently, too. I think there will probably be enough demand for this to bring something formal upstream, but maybe only a few installs care (or everyone has different weird requirements) and we can just throw a script up somewhere and not have to maintain it.