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

[flotho]

Hi everyone,

This one seems really weird. First I suspected that Odoo CE has removed FK in fresh databases : odoo/odoo#18880.
Yet starting with a fresh install with no specific addons in path make the things going well. Then repo by repo I added the dependencies and try to create new DB.
At last, this repo OCA/pos seeems to cause a creation with no Foreign keys.
I've updated the latest OCA/pos check all the depenecies, requirements etc, try many times to create with or without the dependencies. The result is the same, using OCA/pos cause no FK in the db!
Here are the logs, nothing special for me,any help would be appreciated.
odoo.log.txt

[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

[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.

[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" <notifications@github.com> 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> .