Thursday, October 17, 2024
9 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