Thursday, December 5, 2024
17 changes · saas-17.4
Resolved issues and error corrections
This fix prevents internal overlay settings from being treated as live reactive data. It helps avoid unnecessary screen refreshes and potential crashes, improving reliability in the Odoo web interface.
Original PR description
Commit [1] allowed to pass the env to overlays, as a prop. However, when doing so, the env was inserted in a reactive array (`overlays`) which thus made it reactive as well. That reactive env was then used as childEnv for the overlay items. Having a reactive env isn't a good idea, relying on this isn't either. Indeed, changes in the "non reactive" env wouldn't be taken into account. Moreover, it can lead to unexpected excessive re-renderings, or even to crashes (a reactive object is a proxy, and for instance, calling `difference` on a Set wrapped in a proxy crashes). [1] odoo/odoo@7851d85f26c525a90fdb1131c5e4d51a6b140c13 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
PDF pages that were originally rotated now display correctly when users split a document. This prevents confusing previews and helps users split scanned or rotated PDFs accurately in the Documents app.
Original PR description
To reproduce: ============= 1. Go to Documents app 2. Upload a PDF file (one of the attached on the opw) 3. Click on the file to open it 4. Click on the "Split" button the pages on the preview are not displayed correctly Problem: ======== these pdf files, the pages are rotated by 270 degrees so when splitting the pages, the rotation is not taken into account and set to 0 degrees Solution: ========= - set the rotation of the pages to the original rotation when splitting the pdf opw-4216158
Miscellaneous changes
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when impo
Original PR description
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when importing a chart of accounts on a new company, the import of the opening balances causes a new 'Unaffected Earnings' account to be created via `_load_records`, with `noupdate=True`.[^1] [^1]: https://github.com/odoo/odoo/blob/a73e45ff9459ffdc0128327fac47962c6fe27af7/addons/account/models/company.py#L473 task-none runbot-108001 Forward-Port-Of: odoo/odoo#189449 Forward-Port-Of: odoo/odoo#185030
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException> Traceback (most recent call last): File "concurrent/futures/_base.py", line 340, in _invoke_callbacks callback(self) File "odoo/odoo/tests/common.py", line 1532, in handler
Original PR description
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling…
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of
concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException>
Traceback (most recent call last):
File "concurrent/futures/_base.py", line 340, in _invoke_callbacks
callback(self)
File "odoo/odoo/tests/common.py", line 1532, in handler
base_png = f.result(timeout=0)['data']
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 449, in result
return self.__get_result()
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
odoo.tests.common.ChromeBrowserException: Internal error
As this is mostly unhelpful, handle the thing better, and lower the concern to `RUNBOT`: giving prominence to the screenshot failure is probably less relevant than the actual reason why we tried to take a screenshot in the first place?
Forward-Port-Of: odoo/odoo#189585Added base localization package for Lebanon 🇱🇧 , it includes the following: - Chart of Accounts - Taxes - Fiscal Positions Task: - 3927914 --- Forward-Port-Of: odoo/odoo#184602
Original PR description
Added base localization package for Lebanon 🇱🇧 , it includes the following: - Chart of Accounts - Taxes - Fiscal Positions Task: - 3927914 --- Forward-Port-Of: odoo/odoo#184602
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have sig
Original PR description
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187915
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/
Original PR description
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/63cf8a693a5262600d465d70f0383229464d71e7 task-4094393 Forward-Port-Of: odoo/odoo#189156
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneo
Original PR description
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure…
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneous message to the IoT Box or to the Blackbox, all checkouts would become blocked, with the only alternative being to reload the handlers or restart the IoT Box. Furthermore, the subsequent actions appearing as refused may have executed successfully. Which means there would be a mismatch between the data stored in Odoo (multiple failed transactions) and the data sent to the SPF (one failed transaction, then many successful ones). After this commit, the driver status is reset after being sent once. That way, when a new action is sent from the client to the IoT box, it's the status of the execution of this action and not the previous one that gets sent back to the client. opw-4313538 opw-4182434 opw-4293988 Forward-Port-Of: odoo/odoo#189062 Forward-Port-Of: odoo/odoo#186735
Steps: - Create a new helpdesk team. - Open tickets of that team. - Delete all ticket stages Issue: - If all the stages are deleted then the blank screen appears instead of shadow data. Cause: - Only `helpdesk.ticket` was being validated, but `helpdesk.stage.delete.wizard` was not included in the check. Fix: - The issue has been fixed by replacing active_model with default_team_id. task-4290529 Forward-Port-Of: odoo/enterprise#75199 Forward-Port-Of: odoo/enterprise#72954
Original PR description
Steps: - Create a new helpdesk team. - Open tickets of that team. - Delete all ticket stages Issue: - If all the stages are deleted then the blank screen appears instead of shadow data. Cause: - Only `helpdesk.ticket` was being validated, but `helpdesk.stage.delete.wizard` was not included in the check. Fix: - The issue has been fixed by replacing active_model with default_team_id. task-4290529 Forward-Port-Of: odoo/enterprise#75199 Forward-Port-Of: odoo/enterprise#72954
Withholding tax information is missing when printing report 'Delivery Guide SII DTE 52 (CL)' from a delivery Steps to reproduce: - With a CL Company setup - Have a product with main 19% tax and a withholding tax - Create a SO with the product - Confirm - Open Delivery - Validate - Print menu > Delivery Guide SII DTE 52 (CL) Issue: Only VAT 19% tax is present in the report, withholding tax is missing (even if the total is correct) This occurs because the 'withholding' var is inside
Original PR description
Withholding tax information is missing when printing report 'Delivery Guide SII DTE 52 (CL)' from a delivery Steps to reproduce: - With a CL Company setup - Have a product with main 19% tax and a withholding tax - Create a SO with the product - Confirm - Open Delivery - Validate - Print menu > Delivery Guide SII DTE 52 (CL) Issue: Only VAT 19% tax is present in the report, withholding tax is missing (even if the total is correct) This occurs because the 'withholding' var is inside another dict Issue2: 'tax_name' is not present in the rendered data, so we need to add it Issue3: withholding amount will be shown without associated currency opw-4214377 Forward-Port-Of: odoo/enterprise#74979 Forward-Port-Of: odoo/enterprise#73926
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created Forward-Port-Of: odoo/enterprise#74829 F
Original PR description
### Before this PR: If you create new internal transfer with src location WH/Stock and than you scan a package that is on a sublocation of WH/Stock , the source location on the line is not set as the location of the package so when you validate in this situation an error pops because Odoo try to take the package from a different location of the package ### After this PR: The right location id is taken from the stock.quant and put on the line created Forward-Port-Of: odoo/enterprise#74829 Forward-Port-Of: odoo/enterprise#74704
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will
Original PR description
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1.…
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage. 6. back in the POS, create a new order (any table) 7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5 The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2. What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders. After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split. opw-4367937 Forward-Port-Of: odoo/enterprise#74816
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed
Original PR description
Currently, when using a language that translates the abbreviation of quarters (Q) to anything else, the formula `=filter.value(...)` would return the translated version, which then could not be used on other formulas like `=odoo.balance`, this can be observed by opening the Finance/accounting dashboard while in french and selecting a filter in quarter. After this fix, the formula filter.value will always return Q1 to Q4 for quarter names. Task: 4274741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187140 Forward-Port-Of: odoo/odoo#187043
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Schedule the "Calendar: Event Reminder" to run once a day; 2. create an event that started 2 hours ago, and ended 1 hour ago; 3. run the event reminder cron. Issue ----- A reminder email is sent, event though the event has passed. Cause ----- The alarm manager doesn't check whether the reminders it sends are still relevant. Solution -------- When looking querying events to send reminders for, ensure their `stop` date is before the current time. opw-4191612 Forward-Port-Of: odoo/odoo#189479 Forward-Port-Of: odoo/odoo#189340
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "
Original PR description
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "Navbar" option. - Click the "Mobile Preview" button. - Click the "Hamburger menu" button to open the mobile navbar. - Bug: The text color is not "red". [1]: https://github.com/odoo/odoo/commit/1e30600d9e0e12e43fcbca60760a64f2551e3c8f opw-4364765 Forward-Port-Of: odoo/odoo#189417
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467