Friday, March 14, 2025
13 changes · 17.0
Resolved issues and error corrections
This fixes the printed Saudi/GCC invoice layout when a customer reference is present. The invoice now keeps consistent text sizing and shows the Arabic reference label, improving document readability and professionalism.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_sa - Switch to a Saudi Arabian company (e.g. SA Company) - Create an invoice without a customer reference - Print the invoice - Create the same invoice with a customer reference - Print the invoice **Issue:** The font size is smaller for the second invoice and the reference label in Arabic doesn't appear. **Cause:** The reference row in the printed invoice is separated in 3 columns like the other information, but the Bootstrap width of the second column is 8 (i.e. col-8) instead of 2. As the first column has an offset of 6 as it is the case for all the rows, the row width exceeds the grid system size (i.e. 12) defined in Bootstrap. opw-4494547 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Posting an attachment in Mail no longer closes the attachment panel when the page content reloads. This preserves the user's workspace and avoids the need to reopen the panel after each upload.
Original PR description
**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects how Swiss payroll validates IDE-OFS company identification numbers using the modulo 11 checksum. It helps prevent valid payroll transmission data from being rejected due to an incorrect validation check.
Miscellaneous changes
When an employee with the "Team approver" role was using the digitization feature on an expense, a user error would be raised when clicking on the "Refresh" button. This is related to commit 92284e7 which added an access right check when writing on the `state` field of the expense. After this commit, only expense managers are allowed to write the state field (except for the "Submit" state). Since the OCR is resetting the expense state to draft it was raising this access right check. Writin
Original PR description
When an employee with the "Team approver" role was using the digitization feature on an expense, a user error would be raised when clicking on the "Refresh" button. This is related to commit 92284e7 which added an access right check when writing on the `state` field of the expense. After this commit, only expense managers are allowed to write the state field (except for the "Submit" state). Since the OCR is resetting the expense state to draft it was raising this access right check. Writing the state to "Draft" should also be allowed as it's obviously not bypassing the validation process. [opw-4613260](https://www.odoo.com/odoo/49/tasks/4613260) Forward-Port-Of: odoo/odoo#201636
Initial PR: https://github.com/odoo/odoo/pull/194141 It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`. For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways: - calling UNLISTEN * and committing - closing the connection - aborting the transaction
Original PR description
Initial PR: https://github.com/odoo/odoo/pull/194141 It seems the fix above was not enough as it was assumed that connection (or backend in pg terms) were NOT being reused when initiated through `sql_db.connect`. For proper cleanup we need to reach [this part of the code](https://github.com/postgres/postgres/blob/REL_16_STABLE/src/backend/commands/async.c#L1260-L1298) which can be done in 3 ways: - calling UNLISTEN * and committing - closing the connection - aborting the transaction (before committing the listen) `UNLISTEN *` is a good candidate for this, but closing the connection seems to be the safer option. Forward-Port-Of: odoo/odoo#201401
Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacu
Original PR description
Description of the issue/feature this PR addresses: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Current behavior before PR: Installing and uninstalling modules may create a lot of garbage in the file store, and that garbage seem to last for too long. In particular, many asset files will be regenerated, and old assets immediately become garbage. Desired behavior after PR is merged: After installation or uninstallation, trigger the autovacuum cron so that it executes ASAP. Ideally, it shouldn't be run before old assets are discarded. So maybe the cron should be triggered after some little delay. task-3970360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197128
For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group opw-4635356 --- I confirm I have signed the CLA and read the PR guidelines at www.odo
Original PR description
For existing customers, when coretax is installed, the new luxury tax group and its tax will not be loaded into Odoo. During XML generation, it will look for the tax group by XML ID which will not be found and hence resulting to traceback error. To mitigate this issue, we will introduce a post_init_hook to manually create the tax group and not raise exception when env.ref() doesn't find the tax group opw-4635356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201523
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 Description of the issue/feature t
Original PR description
In Belgium, certain tax grids (e.g., 81, 82) in the VAT report force negative amounts to 0, as the amounts are carried over to the next period. However, this behavior confuses users, especially VAT experts, as they see 0 instead of the actual negative amount. To improve clarity: - Negative values are now displayed instead of being forced to 0. - The carryover mechanism remains unchanged, and the explanatory infobullet is still displayed. Task-4589150 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 Forward-Port-Of: odoo/odoo#198606
Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195395
Original PR description
Allow to limit to max failures or errors in odoo test suite when environment variable ODOO_TEST_MAX_FAILED_TESTS is set. Above that limit, skip all following tests ODOO_TEST_MAX_FAILED_TESTS must be a non zero int --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195395
- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510
Original PR description
- Fetch photo from `hr.employee.public` to be avail for users without no hr rights Task: 4626795 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200510
The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201489
Original PR description
The export is completely wrong when it comes to multiple taxes affecting each others. It would recompute the withholding taxes one by one based on the price subtotal instead of taking into account all other taxes as you would expect. task-4641930 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201489
If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318
Original PR description
If ´fcm_token´ if invalidated by Google, our OCN service will now be able to save the updated token. https://firebase.google.com/docs/cloud-messaging/manage-tokens Forward-Port-Of: odoo/enterprise#81318
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour:
Original PR description
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x…
To reproduce: - Install delivery_fedex_rest and enter API credentials for FedEx US, also turn on return label generation. - Enable packages in inventory settings. - New delivery to Azure Interior, 1x product 5555, save and Put in Pack (FedEx Box 1kg). - Add another line with 1x product 5555, save and Put in Pack again (FedEx Box 1kg). - Validate the picking. Current behaviour: Crashes when trying to create the return label with nondescript error coming from FedEx. Expected behaviour: Ideally, a correctly validated picking with generated return labels. However, this appears to currently not be supported by the FedEx REST API... (multi-package single-shot return shipments of print label type) We compromise and will create the outgoing shipment as usual, but not the return shipment in case of multi-package shipments. A helpful message informing the user of this limitation will be put in the chatter of the picking instead of the generated return label in this specific case. opw-4556415 Forward-Port-Of: odoo/enterprise#81326