[10.0]No more foreign keys in all tables when using this repoo about pos

[guewen]

Worth to note this module has another big design issue. It replaces the Manyone towards pos.category on the field product_template.pos_categ_id by a Many2one towards product.category. As soon as you will want to upgrade the base module point_of_sale, this one will try to create a Foreign Key towards product.category and fail (letting the database blocked in an intermediate state) because the ids might not exist in this table.

IMO this module should either be reworked in a clean way, either be removed.

[StefanRijnhart]

In case you were wondering like I was, this problem did not affect 8.0 or 9.0. The bug was introduced here, during the migration to 10.0, by not returning a call to super but returning only a reference to the super method instead: https://github.com/OCA/pos/pull/158/files#diff-a2bb6a42189587ba52241d71ea03f98eL104

Thank you @flotho for doing all this investigation and pinpointing the problem to this particular module.

[flotho]

Hi,
I made additionnal tests :

• OCA/pos : 10.0 ddfab70 OCA Transbot updated translations from Transifex
• odoo/odoo : 10.0 89cade3bffc [FIX] pos_restaurant: wrap product names on OrderChangeReceipt

Same result, all the FK disappearing from tables, Does anyone reproduce this ?

[pedrobaeza]

Which module from OCA/pos? Check in runbot if it happens the same.

[flotho]

I'm trying each module one by one to identify

[flotho]

Well it looks like that pos_remove_category caused the problem. I'll recheck

[flotho]

Well, I confirm that having the module pos_remove_category cause the problem. I made those tests :

• Creating db with adding module from oca/pos one by one, retsart odoo between each addition
  ** => everything work fine except when pos_remove_category is present in the addons path
• Creating db with all the module except pos_remove_category
  ** => Everything Ok
• creating db with only pos_remove_categ => make FK disappear

i'm suspecting the ir.module.module dependency so that I tried to comment the init part.

There's something I can't log/ identify more without your support. Thanks in advance.
regards

[flotho]

@pedrobaeza it's not really easy for me to try on runbot because no error make the creation failed. Sadly there also nothing special in the logs. The db is created but the table structure haven't got anymore FK. I discovered that when a product.template has been deleted and its associated product.product still living its own ....
not easy to debug this one

[legalsylvain]

Thanks @flotho for reporting this problem.

This line seems to create your bug. (not tested)
https://github.com/OCA/pos/blob/10.0/pos_remove_pos_category/models/product.py#L89

Solution 1 : full refactoring
My point of view is that this module is not very clean, and should be refactored :

• do not alter database.
• while loading product, remove pos_categ_id field, add the product_categ_id, and at the end of the load, initialize the pos_categ_id with the product_categ_id
• drop auto_end function and all product overload.
• product_category.available_in_pos : could be computed. (optional) (if category has products that can be sold in PoS.)

Solution 2 : more easy.

• disable _auto_end function. (The module will not work anymore correctly), but the repo will be safe.

@simone, @sylvainc. Could you take a look ?

Note : this problem is present on odoo8 too.
https://github.com/OCA/pos/blob/8.0/pos_remove_pos_category/product.py#L105

[flotho]

Hi everyone,
Additionnal question, once this module is not present in the addons_path, do you think that an -u all will re-add all the FK on an already created database?
regards

[pedrobaeza]

Yeah, this is very critical. Who was the original author/migrator? Is he/she (or anyone else) going to attend this? If not, we should remove it.

[sylvainc]

Hello, I'can only reply shortly sorry, i have not a easy fix because monkey patching like this (in early startup) is too tricky and must be definitivly avoid , please remove this module. I'll try to find a workarround for the corrupted database. Tanks for reporting My mistake, Regards, Le 21 août 2017 9:53 AM, "Pedro M. Baeza" <[email protected]> a écrit : Yeah, this is very critical. Who was the original author/migrator? Is he/she (or anyone else) going to attend this? If not, we should remove it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#200 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABNlRkb-zwRAp6XfC5CJtbVZ1LE1w2OAks5saTeJgaJpZM4O61bZ> .

[legalsylvain]

Done : PR to review :
8.0 : #201
9.0 : #202
10.0 : #203

[flotho]

Thanks folks, needless to say that it had badside effects on my actual prod databases. Hopefully, -u all re-added all the FK.
regards

[simahawk]

@flotho thanks for spotting this! 👍 for removal.

[legalsylvain]

Thanks @StefanRijnhart for this explanation.

[simahawk]

holy 💩 I'm gonna bury myself... 😢
sorry for the mess guys... 🔫

[Cedric-Pigeon]

@pedrobaeza @sylvainc @flotho @legalsylvain @simahawk Can you restore this addon. The fix is proposed for a long time and works fine... #182

[pedrobaeza]

Please restore the addon and add the patch in your PR, and if everything is correct, we merge at once.

[Cedric-Pigeon]

Please revert your merge, it is more simple. I pointed everyone in my PR months ago.

[pedrobaeza]

Sorry, but we can't allowed a module that breaks whole installation. Restore it in your PR and when merged, everything will work correctly. You can press yourself in revert commit, and GitHub will propose a new PR. Cherry-pick your commit in top of it and it's done.

[Cedric-Pigeon]

Ok you are right. I renamed my PR description and add the revert of the removal.

[pedrobaeza]

Thanks for the understanding, @Cedric-Pigeon

[sylvainc]

Thanks you all