-
-
Notifications
You must be signed in to change notification settings - Fork 685
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ADD] calendar migration #112
Conversation
[IMP] use renamed modules from openupgrade_records
[IMP] adapt spelling/fomratting in rst file
@@ -50,7 +50,7 @@ Status : | |||
+-----------------------------------+-----------------------------------+ | |||
|account_test | Nothing to do | | |||
+-----------------------------------+-----------------------------------+ | |||
|account_voucher | done | | |||
|account_voucher | Done | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be due to a bad rebased. Please check it.
I don't see where |
cr.execute( | ||
'alter table calendar_event add column %s int' % ( | ||
openupgrade.get_legacy_name('crm_meeting_id'), | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pedrobaeza here i create the column
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I see now the trick.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But don't you think this should be on crm migration script instead here? You can for example install hr_holidays, that depends on calendar, but not crm, making this script fails.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not really. crm.meeting was defined in base_calendar in 7.0, so you'll have that for every module depending on base_calendar. This is also why migrating it belongs into this migration script.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the explanation.
Very good work. 👍 |
Well done! Please include the changes to ir_cron_scheduler_alarm as printed by scripts/compare_noupdate_xml_records.py from the 7.0 server edition. |
%s, calendar_alarm.id | ||
from calendar_alarm join res_alarm | ||
on %s=res_alarm.id | ||
where %s=%s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While you make work to migrate the links to the old calendar alarms, don't you need to migrating the existing res.alarm records to calendar.alarm?
@StefanRijnhart thanks for your pointers. The alarm migration was completely misguided, now I got it right I think. res.alarms by themselves never did anything, so I don't think there's something to migrate. But we need to migrate the relation between events and alarms and between meetings and alarms, that happens now. |
in function
But how can this work without breaking foreign key constraints ? Your I do get Sorry if I missed something important. Would be happy if you cleared out my mind on this topic. |
thanks, you missed nothing. This worked in my test database out of simple coincidence |
the commit above should fix it |
thx, the full calendar migration works now on my database. (~7000 crm_meetings) |
Having some issues with calendar migration as well not sure if its the same as the thread above. Trying to migrate from 7.0 to 8.0 . |
No description provided.