Thursday, October 17, 2024
17 changes · 17.0
Resolved issues and error corrections
A test in the analytic module is now skipped in specific installations where Timesheets changes required data expectations. This avoids false test crashes for setups using Field Service or Timesheet Grid without Accounting, improving stability without changing business behavior.
Original PR description
Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a default rule, we skip the test if account is not present but hr.timesheet is. runbot-100530
The Argentine withholding chart templates were corrected so the same taxes no longer appear more than once. This prevents duplicate tax entries when installing the module and keeps the setup aligned with the standard Argentine localization structure.
Original PR description
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located…
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12) 2- We moved the taxes from files to match the same structure as l10n_ar Current behavior before PR: After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates. [[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a) Desired behavior after PR is merged: The taxes are no longer duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures a required analytics setup record is created during timesheet testing instead of assuming sample data is already present. It improves test reliability and helps prevent false failures in validation environments.
Original PR description
The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608
Fixes an issue where sending payment status to Viettel SInvoice could fail when there were no invoice records to process. This prevents an error message from interrupting users and makes the action safer to run in Vietnamese invoicing workflows.
Original PR description
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing >…
When User Clicks on Send payment status to SInvoice action,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
Send payment status to SInvoice
Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(2134,)", line 3, in <module>
File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
self.env['res.company']._with_locked_records(self)
File "addons/account/models/company.py", line 785, in _with_locked_records
self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
```
https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.
This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.
sentry-5954926261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPoint of Sale receipts now show the intended delivery date regardless of the cashier's time zone. This prevents customers, especially in regions west of GMT, from seeing a delivery date printed one day earlier than expected.
Original PR description
## Steps to reproduce - Go into point of sale app - Enable delivery later from the settings - Sell a product with a shipping later set in the future - See the expected delivery date on the printed receipt. Note that, normally you will be able to reproduce on any device running in a timezone GMT-, however, for GMT+ timezones, I think there's no good way to reproduce this (please see explanation below) ---- When creating the date with `DateTime.fromJSDate(new Date(yyyy-mm-dd))` , javascript will create it at time 00:00 in the UTC timezone, so for users with negative timezone offset (GMT-x), `formatDate` will print the the date as one day behind. It’s the case for American users for instance. Now, we create the date using `DateTime.fromSQL(yyyy-mm-dd)`, it will be created at 00:00 in the local time zone (not the UTC timezone anymore), and printing it with `formatDate` will therefore yield the correct value expected by the user. opw-4116982
The restaurant point of sale now only shows the edit floor plan option when at least one floor has been set up. This prevents users from opening editing tools that cannot work and could previously cause errors.
Original PR description
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the edit plan button will be visible.
The bank reconciliation report now ignores zero-amount transaction lines so it no longer crashes when a bank transaction has no value. This keeps the report accessible for users and avoids an error during reconciliation review.
Original PR description
### Steps to reproduce the issue: 1. Create a bank transaction and give it an amount of 0 2. Open the reconciliation report in the additional menu of the bank tile 3. An rpc_error occurs with a…
### Steps to reproduce the issue: 1. Create a bank transaction and give it an amount of 0 2. Open the reconciliation report in the additional menu of the bank tile 3. An rpc_error occurs with a division by 0 > File "[...]/account_reports/models/bank_reconciliation_report.py", line 158, in build_result_dict > reconcile_rate = abs(res['suspense_balance']) / (abs(res['suspense_balance']) + abs(res['other_balance'])) > ZeroDivisionError: float division by zero ### Explanation: When the report is created, it will retrieve all `account_move_line` from the `account.journal` dedicated to bank transactions and calculates a rate by dividing the balance of lines from `account.journal.suspense_account_id` with the balance of all lines. https://github.com/odoo/enterprise/blob/1ce5a2cf747f2fbe8b2f46c9d5298e1e420f83ea/account_reports/models/bank_reconciliation_report.py#L140-L144 This division is not protected by a verification of the values equalling to 0 in one of the cases. https://github.com/odoo/enterprise/blob/1ce5a2cf747f2fbe8b2f46c9d5298e1e420f83ea/account_reports/models/bank_reconciliation_report.py#L157-L159 ### Fix reasoning: `account_move_line` with a `balance` of 0 can be ignored when creating the report, after discussion with PO. The protection becomes unnecessary as well and can be removed totally. opw-4178134
This update ensures that the Documents field in projects displays a consistent label across all installations. Previously, the label would vary depending on which modules were installed, which could cause confusion. Now it will always show "Documents" for clarity and consistency.
Original PR description
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
This update corrects and cleans up translations in German localization modules for account follow-up and field service management. These improvements ensure that German-speaking users see accurate and consistent text throughout the application, enhancing the overall user experience.
Original PR description
*l10n_din5008_account_followup, l10n_din5008_industry_fsm Related to: https://github.com/odoo/odoo/pull/183268 Forward-Port-Of: odoo/enterprise#71710
Miscellaneous changes
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Original PR description
revert commit 30c561b422d58d7622f7ee173fae2f8158a14657 because it broke existing optimization and users were unable to access the website instead the functionality was moved to `_get_pl_partner_order()` because it's a cached method and the extra search added by the `.sorted()` wouldn't be an issue. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183805
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make SO and add the same product to order line. - In the Product Configurator, there is no strikethrough price. Issue: When the comparison price is activated the strikethrough price is not visible in the product configurator Cause: There was no `compare_price_list` in the template, hence the co
Original PR description
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make…
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make SO and add the same product to order line. - In the Product Configurator, there is no strikethrough price. Issue: When the comparison price is activated the strikethrough price is not visible in the product configurator Cause: There was no `compare_price_list` in the template, hence the comparison price was never visible. Fix: - Added the `compare_price_list` to the template using XPath because `compare_price_list` is added to the `combination_info` dictionary in the website_sale module and made it conditionally hidden using `t-if` (not with `d-none` as we do for other cases) because the same product configurator template is being used in the backend (like while making a Sale or Rental order) where the `compare_list_price` is not present in `combination_info` which gives a key not found error. opw-3992683 Forward-Port-Of: odoo/odoo#171354
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#183268
Original PR description
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/71710 Forward-Port-Of: odoo/odoo#183268
Reproduce --- - -i event_crm_sale,website_event_questions - Create new "Lead Generation Rule" (Events/Configuration/Lead Generation) - "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]` - add some tag - Add new attendee to an EVENT - Add new question to the EVENT - BUG: `KeyError: 'registration_answer_ids'` opw-4125944 Forward-Port-Of: odoo/odoo#179734
Original PR description
Reproduce
---
- -i event_crm_sale,website_event_questions
- Create new "Lead Generation Rule" (Events/Configuration/Lead Generation)
- "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]`
- add some tag
- Add new attendee to an EVENT
- Add new question to the EVENT
- BUG: `KeyError: 'registration_answer_ids'`
opw-4125944
Forward-Port-Of: odoo/odoo#179734- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166499
Original PR description
- Add new tax groups, fiscal positions and taxes for retentions of not residents. - Add configuration to send SII in new taxes. https://sede.agenciatributaria.gob.es/Sede/nuevasede.html @rafaelbn @arantxasudon @moduon MT-5974 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166499
Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#183614
Original PR description
Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#183614
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that
Original PR description
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a…
*: test_website Since [1], the code responsible for resetting broken view failed to consider that during a "hard" reset, the 'arch_updated' field should be set to False. Steps to reproduce (on a local server): - Activate the developer mode - Navigate to Website and click on "Go to Website" - Click on the menu "Pages" > "Manage Pages" - At the /contactus line, click on the "bug" button to access the view - Click on "Edit" to be able to change the architecture - Add something that breaks the view in the template (i.e : ```<p t-field="no_field.exists"></p>```) - Click on "Save" and after "Go to Page Manager" - Click on the /contactus url link - An internal server error page appears with the possibility to restore the previous version of the view (soft reset) or to reset to initial version (hard reset). Click on "Hard Reset" - With your DB manager, search in the table ir.ui.view, the record with the key website.contactus. Observe that the field arch_updated is still True while the view is reset and shouldn't be in an updated state. This commit ensures consistent updating of this field. A "Hard" reset of a broken view will remove its previous architecture used for "Soft" reset, since there is no real usage where a "Previous" reset is needed after a "Hard" one. [1]: https://github.com/odoo/odoo/commit/479585140caca9fdc758709f043da500297e8046 task-3743850 Forward-Port-Of: odoo/odoo#164929
## Issue: - when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice. ## Steps To Reproduce: On POS, for an order totaling $120. - Add a customer and ensure the "Invoice" box is checked. - pay using two payments methods bank 100$ Cash 50$ - the change is $30, everything looks fine on the ticket on the pos. - Notice on the invoice on the db backend the $30 change is in
Original PR description
## Issue:
- when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice.
## Steps To Reproduce:
On POS, for an order totaling $120.
- Add a customer and ensure the "Invoice" box is checked.
- pay using two payments methods
bank 100$
Cash 50$
- the change is $30, everything looks fine on the ticket on the pos.
- Notice on the invoice on the db backend the $30 change is incorrectly deducted from the bank payment. As a result, the invoice displays:
bank : $70
cash: $50
## Soltution:
- In the _create_payment_moves method, I ensured that an `account.move` is not created for the change amount. Instead, the change is deducted from the first cash payment before creating the relevant `account.move`.
opw-4076246
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#176342