Daily updates from Odoo
Monday, September 9, 2024
6 changes
2 changes
Resolved issues and error corrections
Changing the language from My Profile could trigger an error when an unsaved invoice screen was open. This fix prevents that crash, allowing users to save their profile language preference without interruption.
Original PR description
When the user changes the language in My Profile and tries to save, a traceback will appear. Steps to reproduce the error: - Install ```account_accountant``` and ```hr``` module - Activate multi…
When the user changes the language in My Profile and tries to save,
a traceback will appear.
Steps to reproduce the error:
- Install ```account_accountant``` and ```hr``` module
- Activate multi languages
- Go to accounting > Dashboard > New Invoice
- Click on the profile icon > My Profile > Change language > Save
Traceback:
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5851, in ensure_one
_id, = self._ids
ValueError: Expected singleton: account.move('n', 'e', 'w')
File "odoo/http.py", line 2254, in __call__
response = request._serve_db()
File "odoo/http.py", line 1829, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1849, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1827, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1834, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2059, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/action.py", line 96, in load_breadcrumbs
display_names.append(Model.browse(record_id).display_name)
File "odoo/fields.py", line 1202, in __get__
record.ensure_one()
File "odoo/models.py", line 5854, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/59985860264f7fbd2726a51ff15d7e5101ae8234/addons/web/controllers/action.py#L97
Here, when the user changes the language and tries to save the record.
we received record_id as ('n', 'e', 'w'),
when it tries to access display_name
So it will lead to the above traceback.
This issue is similar to https://github.com/odoo/odoo/pull/163087
sentry-5135218331
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes stock transfer issues where inter-company moves could update the wrong destination location, helping keep inventory quantities accurate. It also removes duplicate lot/serial number fields in receipt details when both creation and existing lot options are enabled, reducing confusion for warehouse users.
Original PR description
Fixes the following issues: - When moving products to the 'Inter-company transit' location, products were effectively moved to the 'Customers' location instead. - ~Unable to see lots/serial numbers in locations having no company, such as the 'Customers' location.~ - Duplicate 'Lots/Serial numbers' field in the move details if both 'Create New' & 'Use Existing One' options are picked in the reception picking type. - ~'No operation made on this lot.' is always displayed in the traceability report after a reload, requiring to leave then re-enter the report instead.~ More information on each issue in its corresponding commit. task-3853055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
Belgian SODA imports with incorrect VAT details will now continue instead of stopping the process. The system creates the journal entry and records VAT-related issues in the chatter, helping onboarding and testing proceed with clearer follow-up information.
Original PR description
The blocking message for importing a soda with wrong VAT is not needed as it blocks onboarding or testing. Instead of blocking, create the journal entry and log VAT related errors in the chatter. task-4072804
3 changes
Resolved issues and error corrections
Corrected a payroll calculation error in the Belgian localization where employees on extended leave (such as maternity leave) were incorrectly receiving representation fees meant to compensate work expenses. The fix ensures representation fees are only paid when employees have actually worked, not when they are on leave regardless of paid public holidays during that period.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Belgian localization; 2. create a public holiday; 3. have a contracted employee with CP200 salary structure; 4. make sure they get representation fees; 5. create a month-long maternity leave overlapping the holiday; 6. generate a payslip for that month. Issue ----- Employee receives representation fees, meant to compensate work expenses, despite not having worked that month. Cause ----- Representation fee calculation is currently based on "paid days" rather than days where the employee worked. As maternity leave is unpaid, the employee would normally not get representation fee, but because of the paid public holiday, the calculation continues as if the worker wasn't on leave. Solution -------- Check the `work_entry_type_id` of worked days, and skip representation fee calculation if all have `is_leave` set to `True`. opw-3908980 Forward-Port-Of: odoo/enterprise#68462
This fix resolves an access error that prevented users with Billing rights from using the vendor QR code scanning feature. The QR scan functionality now works correctly for all authorized billing users, improving their ability to process vendor bills efficiently.
Original PR description
Before this commit: When a user with Billings rights scans a QR code using the vendor QR scan feature, an ir.act.window access error appears. After this commit: We fix the access error. And the QR scan feature works correctly as intended.
This fix corrects an issue where the EC Sales report was displaying an incorrect country code (e.g., "A1" instead of the actual country code) when processing customer VAT numbers. The system now uses the customer's actual country code instead of trying to extract it from the VAT number, ensuring accurate reporting for cross-border sales.
Original PR description
Steps to reproduce: [l10n_be] - Create a customer from Spain with the following VAT: A12345674 - Create an invoice with the customer - Go to EC Sales report Issue: The country code used in the report is "A1" Solution: Instead of inferring the country code from the VAT, we use the country code per se; to be a bit more defensive we fall back on the initial flow in case there is no country code. opw-4080828 Forward-Port-Of: odoo/enterprise#69125