[MIG] hr_recruitment module migration script - #682
Conversation
cubells
commented
Nov 28, 2016
- Added analysis files
- Created pre and post files
* Added analisys * Created pre and post files
|
Hi @cubells Thanks for your work. Could you add in your PR the change of the module coverage file. (set to 'Done' hr_recrutment line.) kind regards. |
|
Done @legalsylvain |
| # Nothing to do | ||
|
|
||
| hr_recruitment / hr.applicant / availability (integer) : type is now 'date' ('integer') | ||
| # Unable to calculate date form a integer --> Nothing to do |
There was a problem hiding this comment.
You should take field create_date and add this number of days to get the new date.
| # Done: Adapt to new range | ||
|
|
||
| hr_recruitment / hr.applicant / source_id (many2one) : relation is now 'utm.source' ('hr.recruitment.source') | ||
| # Nothing to do |
There was a problem hiding this comment.
You need to create an utm.source for each of the existing hr.recruitment.source, as now the object inherits (via delegation) of this object, and fill the corresponding field:
cr.execute('INSERT INTO utm_source ... RETURNING id')
new_id = cr.fetchone()
cr.execute('UPDATE hr_applicant SET source_id = %s WHERE id = %s', (new_id, old_id))
```
| ]} | ||
|
|
||
|
|
||
| def migrate_applicant_source(cr): |
There was a problem hiding this comment.
You should do this on post-migration, as utm.source doesn't have yet the new structure.
| cr, | ||
| openupgrade.get_legacy_name('priority'), | ||
| 'priority', | ||
| [('4', '3'), ('3', '1'), ('2', '0'), ('1', '0')], |
There was a problem hiding this comment.
You must change the map_values order, as this is got iterating over values, so in your current map, you will replace 4 value by 3, and next iteration, the existing 3 and the new 3 will be replaced by 1. You must reverse the mapping.
And another thing, why there's no 2 in the new mapping?
There was a problem hiding this comment.
I do that mapping:
4 is excellent and is mapped to excellent.
3 is good and is mapped to good.
All the others are mapped to normal.
Very good is not mapped.
There was a problem hiding this comment.
But right now three of the old values map to the new 0 (0, 1 and 2). Is that correct?
There was a problem hiding this comment.
yes, It is.
Average, Below Average and Bad are mapped to Normal because there is not another similar value.
| """ | ||
| UPDATE hr_applicant SET availability = %s | ||
| WHERE id = %s | ||
| WHERE id = '%s' |
There was a problem hiding this comment.
You need to do this because you're not using psycopg capability to convert types. You have to do this:
WHERE id = %s
""", (new_date, applicant[0]))
This will also prevent SQL injection possibilities: https://github.com/OCA/maintainer-tools/blob/master/CONTRIBUTING.md#no-sql-injection
| for old_id in cr.fetchall(): | ||
| cr.execute("INSERT INTO utm_source (name) " | ||
| "SELECT name " | ||
| "FROM hr_recruitment_source " |
There was a problem hiding this comment.
You have to rename table to avoid the removal of the significant fields in the update process
There was a problem hiding this comment.
Here you have to access to the migrated table name, not the new one.
| @@ -0,0 +1,18 @@ | |||
| <?xml version='1.0' encoding='utf-8'?> | |||
| <openerp> | |||
There was a problem hiding this comment.
Remove labels openerp data by odoo in v9.0
There was a problem hiding this comment.
This is an automatic file generated by https://github.com/OCA/OpenUpgrade/blob/9.0/scripts/compare_noupdate_xml_records.py, so we can leave it as is for this version and change the script for next one.