Friday, May 10, 2024
3 changes · 17.0
Resolved issues and error corrections
This fix ensures that quality control checks of type "by operation" cannot be bypassed during the completion process. Previously, the system was not applying the same validation rules when marking operations as done as it did when initially checking quality. Additionally, the quality control wizard now displays serial numbers correctly instead of showing "False" when no lot name is present.
Original PR description
- Use same checks in _action_done() as are used in check_quality() - Quality check wizard shows '- False' instead of Serial number in title if no lot_name This bug has been reported to Odoo with **ticket #3815941** (initial ticket #3839794 was rejected because the license number was linked to v13)
This fix prevents a critical data loss issue that occurred when editing generic website pages that had been customized for specific websites. Previously, changes made to a generic page would accidentally overwrite content on the customized version, causing users to lose their work without realizing it. The fix ensures that generic pages with customized versions are handled correctly to prevent this unintended data replacement.
Original PR description
In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore…
In the case of a generic page and its specific page: When the specific page change its URL, its view will still have the sam key as the generic page despite not being served on the same URL anymore and not really being the same ressource anymore. This is a bit weird conceptually. Indeed, the generic page is not shadowed by the specific one anymore. This is an issue because when going on the generic page and editing it, the save will actually "bug": it will not write on the generic view that you edited but the save will instead be "redirected" (through the COW mechanism) to the specific view. The editor will look like it did not save your change, while in fact it actually erased, behind the scene, the specific page content and replaced it by the one you tried to save on the generic page. You really just lost your specific page content without knowing it. This is a corner case of the COW mechanism and the holy grail rule of multi website (editing a website should only impact itself and not other websites): we serve both the generic content and its specific content on the website, which should never be possible except for this particular case of a view being linked to a page and the specific view's page having its URL changed. Note that an apparently good solution would be to adapt the view key to reflect its new page URL (as when you create a new page), but it's not possible. We don't do that for a simple reason: the page view's key could be xpath'd. And it is even the case for the contactus page. Even if it is not a very legit flow to xpath a page view, because it makes (most of the time) that page not possible to edit, we have to support it. Also note that a generic page is not something supposed to exist, even if we support it (and use it for /contactus), it's best to avoid it: 1. You can't do that through the UI unless going into debug mode 2. It does not make a lot of sense to share a whole page content on multiple websites, as it would duplicated content (bad for SEO). Steps to reproduce: - Go to /contactus and enter edit mode - Change something like add "WEBSITE1" somewhere in the page - Open the page properties and change the url from /contactus to /contactuswebsite1 - Go to /contactus, which will still be available and now show the generic page - You will not see the "WEBSITE1" you added, which is what is expected as this is the generic page, the "WEBSITE1" is on the /contactuswebsite1 page - Enter edit mode and add something, like "GENERIC", save - The page will reload (as you saved) but your "GENERIC" will disappear, looking like it did not save your change - Now go to /contactuswebsite1, you will see that the "WEBSITE1" word is gone, and the "GENERIC" word is there On top of the following OPWs, the bug was also reported internally on discord. opw-3760257 opw-3473923 task-3476840 Forward-Port-Of: odoo/odoo#163038 Forward-Port-Of: odoo/odoo#159297
This fix resolves a critical issue where IoT devices connecting to Odoo version 16 and later would fail to start due to a missing software library (num2words). Instead of requiring customers to rebuild their IoT device images, the system now handles the missing library gracefully by importing it only when needed, ensuring IoT devices can continue operating without interruption.
Original PR description
Before this commit: Any IoT-box syncing to a version 16 (and >) database would not be able to start odoo service due to the `num2words` missing library. This is in practice the fault of the IoT as this library is part of odoo requirement. But to solve it it would need to recreate an IoT box OS image and asking customers to re-flash their SD card which is not convenient and time consumming. After this commit: Import conditionally num2words opw-3902183 Forward-Port-Of: odoo/odoo#165067