Thursday, October 24, 2024
18 changes
2 changes
Enhancements to existing features
The Field Service planning view now shows only deadlines and milestones linked to Field Service projects when FSM mode is active. This reduces clutter for field service teams and helps them focus on the work that is relevant to their operations.
Original PR description
In this PR, we implement the following changes: 1. Refactor get_all_deadlines Method: The get_all_deadlines method has been refactored by splitting it into two distinct methods: one for preparing the domain and another for retrieving all the necessary fields. This refactor enhances flexibility by enabling easier method overrides, allowing for the addition of fields or adjustment of the domain as required. 2. Hide Non-FSM Deadlines and Milestones in FSM Gantt View: Deadlines and milestones that do not belong to FSM projects are now hidden in the Gantt view when FSM mode is active. This visibility is controlled by a domain, ensuring that only FSM project deadlines and milestones are displayed in the FSM. task-4037284
WhatsApp discussion users now get one consistent search experience for finding conversations from the sidebar. This replaces separate channel-specific search controls with the existing quick search, making navigation faster and more predictable with Ctrl-K.
Original PR description
replaced the channel selector search on the discuss sidebar categories with a unified search extending the existing quick search feature. replaced ChannelSelector component with the new DiscussSearch. community PR: https://github.com/odoo/odoo/pull/176652 task-4100945
12 changes
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.
4 changes
Enhancements to existing features
This update improves how users in Argentina are informed about AFIP error 10016 during invoice validation. Instead of a generic error message, users now receive specific guidance based on the actual cause—whether it's a date issue, numbering mismatch, or date range requirements. This helps users quickly resolve validation problems without contacting support.
Original PR description
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.
This pr is created to help de user to know the origin of the afip error 10016. The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The…
This pr is created to help de user to know the origin of the afip error 10016.
The error 10016 can be caused by different origins, so here we give the user more precision about the origin. The objective of this pr is to be able to differentiate what is the origin of error 10016 and to be able to give a more precise message to the client.
1) If the last afip invoice validated has a higher date than the date of the invoice that is being validated then the message shown to the user is '10016-1': 'The invoice date cannot be after the last invoice validated in AFIP.'
2) If the last afip invoice number is higher than the current invoice number being validated in Odoo, then the message shown to the user is '10016-2': 'There may have been a mismatch in the numbering of this type of document between Odoo and AFIP.'
3) If any other reason cause the error '10016' then the message shown to the user is:
* Please note that if you are trying to validate an invoice with a date other than today, you must verify if it falls within the date range according to the AFIP concept or document type:
a) If it is Product: N+5 or N-5 with N being today's date.
b) If it is Services or Products and services: N+10 or N-10 with N being today's date.
c) If it is a MiPyme Invoice: N-5 0 N+1 with N being today's date. For Debit Note or Credit Note only N-5"
Task Adhoc side: 37771
Task latam side: 1194
This pr replaces https://github.com/odoo/enterprise/pull/65675Resolved issues and error corrections
This update fixes an issue where tax groups weren't correctly reflecting the company associated with a sales order or invoice in Chile. By adding the move company to the context, the system now accurately retrieves the appropriate tax groups, ensuring correct reporting and compliance with Chilean tax regulations. This complements a previous fix and improves data accuracy.
Original PR description
This is a complement of previous fix: https://github.com/odoo/enterprise/commit/9b2d9508745fb1b00e42c8d729d01ad7ae1b4b85 Add the company of the move in the context as it is possible that the company of the move and the current company are different. Related community PR: https://github.com/odoo/odoo/pull/185096
This update resolves an issue where users were blocked from synchronizing their online accounts due to a persistent error status. The solution resets the fetching status automatically when transactions are retrieved or through a new button in the online account list view, ensuring smoother synchronization and uninterrupted access to updated financial data.
Original PR description
The field fetching status is used to check if we need to call the synchronization. In case there is an error during the synchronization, the user would be block with his connection. The solution is to reset the fetching status when fetching the transaction or use the new reset button on the list view of the online accounts. task:4262788
This update fixes an issue where Purchase Orders and Sales Orders generated between companies didn't consistently use the expected arrival or commitment dates. Now, the system will accurately reflect the specified delivery dates when creating counterpart orders in the other company, improving order scheduling and fulfillment accuracy.
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72586