Thursday, October 24, 2024
12 changes · 18.0
Enhancements to existing features
Electronic invoicing options are now selected more reliably based on each customer’s country and Peppol eligibility. Italian customers will default to the local FatturaPA format, and users will see fewer irrelevant Peppol options when their company cannot use them.
Original PR description
### Commit 1: [IMP] l10n_it_edi: add FatturaPA as the preferred edi format for IT partners Add FatturaPA as the preferred EDI format set by default on Italian partners. task-no --- ### Commit 2:…
### Commit 1: [IMP] l10n_it_edi: add FatturaPA as the preferred edi format for IT partners Add FatturaPA as the preferred EDI format set by default on Italian partners. task-no --- ### Commit 2: [FIX] account_\*,l10n_\*: EDI formats computation fixes 1. Before this commit, there was multiple lists of UBL/CII formats that needed to be maintained. This was error prone because each implementation needed to overrive each of these lists. We now have one dict with all formats informations that is parsed in different ways depending on the need. (By Country, Peppol compatible, ...) 2. Before this commit, if a country had two possible UBL/CII formats, one always override the other, we now have the possibility to have multiple formats per country and set a priority on them (trough a sequence number). 3. Before this commit, we maintained a list of NON-PEPPOL formats, this had multiple drawbacks: it's hard to maintain, error prone, unecessary negation that made condition tricky to understand. We now set a value on the dictionnary of UBL/CII formats that marks the format as compliant with Peppol Network. task-4240924 --- ### Commit 3: [IMP] account_peppol: refine displayed EDI formats and sending methods in partner form Make the displayed information on partner form more relevant: - the sending method "by Peppol" is no longer visible when the current company can't enable Peppol (for example an US company). - the EDI formats displayed when "by Peppol" is the preferred sending method are now only EDI formats supported by the Peppol Network. task-4240924
Inviting someone as a follower in Mail will no longer send an invitation notification automatically. This reduces duplicate emails when users are adding followers before sending them an actual message.
Online food orders from UrbanPiper, Swiggy, and Zomato now show merchant-paid GST taxes on order lines when the tax rate is not the aggregator-paid 5% GST. This helps merchants in India better understand and reconcile taxes they are responsible for collecting and paying.
Original PR description
**=pos_urban_piper, pos_urban_piper_swiggy After this commit: - In India there is a special case that 5% GST is collected by the aggregator and paid by the aggregator directly but other than this like 12% or 18% GST is collected by the merchant and paid by the merchant itself. - This commit targets to display taxes in the order line if they are other than 5% GST. task- 4190283
Signing requests now automatically select the partner linked to the record as the default signer. This reduces manual selection work and helps send documents to the right person more consistently.
Resolved issues and error corrections
Mobile users can now create or view discussion threads from message actions as expected. This fixes a display issue that prevented important conversation options from appearing on phones and tablets.
Original PR description
**Current behavior before PR:** Users were unable to create or view threads from message actions on mobile devices due to an incorrectly written condition. The condition checked `component.isOriginThread`, but in mobile, the component is `MessageActionMenuMobile` insead of `Message`, which does not have the isOriginThread method. **Desired behavior after PR is merged:** This PR fixes the issue, allowing the create or view thread actions to display properly on mobile. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where automated actions that cleared a linked record field could fail and show a web error instead of saving normally. Businesses using automated updates, including Studio-created rules, can now rely on those fields being cleared as intended.
Original PR description
**Current behavior:** Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger. **Expected behavior:** The targeted field is…
**Current behavior:**
Setting up an automation rule which attempts to clear an m2o field on a record can result in an exception occurring on rule trigger.
**Expected behavior:**
The targeted field is cleared.
**Steps to reproduce:**
*Concrete example: `-i stock,web_studio`
1. Go to the form view for lots/serial numbers
2. Activate studio, add a new Boolean field and a M2o field (on res.partner for sake of example) in the view
3. Create a new automation rule which runs on `stock.lot` like:
* Trigger: `On save`
* Before Update Domain: `Match all records`
* Apply on: `[('x_studio_new_boolean_field', '=', False)]`
4. Add an action to the rule like:
* Type: `Update Record`
* Action Details: `Update x_studio_new_m2o_field to <blank>`
5. Open a lot record, set the new boolean field to True and enter a partner in the m2o field -> save
6. Set the boolean to False then save again -> web error
**Cause of the issue:**
Setting the field to False is actually evaluated as setting it to 0 -> we write `res.partner(0,)` instead of clearing it. At the conclusion of the automation rule being triggered, there is a `web_save()` which returns a `web_read()` on the (in this instance) `stock.lot` record being written on.
Here, once we see the `x_studio` m2o field in the specification, there is a dict comprehension:
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L116-L119 Which calls `cleanup()` on the result of a recursive`web_read()` on `res.partner(0,)` which here is returning {'id': 0}. In `cleanup()`: `vals['id'] == 0 == False` -> Try to access `vals['id'].origin` which, of course, raises an exception.
**Fix:**
For m2o fields, evaluate Falsey expr values in `_eval_value()` to explicit `False`.
opw-4252864This fixes an error that could appear when users enabled Valuation by Lot/Serial number on the same product from multiple open tabs. The change prevents the page from crashing, making product inventory valuation settings more reliable.
Original PR description
When the user clicks on the checkbox of ``Valuation by Lot/Serial number``, a traceback will appear. Steps to reproduce the error: - Install ``stock_account`` module - Create a product(type : Goods)…
When the user clicks on the checkbox of ``Valuation by Lot/Serial number``,
a traceback will appear.
Steps to reproduce the error:
- Install ``stock_account`` module
- Create a product(type : Goods) > Track Inventory: ``By Unique Serial Number``
- Create one variant of that product
- Now, Open the product in one tab and open the product variant in another tab
- Click on the checkbox of ``Valuation by Lot/Serial number`` in both tabs
Traceback:
```
UnboundLocalError: cannot access local variable 'products' where it is not associated with a value
File "odoo/http.py", line 2364, in __call__
response = request._serve_db()
File "odoo/http.py", line 1891, in _serve_db
return self._transactioning(
File "odoo/http.py", line 1954, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 137, in retrying
result = func()
File "odoo/http.py", line 1921, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2168, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 330, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 728, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 35, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 517, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/sale_project/models/product_template.py", line 137, in write
return super().write(vals)
File "addons/stock_account/models/product.py", line 82, in write
impacted_templates[tmpl] = (products, description, products_orig_quantity_svl)
```
https://github.com/odoo/odoo/blob/09fa1db600c31d2d04f0504f0412cbbc85ff7e3d/addons/stock_account/models/product.py#L77-L82
Here, the ``products`` variable is referenced before the assignment,
So, it will lead to the above traceback.
sentry-5991310335
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an error that could appear when closing a Point of Sale register after reviewing and deleting draft orders involving combo products. Cashiers can now complete register closing more reliably without terminal tracebacks interrupting the workflow.
Original PR description
A traceback occurs when the user tries to close a register having the draft orders. To reproduce this issue: 1) Open a `furniture register` in the POS 2) Add a `combo product` and close the register…
A traceback occurs when the user tries to close a register having the draft orders.
To reproduce this issue:
1) Open a `furniture register` in the POS
2) Add a `combo product` and close the register
3) Click on Review Orders and delete the existing orders
4) Now click on the `Back` button and repeat steps 2 and 3
5) An error occurred in the terminal
Error:-
```
IndexError: list index out of range
```
In the `_prepare_combo_line_uuids` the `order_vals['lines']` contains multiple lines.
For each line, there are two data possibilities of data.
If line[0] contains 0 or 1, the data should be like `[0, 0, {.......}]`,
if the line[0] doesn't contain 0 or 1 the data should be like `[3, 4]`.
Clearly, it leads to a traceback when the filter is used in `order_vals['lines']`
and tries to access 2nd index through lambda.
https://github.com/odoo/odoo/blob/82867bc13ea2beb50234ad6e23717ad61d047e7c/addons/point_of_sale/models/pos_order.py#L133-L140
Adding an extra check in the filter will resolve this issue.
sentry-5990190061Customers using the restaurant mobile menu will keep the same tracking number after refreshing and returning to pay for an order. This prevents confusion and duplicate order identifiers for orders that were already sent.
Original PR description
Steps to reproduce : ==== 1.Activate mobile menu in restaurant config. 2.Open mobile menu. 3.Make an order up to confirmation page (tracking number is available). 4.Refresh the page 5.Go to My Order and pay again , new tracking number is generated. Issue: ==== - A new tracking number is being generated, even though the order was previously sent and already has an existing tracking number. Fix : ==== - Preventing the creation of a new tracking number if the order already has one. task - 4259426
This fix ensures Mexican electronic invoices correctly report local tax percentages when they appear on the same invoice line as the standard 16% tax. It helps prevent incorrect CFDI tax data and reduces the risk of rejected or inaccurate invoices.
Original PR description
task_id: 4261885
Users accessing shared projects can now change planned dates on tasks without triggering an error. This keeps collaboration smoother for external or portal users who need to update task schedules.
Original PR description
In project sharing, when the user changes a planned date in task form, a traceback occurs, because the portal user doesn't have the rights on `resource.calendar.attendance`. To solve that, we call the method that get those records with sudo (`_get_tasks_by_resource_calendar_dict`). task-3973305
Rental product pages now update availability information when shoppers switch between product variants. This helps prevent customers from trying to rent a variant that is unavailable without seeing a warning.