Daily updates from Odoo
Monday, September 9, 2024
16 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
9 changes
New functionality added to Odoo
Users can now choose whether an Engineering Change Order should update a product version when it is applied. This gives teams more control over product lifecycle changes and avoids unnecessary version changes when an ECO does not require one.
Original PR description
With this Commit : -------------------------------------- -Introduced a new checkbox in the ECO form allowing users to choose whether to update the version when applying the ECO. -This feature provides greater flexibility for users by giving them control over version updates during the ECO process. Task id : 3962137
Enhancements to existing features
The contract form now always shows the salary attachment button, even when no attachments exist yet. Users can also create new salary attachments directly from the contract, making payroll setup and maintenance faster and more convenient.
Original PR description
This PR improves the contract form view by making the salary attachment button visible even when there are zero attachments. Additionally, it allows users to directly create new attachments from the contract form view. task-4096116
This change adds support for the newer Font Awesome 6 icon set while keeping the existing Font Awesome 4 icons available. It helps preserve compatibility for current screens and customizations while enabling newer icon choices in the web interface.
Original PR description
https://github.com/odoo/odoo/pull/179626
Engineering changes can now be applied without automatically increasing the product or Bill of Materials version number. This gives teams more control over when version numbers change while keeping the existing automatic update behavior as the default.
Original PR description
Sometimes users don't want an ECO to affect the version number of a product/BoM when it is applied, so we add in the option to avoid it. By default we leave `will_update_version=True` so that the current behavior is still the default behavior. This involved manually updating code in several places to ensure this behavior occurs for many different flows including: - create BoM ECO from MO, - applying rebase/conflict resolve due to orig BoM change or new BoM created by another ECO - ECO for a product Note that: - the new BoM version will auto-update when the option is activated/deactivated so that the number matches the final applied version number and is easier for the user to keep track of it. - The Update BoM (for an out of date BoM) logic has been updated to consider newer BoMs with the same version number (i.e. we still expect the previous BoMs to still be archived like the previous flow) Task: 3962137
Colombian companies can now automatically retrieve daily currency exchange rates from Banco de la Republica. This reduces manual updates and aligns exchange rates with the source commonly used by local customers.
Original PR description
The Colombian localization does not have a provider for automatic currency rates yet. This commit implements the API of the Banco de la Republica (because most of the Colombian clients already use this rate) to get the daily rate. task: 4043989
The Documents app now avoids an extra server lookup when showing certain error dialogs. This reduces the risk of server overload when many errors happen at once and helps prevent repeated error loops.
Original PR description
This commit removes the orm call which provides the id of the support folder to the error dialog and replaces it by a simple isAdmin check. The reason for this change is that in case of multiple tracebacks triggered at the same time, it could overload the server with orm calls which could also trigger more tracebacks in an infinite cycle.
When the salesperson on a subscription is changed, the linked customer record is now updated to match. This keeps customer ownership aligned during subscription changes and when confirming subscription quotations, reducing manual follow-up and reporting mismatches.
Original PR description
Before this commit, when salesperson on subscription is changed we do not change salesperson for customer related to that subscription. After this commit, update salesperson on customer if salesperson on subscription is get changed. update salesperson on customer while confirming subscription quotation. task-3891309
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
Code cleanup and technical improvements
The Mexican delivery EDI stock functionality has been consolidated into the main stock EDI module because the extended address data is now required for the feature to work. This simplifies module setup and ensures businesses using Mexican delivery EDI have the required data and validations available in one place.
Original PR description
To use the mexican delivery EDI, it is now required that we have the address field from the mx_edi_extended (the module that stock_extended previously additionally depends on). Using base mx_edi_stock without the extended module will not work anymore. With that in mind, it is now a good time to make the base stock depends on extended and merge everything from the stock extended to the base stock module, including the recently merged stock_extended_31 module. task-id: 3894340
5 changes
Enhancements to existing features
This update prevents the system from sending assignment notification emails when recurring subscription invoices are created. Previously, the system could send thousands of unnecessary emails depending on database size. The change maintains proper communication consistency by keeping the same salesperson assigned to invoices as they are on the original subscription order.
Original PR description
Before this commit, assignment emails are sent when an account.move is created with a different user_id than the current one. For subscriptions it can send thousands of email depending on the database size. The user_id on the account.move is the same salesperson than the one in charge of the sale.order. It helps the consistency of communication between the customer and the company. taskid: 4096474
This update improves how bills are matched in the GSTR 2B tax return process by allowing a small Rs. 1 tolerance for amount differences and better handling of bill reference numbers with special characters. This reduces unnecessary bill creation from minor discrepancies like paisa differences, making the tax filing process more accurate and efficient.
Original PR description
Description: - This PR introduces an Rs. 1 tolerance for amount matching to prevent unnecessary bill creation for minor discrepancies (e.g., paisa differences). It also improves bill reference number matching by handling special characters and comparing numerically as text. Impact: - Reduces unnecessary bill creation. - Enhances accuracy in matching bill reference numbers. Task ID: 3975209
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