Wednesday, May 29, 2024
10 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where scanning a different destination location in batch picking operations would only update the last picked item instead of all items with the same product. Now when a new destination is scanned, all related items in the batch are properly synchronized to the new location, ensuring consistent and predictable barcode scanning behavior.
Original PR description
**Current behavior:** If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some…
**Current behavior:**
If we have a picking batch with some pickings all for the same product, while enforcing mandatory scans on source location, products, and destination location, there is some unexpected behavior if a different destination barcode is scanned after the similar-product pickings have all been scanned.
**Expected behavior:**
With this specific configuration, pickings with the same product should all be changed when a different destination is scanned.
**Steps to reproduce:**
1. In the Internal Transfers picking type, configure the barcode settings like so:
`Source Location: Mandatory Scan`
`Product: True`
`Destination Location: After each product`
2. Create some new internal location (e.g., .../Stock/shelf)
3. Create a new batch picking with 2 internal transfer pickings for the same product
4. Go to the batch operation barcode menu, select the created batch picking
5. Scan the source location, scan the first product code and then manually add the second picking quantity with the add quantity button, scan the newly created internal location
6. Observe that the last picking destination location has changed and the first has not- furthermore trying to change the second's destination location via scan does not work (manual changes via the edit button/form still possible)
**Cause of the issue:**
The method of changing destination does not account for this setup, so there is no specific handling for it. Only the selected line will be modified by a new destination scan.
**Fix:**
Extract the line modification code into a new function and override it in the batch_picking module to change the entire current batch of lines that have been scanned (that all have the same product).
opw-3733870This fix ensures that the subscription modal dialog and its trigger button are always displayed together using the same visibility conditions. Previously, there was a mismatch that could cause the button to appear without the corresponding modal, creating a broken user experience. This fix prevents users from clicking a button that doesn't open anything.
Original PR description
Use the same condition for the modal and button to ensure both are always rendered at the same time and the button cannot be rendered if the modal is not.
This update corrects when the global filter option appears in spreadsheet context menus. Previously, the option was showing up for all pivot formulas, but it should only appear for header-level pivot formulas. This fix ensures users see the global filter option only when it's actually applicable to their spreadsheet data.
Original PR description
The context menu (and clickable cell) `use_global_filter` should take the value of the underlying pivot formula, and apply it to the matching global filters. This works, but was supposed to work only for `ODOO.PIVOT.HEADER` formulas, and not simple `ODOO.PIVOT` formulas. This commit fixes the visibility of the `use_global_filter` option in the context menu, so that it is only visible for `ODOO.PIVOT.HEADER`. Also removed/changed tests that were testing that the menu was visible for positional `ODOO.PIVOT` formulas. Task: [3714696](https://www.odoo.com/odoo/2328/tasks/3714696?cids=1)
This fix resolves an error that occurred when users clicked on the contracts button in job applications that had multiple contracts (one active and one archived). The system was trying to process multiple contracts at once instead of handling them individually, causing the application to crash. Now users can safely view and manage contracts without encountering errors.
Original PR description
When user clicks on contracts smart button in application and if application has two contracts (one archived and one active), a traceback will appear. Steps to reproduce the error: - Install…
When user clicks on contracts smart button in application and if application has
two contracts (one archived and one active), a traceback will appear.
Steps to reproduce the error:
- Install "hr_contract_salary" module
- Go to Recruitment > Applications > All Applications > Create new application >
Generate Offer > Select Contract Template > Send By Email > Send
- Click on Offers > Salary Configurator > Fill all required fields >
Review Contract & Sign > Validate & Send Completed Document
- Open that application > Contracts > Create new contract > Save
- Archived one contract > Click on Contract smart button
Traceback:
```
ValueError: Expected singleton: hr.contract(27, 29)
File "odoo/http.py", line 2253, 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/dataset.py", line 42, in call_button
action = self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "home/odoo/src/enterprise/saas-17.2/hr_contract_salary/models/hr_applicant.py", line 59, in action_show_proposed_contracts
"res_id": self.env['hr.contract'].search([["applicant_id", "=", self.id], '|', ["active", "=", False], ["active", "=", True]]).id,
File "odoo/fields.py", line 5182, in __get__
raise ValueError("Expected singleton: %s" % record)
```
https://github.com/odoo/enterprise/blob/504b3c66a9a8d142b89f9c873675ec65fdb43dd0/hr_contract_salary/models/hr_applicant.py#L59
Here when application has two contracts (one is archived and one is active),
So when it tries to access the id of 2 records.
It will lead to the above traceback.
sentry-5350130147
Forward-Port-Of: odoo/enterprise#62627This fix resolves an incorrect tax validation warning that appeared when generating the Ecuadorian ATS (Anexo Transaccional Simplificado) tax report for invoices with section lines and product taxes. Previously, users would see a misleading "Invoice lines should have exactly one VAT tax" error even though the ATS file would still download successfully. The fix ensures proper tax handling for these invoice configurations.
Original PR description
Create an Invoice for an EC customer hading a section line and a tax on the product line Confirm the invoice Add Withholding move Go to Accounting>Reporting>Tax report Generate ATS Warning will be shown "Invoice lines should have exactly one VAT tax." ATS file will download anyway opw-3896076 Forward-Port-Of: odoo/enterprise#63363
This update fixes a crash that occurred in spreadsheets when users simultaneously deleted a list and updated its filter criteria. The fix adds missing technical logic to properly handle these concurrent operations, ensuring spreadsheets remain stable during collaborative editing.
Original PR description
Before this commit, deleting a list and updating its domain concurrently would lead to a crash. This was due to the fact that the transformation of `UPDATE_ODOO_LIST_DOMAIN` was missing. This commit adds the missing transformation. This commit also fix a test that checked the number of pivots instead of the number of lists. Task: 3908657 Forward-Port-Of: odoo/enterprise#63332 Forward-Port-Of: odoo/enterprise#63246
This fix corrects how the bank reconciliation widget collects financial data to properly recognize when a user has access to multiple companies. Previously, the system only checked the current company context, which could cause issues for users managing accounts across different company entities. The fix ensures the system correctly identifies the appropriate company associated with each journal and returns properly formatted data.
Original PR description
The aim of this commit is checking that the function `collect_global_info_data` properly checks if one of the user's companies is the one on the journal and not necessarily the one from the current company (`self.env.company`). In the mean time, we're now returning an empty string instead of a False for the balance_amount's value in the returned dict because we have a props validation on this field. no task id
This update ensures that the test_discuss_full_enterprise module is automatically installed when both test_discuss_full and web_enterprise modules are present. This fix resolves test failures that were occurring when these modules were used together, improving the reliability of the testing environment.
Original PR description
When `test_discuss_full` and at least `web_enterprise` are installed, `test_discuss_full_enterprise` must be installed for the tests in `test_discuss_full` to pass. runbot-65732 Forward-Port-Of: odoo/enterprise#63366
This fix corrects an error in the payment registration wizard that occurred when processing multiple bills together where some qualified for early payment discounts and others did not. Previously, the payment amount and difference were calculated incorrectly in these scenarios. Now the amounts are calculated correctly, ensuring accurate payment processing for grouped bills with mixed discount eligibility.
Original PR description
Description of the issue/feature this PR addresses: If the user has two invoices/bills selected where one falls within the parameters of a discounted payment and the other does not, the calculated…
Description of the issue/feature this PR addresses: If the user has two invoices/bills selected where one falls within the parameters of a discounted payment and the other does not, the calculated payment total and payment difference will be wrong. Current behavior before PR: If I have two Bills, both for $25.00 where one falls within the parameters of a discount for 2% in 10 Days and the other doesn't, and I select both of them and click register payment, and the select "Group Payments" (group_payment), the "Amount" (amount) will be $0.50 and the Payment Difference (payment_difference) will be $49.50. Desired behavior after PR is merged: In the same scenario, I would expect the "Amount" to be $49.50 and the "Payment Difference" to be $0.50 To Reproduce: - Create Payment Term "2% 10, Net 30" this payment term should be configured to have a discount of 2% if paid in the first 10 days, and then 100% of the bill is due in 30 Days. - Create two Purchase Orders (doesn't matter which products you purchase), receive products, and create bills. Make sure one has the new payment term you created and its bill date puts it within the discount parameters. The other bill should either have a different payment term that doesn't have a discount or the same term but not be within the parameters to have the discount apply (bill is older than 10 days in this case) - Go to Accounting --> Vendors --> Bills and select both of these new bills and click "Register Payment" - In the wizard, click "Group Payments" and you will see the amount and payment difference are incorrect. **This process can also be done with sale orders instead, you will get the same result with two invoices for customers. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an infinite loop of emails that was occurring when redirected emails from external addresses were automatically added as followers. The system now checks if the redirected email matches an existing alias to avoid duplicate followers and prevent excessive email traffic.
Original PR description
With the introduction of alias domains in 17.0, redirected emails from non Odoo addresses would automatically add the original email as a follower. This would cause an infinite loop of emails to be sent to and from the database. Using the setting on aliases "alias_incoming_local" allows us to check the local part of aliases that have this enabled to prevent this from happening if the redirect email and the alias on the database have the same local part. Thus, the additional email will not be added as a follower. opw-3920634 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr