Daily updates from Odoo
Navigate
Branch
Wednesday, April 3, 2024
76 changes
25 changes
Enhancements to existing features
This pull request groups several user-facing improvements and fixes across accounting setup, HR time off, live chat, mail activities, website forms, and restaurant operations. It improves onboarding and day-to-day workflows while fixing issues that could affect previews, employee images, time off calculations, website form behavior, and message recipient suggestions.
Original PR description
woops, wrong branch
Resolved issues and error corrections
Bank statement reports now show the latest running balance correctly when balances are grouped. This prevents misleading totals in accounting views and helps finance teams rely on the displayed cash position.
Original PR description
Since https://github.com/odoo/odoo/pull/127353, the web client only asks for the aggregatable field, making the read_group override of 'account.bank.statement.line' becomes ineffective. Remove the check done on fields, and always return the latest running_balance by group. https://github.com/odoo/enterprise/pull/59936
This fix allows Brazilian PIX QR codes to work even when no payment amount is included, which is important for offline point-of-sale use. It helps cashiers continue accepting PIX payments in situations where the final amount must be entered later or connectivity is unavailable.
Original PR description
Since this commit we support the QR code without amount To be used in the POS when the POS is offline. Introduced by: https://github.com/odoo/odoo/pull/148803/commits/f286e2c0473c568991171ef8c0b2dbb9871d2f2e Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
**Before this PR:** When more than 1 line item is added, users are unable to update or remove products from the catalog view. **Technical Reason:** There is a function _is_readonly() that returns True if there are multiple line items, and because of this, the value of props.readOnly becomes True which prevents users from updating the products in catalog view. **Solution:** Adding one more condition in account_move_line to satisfy the desired behavior. **After this PR:** The users ca
Original PR description
**Before this PR:** When more than 1 line item is added, users are unable to update or remove products from the catalog view. **Technical Reason:** There is a function _is_readonly() that returns True if there are multiple line items, and because of this, the value of props.readOnly becomes True which prevents users from updating the products in catalog view. **Solution:** Adding one more condition in account_move_line to satisfy the desired behavior. **After this PR:** The users can update or remove the products from the catalog view if there are multiple line items. **Task**-3806509 Forward-Port-Of: odoo/odoo#157994
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a modification of the HTML structure for date(time) input fields. Consequently, a bug emerged in the visibility options for fields reliant on a date(time) field. Specifically, the time condition selector failed to display the time conditions because they are rendered based on the HTML struc
Original PR description
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a…
**[FIX] website: fix conditional visibility depending on date field** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. This change resulted in a modification of the HTML structure for date(time) input fields. Consequently, a bug emerged in the visibility options for fields reliant on a date(time) field. Specifically, the time condition selector failed to display the time conditions because they are rendered based on the HTML structure of the fields. Since the code was not adjusted to fit the new structure, this functionality stopped functioning. [1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 task-3790809 ---------------------------------------------- **[FIX] website: fix traceback with website form date(time) fields** Since commit [1], the "tempusdominus" date(time) picker has been replaced by the OWL date(time) picker. A traceback appears when loading a website form containing a field dependent on a date(time) field. This traceback occurs because when checking the value of an empty date(time) field (which happens when the user hasn't yet filled out the form), we parse the field value into a Date(Time). Before the changes in commit [1], we parsed this differently, which didn't crash but returned "NaN" with an empty date(time) field. In this commit, we now check whether a date(time) is valid and if not, we now assign it "NaN" to maintain exactly the same behaviour as before the commit [1]. Any value other than "NaN" would not work with the date comparison system and would break certain conditions. This commit also adds steps to the "website_form_editor" test tour so that it fails without this commit. [1]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 task-3790809 Forward-Port-Of: odoo/odoo#158288
### Before This PR if there the new_hire_field is False(in case of hr_contract for example if there are not contracts), an error appear. ### After THIS PR This Commit will check that the field is not false so the error is not raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159859
Original PR description
### Before This PR if there the new_hire_field is False(in case of hr_contract for example if there are not contracts), an error appear. ### After THIS PR This Commit will check that the field is not false so the error is not raised --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159859
This traceback arises when the user changes the date with a new employee of no contract while creating a new Work Entry. To reproduce this issue: 1) Install `hr_work_entry_contract` 2) Open `payroll` and create a new `Work Entry` 3) Select `Work Entry Type` as `Unpaid` and create a new employee 4) Now try to change the `end date` Error:- ``` KeyError: False File "odoo/http.py", line 2252, in __call__ response = request._serve_db() File "odoo/http.py", line 1828, in
Original PR description
This traceback arises when the user changes the date with a new employee of no contract while creating a new Work Entry. To reproduce this issue: 1) Install `hr_work_entry_contract` 2) Open `payroll`…
This traceback arises when the user changes the date with a new employee of no contract
while creating a new Work Entry.
To reproduce this issue:
1) Install `hr_work_entry_contract`
2) Open `payroll` and create a new `Work Entry`
3) Select `Work Entry Type` as `Unpaid` and create a new employee
4) Now try to change the `end date`
Error:-
```
KeyError: False
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, 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 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, 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 38, in call_kw
return 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 "addons/web/models/models.py", line 1074, in onchange
todo = [
File "addons/web/models/models.py", line 1077, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1190, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6669, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 1138, in __get__
self.recompute(record)
File "odoo/fields.py", line 1353, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1326, in apply_except_missing
func(records)
File "odoo/fields.py", line 1375, in compute_value
records._compute_field_value(self)
File "odoo/models.py", line 4982, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 102, in determine
return needle(*args)
File "addons/hr_work_entry/models/hr_work_entry.py", line 84, in _compute_duration
durations = self._get_duration_batch()
File "home/odoo/src/enterprise/saas-17.1/hr_work_entry_contract_planning/models/hr_work_entry.py", line 46, in _get_duration_batch
res.update(super(HrWorkEntry, super_we)._get_duration_batch())
File "addons/hr_work_entry_contract/models/hr_work_entry.py", line 119, in _get_duration_batch
result[work_entry.id] = mapped_contract_data[(date_start, date_stop)][calendar][employee.id]['hours']
```
On the `_get_duration_batch` method, when the user creates a new employee without a contract,
the calendar remains an empty recordset.
which leads to the traceback from the below lines.
https://github.com/odoo/odoo/blob/a277faa2ffab7559fcbad95fcc1e8fd6a26d756b/addons/hr_work_entry_contract/models/hr_work_entry.py#L110-L112
After applying this commit will resolve the issue by making the code more robust
and gives the default value for `work_entry.id`.
sentry-5095168051
Forward-Port-Of: odoo/odoo#159982
Forward-Port-Of: odoo/odoo#159276Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address. Steps to reproduce: ------------------- * Go to the **Contacts** app * Select any contact (ex: Azure Interior) * Under **Contacts & Addresses** select Add * Select **Invoice Address** * Write the address then **Save & Close** * Go to the **Point of Sale** app * Add items * For customer, sel
Original PR description
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.…
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address. Steps to reproduce: ------------------- * Go to the **Contacts** app * Select any contact (ex: Azure Interior) * Under **Contacts & Addresses** select Add * Select **Invoice Address** * Write the address then **Save & Close** * Go to the **Point of Sale** app * Add items * For customer, select the contact we just modified * Select **Payment** * Select any payment method * Select **Invoice** * Validate > Observation: The invoice address is not used Why the fix: ------------ We observe a discrepancy between the sale and pos output for the same workflow. * Sale * Sale order form: `Customer` -> Azure interior (Has a field for invoice address) * Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address) * PoS * PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address) * Account move form: `Customer` -> Azure interior In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move. In the sale workflow, the move is created with `invoice_vals_list` https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207 Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address. https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004 With `partner_invoice_id` computed as follows: https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342 Thus, we also send the invoicing contact address as partner_id when creating the move in pos; opw-3797434 Forward-Port-Of: odoo/odoo#159856 Forward-Port-Of: odoo/odoo#159172
Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE command for a record that isn't in page 1 (so a record we haven't read), with a value for that readonly field. Before this commit, the value was sent in the UPDATE command, even though readonly fields shouldn't be sent. The difficulty here is that we can't always evaluate those readonly expressions, a
Original PR description
Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE…
Have an x2many with several pages containing a field with a readonly modifier (in the view, not in the field definition), e.g. `readonly="1"` in the arch. Have an onchange that returns an UPDATE command for a record that isn't in page 1 (so a record we haven't read), with a value for that readonly field. Before this commit, the value was sent in the UPDATE command, even though readonly fields shouldn't be sent.
The difficulty here is that we can't always evaluate those readonly expressions, as they can depend on other fields, which we didn't read if the record is in a page we didn't browse to yet. However, "static" expression like `"1"`, or `"context.get('something')"` can totally be evaluated, and they should. This is what this commit does.
Steps to reproduce the issue:
- Install mrp
- Go to Manufacturing > Products > Bill of Materials
- New:
- Product: quick create "B1"
- Components: two lines: quick create "C1" and "C2" - Save
- Manufacturing > Operations > Manufacturing Orders
- New [in that form view, set the limit of the x2many to 1]:
- Product: "B1"
- Save - Change quantity to 2 - Save => Invalid Operation
opw 3819253
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160129Steps to reproduce: - Install Invoicing - Create a product with $0 cost (e.g. Product X) - Create a vendor bill: * Vendor: [any] * Invoice Lines: - Product: [none] - Label: [anything] - Price: [any] - Taxes: [any] => The displayed "Untaxed Amount", "Taxes" and "Total" are correct - Save the vendor bill - Edit the invoice line of the bill - Add Product X => "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected - Change Price to 100 manually
Original PR description
Steps to reproduce: - Install Invoicing - Create a product with $0 cost (e.g. Product X) - Create a vendor bill: * Vendor: [any] * Invoice Lines: - Product: [none] - Label: [anything] - Price: [any]…
Steps to reproduce:
- Install Invoicing
- Create a product with $0 cost (e.g. Product X)
- Create a vendor bill:
* Vendor: [any]
* Invoice Lines:
- Product: [none]
- Label: [anything]
- Price: [any]
- Taxes: [any]
=> The displayed "Untaxed Amount", "Taxes" and "Total" are correct
- Save the vendor bill
- Edit the invoice line of the bill
- Add Product X => "Untaxed Amount", "Taxes" and "Total" are correctly set to 0 as expected
- Change Price to 100 manually
Issue:
"Untaxed Amount", "Taxes" and "Total" stay at $0.
Upon save, "Untaxed Amount" is correctly set to $100, but "Taxes" stays at $0.
If "Units of Measure" option is activated in the Settings (available with Sales, Purchase or Inventory app), the user will be in "uom.group_uom" and the issue will not happen.
Cause:
When the user isn't in "uom.group_uom" group, "product_uom_id" field is declared after "price_unit" field in the view.
Due to that, adding a product in the invoice line and changing the price to $100, will first set "price_unit" to $100 and then set "product_uom_id" that will trigger "_compute_price_unit" method where "price_unit" is recomputed to $0 (its cost).
Solution:
Move "product_uom_id" field before "price_unit" field in the view as it is the case when the user is in "uom.group_uom" group.
opw-3750740
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#156447The warning message when you have a half-day off confirmed while the duration of this leave's type is daily is moved towards the bottom of the sheet to avoid overlap between this message and the ribbon. And to improve the readibility of the dialog view, the scroll bar is removed when it's not needed. task: 3820211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159454
Original PR description
The warning message when you have a half-day off confirmed while the duration of this leave's type is daily is moved towards the bottom of the sheet to avoid overlap between this message and the ribbon. And to improve the readibility of the dialog view, the scroll bar is removed when it's not needed. task: 3820211 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159454
**Steps to reproduce:** - Install Accouting and Expenses - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans" - Create an analytic plan with the following line: * Domain: Expense * Applicability: Mandatory - Create an analytic account from the plan via "Analytic Accounts" smart button - Create an expense without analytic - Create a report from it - Submit it to manager - Try to approve it => An expecte
Original PR description
**Steps to reproduce:** - Install Accouting and Expenses - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans" - Create…
**Steps to reproduce:** - Install Accouting and Expenses - Activate "Analytic Accounting" in Accounting settings - Go to "Accounting / Configuration / Analytic Accounting / Analytic Plans" - Create an analytic plan with the following line: * Domain: Expense * Applicability: Mandatory - Create an analytic account from the plan via "Analytic Accounts" smart button - Create an expense without analytic - Create a report from it - Submit it to manager - Try to approve it => An expected Validation Error will raise: "One or more lines require a 100% analytic distribution." - Go to "Expenses / Expense Reports" (list view) - Select the created expense report - Try to approve it **Issue:** The report will be approved even if there is no analytic configured on it. **Cause:** "validate_analytic" option is not passed in the context when approving the report from list view as it is done in form view. opw-3806787 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160143 Forward-Port-Of: odoo/odoo#159043
Steps to reproduce: - Install MRP - Enable packages and multi-step routes - Enable two steps manufacturing - Create a component and a product - Create a BOM for the product and add the component - Make an MO for 100 units of the product - Go to the picking and make a move of 20 units of the component with a destination package - Put in pack - Create the backorder and validate the transfer of the remaining components - Go back to the MO Issues: Units reserved is wrong. The pro
Original PR description
Steps to reproduce: - Install MRP - Enable packages and multi-step routes - Enable two steps manufacturing - Create a component and a product - Create a BOM for the product and add the component - Make an MO for 100 units of the product - Go to the picking and make a move of 20 units of the component with a destination package - Put in pack - Create the backorder and validate the transfer of the remaining components - Go back to the MO Issues: Units reserved is wrong. The problem is when we are unpacking, we were using result package inside the key. But what we want is to remove quantity from the package the quantity originate from. opw-3759006 Forward-Port-Of: odoo/odoo#160091 Forward-Port-Of: odoo/odoo#158166
The `website_livechat.chatbot_redirect` tour checks that the chat bot still works after redirection. The tour waits for the chat bot message that indicates the redireciton was made. Since the tour restarts the bot to test two differents flows, this message is already present before the second redirection occurs. The tour should instead wait for two occurences of this message the second time. Forward-Port-Of: odoo/odoo#160276
Original PR description
The `website_livechat.chatbot_redirect` tour checks that the chat bot still works after redirection. The tour waits for the chat bot message that indicates the redireciton was made. Since the tour restarts the bot to test two differents flows, this message is already present before the second redirection occurs. The tour should instead wait for two occurences of this message the second time. Forward-Port-Of: odoo/odoo#160276
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback. This commit corrects this situation. Here's a way to reproduce the error: - Install `sale_management` - Open a quotation - Put enough elements to have two pages - Modify the view via debug mode and change the list view limit from "200" to "2". - Add 4 elements - Sort with `product_uom_qty` field - Attempt to delete the second element (i.e. the last element on the first page) When deletin
Original PR description
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback. This commit corrects this situation. Here's a way to reproduce the error: - Install `sale_management` -…
In some cases, sorting a sub-view list and then deleting one of its rows can cause a traceback.
This commit corrects this situation.
Here's a way to reproduce the error:
- Install `sale_management`
- Open a quotation
- Put enough elements to have two pages
- Modify the view via debug mode and change the list view limit from "200" to "2".
- Add 4 elements
- Sort with `product_uom_qty` field
- Attempt to delete the second element (i.e. the last element on the first page)
When deleting this line, a traceback is raised
Let's say we have 4 records with the following data
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
| 2 | Lamp | 1 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 4 | Board | 3 |
In this case we have two cached elements: the two elements visible on
the first page.
In the cache we have two complete records, by complete we mean a record
containing all the fields, for example:
```js
{
"1": {
id: "datapoint_4",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": {
id: "datapoint_11",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
}
}
```
After sorting by quantity, we end up with
Page 1 (`1 - 2 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 4 | Board | 3 |
Page 2 (`3 - 4 / 4`):
| ID | Product | Quantity |
|----|---------|----------|
| 3 | Chair | 4 |
| 1 | Table | 6 |
It also changes at cache level, since we sorted via the `product_uom_qty`
field, we had to go and read the records on the next page (despite the
fact that they weren't displayed).
But as we only need the quantity information, we only fetch this field
from the records on the following pages.
In terms of cache, we have something like this
```js
{
"1": {
id: "datapoint_45",
...
data: {
sequence: 10,
name: "Lamp",
product_uom_qty: 1,
display_type: false
...
}
},
"3": {
id: "datapoint_16",
...
data: {
sequence: 10,
name: "Board",
product_uom_qty: 3,
display_type: false
...
}
},
"4": {
id: "datapoint_32",
...
data: {
sequence: 10,
name: "Table",
product_uom_qty: 6,
display_type: false
...
}
},
"2": { //Chair
id: "datapoint_1",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
}
}
```
We therefore have one new incomplete record in the cache
The problem will occur when we try to delete a record from the first page,
if we delete `Board`, to have this
Page 1 (`1 - 2 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 2 | Lamp | 1 |
| 3 | Chair | 4 |
Page 2 (`3 - 3 / 3`):
| ID | Product | Quantity |
|----|---------|----------|
| 1 | Table | 6 |
So we'll have to move the table that was on page 2 to page 1 (in our
case `Table`), except that when we render the list we'll have to compute
the required/readonly/invisible elements, and if we have a field that
has a readonly with the condition `not display_type` in our view, this
will cause a traceback because in the cache we only have this
```js
"4": { //Chair
id: "datapoint_32",
...
data: {
sequence: 10,
product_uom_qty: 4,
}
},
```
`display_type` is definitely not in the data because we considered this
cached record to be complete.
This commit modifies the `StaticList._applyCommands` function to create
datapoints for all records that are not **entirely** loaded via `StaticList._getResIdsToLoad`.
https://github.com/odoo/odoo/blob/00898aef4dbeb469e0cec7eaea387de2755c6426/addons/web/static/src/model/relational_model/static_list.js#L898-L912
opw-3771077
Forward-Port-Of: odoo/odoo#159264Steps to reproduce: - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Product: [any product with UNSPSC Category set] - Confirm the invoice - Go to the portal preview of the invoice - Download the invoice from portal Issue: 1) On the invoice, the CFDI document has been generated and processed without notice. Downloading an invoice from portal should only download the in
Original PR description
Steps to reproduce: - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Product: [any…
Steps to reproduce: - Install l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Product: [any product with UNSPSC Category set] - Confirm the invoice - Go to the portal preview of the invoice - Download the invoice from portal Issue: 1) On the invoice, the CFDI document has been generated and processed without notice. Downloading an invoice from portal should only download the invoice. 2) There are 2 buttons on the portal: "Download" and "Print". The "Print" allows to print the invoice, even if it has not been generated and sent yet. Cause: When downloading an invoice from portal, we are going through the "Send & Print" wizard (without displaying it) with only "Download" option checked. However, some localization (e.g. MX) may add specific options that are checked by default (e.g. CFDI), which triggers the corresponding flow. Solution: 1) Make sure that all options of "Send & Print" wizard are deactivated, except "Download". Download existing invoice documents or generate a Pro Forma document when downloading invoice from portal. 2) Remove "Print" button from portal view. opw-3821371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159255
This commit updates the parameters passed to the IAP SMS API route ("/api/sms/3/send") to include the DB UUID. Task: 3829793 Forward-Port-Of: odoo/odoo#159714
Original PR description
This commit updates the parameters passed to the IAP SMS API route ("/api/sms/3/send") to include the DB UUID.
Task: 3829793
Forward-Port-Of: odoo/odoo#159714Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159863 Forward-Port-Of: odoo/odoo#157026
Original PR description
Steps to reproduce: - Install 'Subscriptions' - Enable 'Lock Confirmed Sales' in the settings - Make a new subscription - Invoice the subscription Issues: The subscription is now locked, this behaviour is not intended. As confirmed with the PO this settings should never affect the subscriptions. Linked PR: https://github.com/odoo/enterprise/pull/58332 opw-3754106 Forward-Port-Of: odoo/odoo#159863 Forward-Port-Of: odoo/odoo#157026
* Adds text values for the call settings sliders. * Replaces `onChange` events with `onInput` events so that the values respect the position of the sliders. * Debounces some functions to handle the increased amount of calls due to the swap to the `onInput` listener. * Changes the default value of `voiceActiveDuration` from `0` to `200` to match the minimum value of the input. Forward-Port-Of: odoo/odoo#159693 Forward-Port-Of: odoo/odoo#151028
Original PR description
* Adds text values for the call settings sliders. * Replaces `onChange` events with `onInput` events so that the values respect the position of the sliders. * Debounces some functions to handle the increased amount of calls due to the swap to the `onInput` listener. * Changes the default value of `voiceActiveDuration` from `0` to `200` to match the minimum value of the input. Forward-Port-Of: odoo/odoo#159693 Forward-Port-Of: odoo/odoo#151028
In `ir.model.data` model, there is no SQL constraint which is ensuring that the `name` field can not contain `.` (dot) So when loading the translations to database if the xmlid's `name` contains dot then `xmlid.split('.')` will split it more than 2 parts. Which will cause issue during saving it to database as it is expecting[^1] 2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts with `maxsplit=1` Description of the issue/feature this PR addresses: Current behavior before PR:
Original PR description
In `ir.model.data` model, there is no SQL constraint which is ensuring that the `name` field can not contain `.` (dot) So when loading the translations to database if the xmlid's `name` contains dot then `xmlid.split('.')` will split it more than 2 parts. Which will cause issue during saving it to database as it is expecting[^1] 2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts with `maxsplit=1`
Description of the issue/feature this PR addresses:
Current behavior before PR:
It is splitting xmlids as many as possible parts.
Desired behavior after PR is merged:
It will split xmlid to the 2 parts `[module, name]`
[^1]: https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1326
and
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1390
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160098This route is no longer used in our code and it tries to read templates that are no longer existing, leading to a crash if called manually. Forward-Port-Of: odoo/odoo#160206
Original PR description
This route is no longer used in our code and it tries to read templates that are no longer existing, leading to a crash if called manually. Forward-Port-Of: odoo/odoo#160206
Steps to reproduce: ------------------- - create 2 websites (for one or two companies); - create 2 jobs; - publish job A in website 1; - publish job B in website 2; - as a public user go to website 1 and apply for job A; - go to website 2 and try to apply for job B; Issue: ------ When we encode the email address, we receive the message: ``` You already applied to another position recently. You can continue if it's not a mistake. ``` Cause: ------ We don't take into account th
Original PR description
Steps to reproduce: ------------------- - create 2 websites (for one or two companies); - create 2 jobs; - publish job A in website 1; - publish job B in website 2; - as a public user go to website 1 and apply for job A; - go to website 2 and try to apply for job B; Issue: ------ When we encode the email address, we receive the message: ``` You already applied to another position recently. You can continue if it's not a mistake. ``` Cause: ------ We don't take into account the website linked to the job we are applying for. Solution: --------- Incorporate the website into the domain for application search. opw-3798670 Forward-Port-Of: odoo/odoo#159263
Accounts 10x -> 13x should be of 'equity' type. (In the Balance Sheet, they are referenced under the Equity section.) Enterprise PR: https://github.com/odoo/enterprise/pull/57117 opw-3743637 Forward-Port-Of: odoo/odoo#160161 Forward-Port-Of: odoo/odoo#154859
Original PR description
Accounts 10x -> 13x should be of 'equity' type. (In the Balance Sheet, they are referenced under the Equity section.) Enterprise PR: https://github.com/odoo/enterprise/pull/57117 opw-3743637 Forward-Port-Of: odoo/odoo#160161 Forward-Port-Of: odoo/odoo#154859
Issue ----- The tooltip help text doesn't match the actual calculation made in the product margins report. **opw-3792181** Forward-Port-Of: odoo/odoo#159131
Original PR description
Issue ----- The tooltip help text doesn't match the actual calculation made in the product margins report. **opw-3792181** Forward-Port-Of: odoo/odoo#159131
**Description of the issue/feature this PR addresses:** Having the VAT VIES Check valid field directly next to the VAT number as an inline element becomes unreadable, so we add a line break before **Current behavior before PR:**  **Desired behavior after PR is merged:**  Info
Original PR description
**Description of the issue/feature this PR addresses:** Having the VAT VIES Check valid field directly next to the VAT number as an inline element becomes unreadable, so we add a line break before **Current behavior before PR:**  **Desired behavior after PR is merged:**  Info: @wt-io-it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159332
21 changes
Enhancements to existing features
Signature request activities are now connected to the business record they came from, making it easier to track and navigate related documents. When a request is sent or completed, the relevant updates and signed files are automatically logged on the original record for clearer follow-up.
Original PR description
This commit has the goal to increase the usefulness of the "request signature" activity type. This is done by integrating the model that has the activity with the signature.request record. Now, when a sign activity is added to a record, it is linked to any sign request that is generated from that activity. Whenever the sign.request is completed, the generated files are added in the chatter. This makes it easier to navigate between the linked records. task-3685648
Creating a new appointment from the Gantt view now starts from the current time rounded to the nearest hour instead of defaulting to midnight. This makes new bookings faster and more relevant for users scheduling appointments during the day.
Original PR description
Purpose ========= Currently when we click on the new button on Gantt view the default start is set to today's midnight which is not relevant. After this PR ================== The current DateTime with rounded hour will be set as a default start while creating a new booking through the Gantt view. Task-3820387
Internal users who open a shared spreadsheet link are now taken directly to the spreadsheet within the Documents app. This keeps the usual Documents breadcrumb and navigation context, making shared spreadsheet links easier to understand and use.
Original PR description
Currently when sharing a spreadsheet by using the share option or copying the URL, as an internal user, you don't land in the Documents app. With this commit, the user lands on the open spreadsheet, with the Documents app in the breadcrumb, as if he was coming from Documents. Task: 3525858
Users with the proper access rights can now delete timer or timesheet records belonging to another user. This removes an unnecessary restriction that prevented administrators or authorized staff from managing records they are permitted to control.
Original PR description
_*: timer, test_timer Before these commit when any user record rule only allows deletion of the record if you are the user on that record. Admin can't delete the timesheet record of the user. Improvements: ----- if a user possesses the authority or permission to delete another user's timer, then they can perform the deletion. task-3160340
This change adds automated checks to make sure sensitive employee fields keep the correct access restrictions across several HR-related apps. It helps reduce the risk of accidental exposure of private employee information as the system evolves.
Spreadsheet users can now choose to include child records when applying relation-based filters. This makes spreadsheet reports more complete and easier to analyze when data is organized in parent-child structures.
Original PR description
Task: 3500731
Features or functions removed from Odoo
Planning reports no longer show the working days count because it could be misleading when shifts overlap or when employees have flexible schedules. This prevents business users from relying on an inaccurate metric in planning, leave, timesheet forecasting, and sales planning reports.
Original PR description
Before this commit, the field 'working_days_count' was utilized in reports related to scheduling. However, this field did not accurately represent the number of working days for a resource. For instance, if a resource has multiple non-overlapping shifts in a week, the calculation is accurate. But, as soon as shifts overlap, the value no longer reflects reality. Why? Because the number of working days is calculated for each time slot based on the daily hours in the calendar, independently of other shifts. This means, for a 40-hour week calendar with 8-hour days, if there are two shifts from Monday to Friday, each with 40 allocated hours, the working_days_count equals 10, which is incorrect. It also doesn't work for employees with flexible hours due to the absence of a standard calendar. This commit removes the field as there is no viable solution to resolve these issues. taskid:3186627
Miscellaneous changes
Before this commit, the ticket field is displayed in the sublist view of timesheet when the user is in ticket form view with timesheets feature enabled. This commit hides the ticket field as it was the case base. issue found during the testing of task-2276015 Forward-Port-Of: odoo/enterprise#59891
Original PR description
Before this commit, the ticket field is displayed in the sublist view of timesheet when the user is in ticket form view with timesheets feature enabled. This commit hides the ticket field as it was the case base. issue found during the testing of task-2276015 Forward-Port-Of: odoo/enterprise#59891
During this commit: https://github.com/odoo/enterprise/pull/45792/commits/3a3d9c877f3e8bd2db9e66cd8120d889fd09f125 a xpath was refactored to add the closing attribute for the belgian tax report. Before this commit the xpath wasn't working but didn't cause a traceback. By adding the parenthesis, the last operator can get the last div of the pdf_export_filters template and put after it the different closing attribute. no task id Forward-Port-Of: odoo/enterprise#59453
Original PR description
During this commit: https://github.com/odoo/enterprise/pull/45792/commits/3a3d9c877f3e8bd2db9e66cd8120d889fd09f125 a xpath was refactored to add the closing attribute for the belgian tax report. Before this commit the xpath wasn't working but didn't cause a traceback. By adding the parenthesis, the last operator can get the last div of the pdf_export_filters template and put after it the different closing attribute. no task id Forward-Port-Of: odoo/enterprise#59453
Previously, splitting an order did not cancel the split order line in the preparation display. This commit ensures that the preparation display is updated correctly when an order is split. opw-3809693 Forward-Port-Of: odoo/enterprise#59655 Forward-Port-Of: odoo/enterprise#59554
Original PR description
Previously, splitting an order did not cancel the split order line in the preparation display. This commit ensures that the preparation display is updated correctly when an order is split. opw-3809693 Forward-Port-Of: odoo/enterprise#59655 Forward-Port-Of: odoo/enterprise#59554
Since when we generate an offer, we can provide a specific job and department, that will be set on the user and used in the pdf contract signed. We should also get this job and departement correctly set on the new contract which is not the case for now. So we first choose to use the info comming from the offer before the one from the contract template. Forward-Port-Of: odoo/enterprise#59662
Original PR description
Since when we generate an offer, we can provide a specific job and department, that will be set on the user and used in the pdf contract signed. We should also get this job and departement correctly set on the new contract which is not the case for now. So we first choose to use the info comming from the offer before the one from the contract template. Forward-Port-Of: odoo/enterprise#59662
# Description When opening the balance sheet in the cash basis method, the queries, generated by `_compute_formula_batch_with_engine_domain`, for the report can be slow. The issue is that they filter by date, which can be slower the more data the `temp_account_move_line` table contains. # Fix To speed up these queries, I added a composite index on the date and a few other fields. Since the index is added to a temporary table, it will be removed when the table is dropped. # Benchmark
Original PR description
# Description When opening the balance sheet in the cash basis method, the queries, generated by `_compute_formula_batch_with_engine_domain`, for the report can be slow. The issue is that they filter by date, which can be slower the more data the `temp_account_move_line` table contains. # Fix To speed up these queries, I added a composite index on the date and a few other fields. Since the index is added to a temporary table, it will be removed when the table is dropped. # Benchmark (in 17.0) | Cash Basis | Before | After | |------------|-------:|------:| | 1K | 250ms | 200ms | | 80K | 22s | 4s | | 180K | 30s | 4s | | 280K | 54s | 4s | (In this case, the 4 seconds come mainly from the SELECT for payment_table). # Reference opw-3782652 Forward-Port-Of: odoo/enterprise#59376 Forward-Port-Of: odoo/enterprise#59005
Account 1611 Crediti per ritenute subite (appoggio) which is created by the l10n_it_edi_withholding module was not referenced in the Balance Sheet. We fix this now. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59148
Original PR description
Account 1611 Crediti per ritenute subite (appoggio) which is created by the l10n_it_edi_withholding module was not referenced in the Balance Sheet. We fix this now. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59148
Open customer form view Issue : Name for the field 'l10n_mx_edi_operator_licence' is not visible This occurs because the xpath position the field after the vat which is inside a div made to show the Tax information opw-3819273 Forward-Port-Of: odoo/enterprise#59807
Original PR description
Open customer form view Issue : Name for the field 'l10n_mx_edi_operator_licence' is not visible This occurs because the xpath position the field after the vat which is inside a div made to show the Tax information opw-3819273 Forward-Port-Of: odoo/enterprise#59807
follow up to https://github.com/odoo/enterprise/pull/58895 Steps to reproduce: - Install ups_rest - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: if a new acces token is requested we need sudo accesn to update the carrier access token opw-3771840 Forward-Port-Of: odoo/enterprise#59811
Original PR description
follow up to https://github.com/odoo/enterprise/pull/58895 Steps to reproduce: - Install ups_rest - Configure the new ups shipping method as admin - Create an SO and try to add ups delivery as demo - Access error Bug: if a new acces token is requested we need sudo accesn to update the carrier access token opw-3771840 Forward-Port-Of: odoo/enterprise#59811
The computed stored field l10n_mx_edi_payment_method_id of account_move in l10n_mx_edi can lead to MemoryErrors during module installation in some large databases. To fix that, this commit first creates the field's column in _auto_init, avoiding the recomputations that overfill the field_cache and lead to MemoryErrors. Then, since inside the field's compute method the field should be set to a specific payment_method defined in the module's data files, change the post_init_hook to set the paym
Original PR description
The computed stored field l10n_mx_edi_payment_method_id of account_move in l10n_mx_edi can lead to MemoryErrors during module installation in some large databases. To fix that, this commit first creates the field's column in _auto_init, avoiding the recomputations that overfill the field_cache and lead to MemoryErrors. Then, since inside the field's compute method the field should be set to a specific payment_method defined in the module's data files, change the post_init_hook to set the payment_method to the correct id in the database after data files loading. I missed it in PR odoo/enterprise#30929 because this field was changed to a computed field starting v15. opw-3018535 Forward-Port-Of: odoo/enterprise#59069 Forward-Port-Of: odoo/enterprise#34974
When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condi
Original PR description
When a task and a ticket share the same ID, the _search_user_timer_id method will not work and provide the wrong result when using User Timer as the filter. Steps to reproduce: Having a task and a ticket with the same ID. Start the timer in the task. Go to the ticket and filter by "User Timer is set" There will be a ticket without a timer running but still showing in the search result. Cause The search method did not take into consideration of model. Solution Add model as a condition when searching timer records Forward-Port-Of: odoo/enterprise#59398
Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one). Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs. This commit makes sure to consider this 'ano
Original PR description
Chilean ecommerce checkout flow was consistently breaking when automatic invoice was enabled (Sale settings), for customers choosing the 'Ticket' option (not the 'Invoice' one). Indeed, choosing the 'Ticket' options sets a generic 'Anonymous' customer as billing address, but since this address is incomplete, the customer is redirected to the page to complete it, even though they don't have the rights to update that address since it's not theirs. This commit makes sure to consider this 'anonymous' billing address as being always complete, even if some fields are empty. opw-3792844 Forward-Port-Of: odoo/enterprise#59351
The issue: Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback The fix: Ignore the lines with the zero percent opw-3785700 Forward-Port-Of: odoo/enterprise#58444
Original PR description
The issue: Go to Accounting > Reporting > Journal Report, if you have a tax with a distribution invoice/refund line that has a zero percent line, this will cause a Division By Zero traceback The fix: Ignore the lines with the zero percent opw-3785700 Forward-Port-Of: odoo/enterprise#58444
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
Original PR description
…cess Because of Ponto that puts its consent expiration date in _get_accounts we need to move the _get_consent_expiring_date flow after the success call so that the expiration date is set correctly. task-id: 3619486 odoofin: https://github.com/odoo/odoofin/pull/236 Forward-Port-Of: odoo/enterprise#59683 Forward-Port-Of: odoo/enterprise#52319
**Coverage for community fix** https://github.com/odoo/odoo/pull/157515 opw-3754297 Forward-Port-Of: odoo/enterprise#59301 Forward-Port-Of: odoo/enterprise#58264
Original PR description
**Coverage for community fix** https://github.com/odoo/odoo/pull/157515 opw-3754297 Forward-Port-Of: odoo/enterprise#59301 Forward-Port-Of: odoo/enterprise#58264
30 changes
Security fixes and vulnerability patches
This fix strengthens privacy controls in the Calendar module by preventing uninvited administrators from viewing private event details. Only event organizers and attendees can now access private event information, ensuring confidential meetings remain protected. The update includes new safeguards to prevent unauthorized editing of any events by uninvited admins.
Original PR description
This commit reverts [#133504](https://github.com/odoo/odoo/pull/133504), as it was deliberating access to private event information to uninvited administrators in the calendar view. Only the event organizer and its attendees must be able to fetch private events information. In addition, two tests have been added to: 1. ensure the confidentiality of private events from uninvited administrators and 2. prohibit uninvited administrators from edit the information of any event, private or not. task-3837646 Forward-Port-Of: odoo/odoo#159743
Enhancements to existing features
This update improves how subscription payment links are processed by ensuring payment tokens are only created when the payment amount meets or exceeds the subscription's recurring amount. This prevents invalid payment processing and ensures customers are charged the correct amount for their subscriptions.
Original PR description
opw-3736162 **UPDATE**: this PR caused regressions, follow-up here: https://github.com/odoo/enterprise/pull/61025
This update enhances the online checkout process by converting the order summary into a collapsible dropdown (similar to the mobile experience), removing unnecessary labels, and making the payment button always visible by keeping the order summary sticky. These changes create a cleaner, more intuitive checkout flow that reduces clutter and improves accessibility to the payment action.
Original PR description
- replace order summary by a dropdown like mobile view - remove 'Pay With' title - match 'Choose delivery method' style with 'Choose payment method' - make order summary sticky so that 'Pay now' is always accessible task-3741412 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The color picker tool now works more smoothly when entering hex color codes. Users can type color values without the "#" symbol and it will be added automatically, and the color preview updates instantly as they type. Additionally, the color picker no longer closes unexpectedly when clicking in the input area, making it easier to enter and confirm color selections.
Original PR description
**[IMP] web_editor: prevent the colorpicker from closing on inner click** Before this commit, clicking in the area below the "Hex color" input would close the color picker. This was annoying when entering a value in the "Hex color" input and then clicking below to confirm it. After this commit, the color picker no longer closes when clicking on its background. task-3747408 ----------------------- **[IMP] web: update the colorpicker on hex color input's input event** This commit improves the UX of the color picker's hex input in two ways: If the user enters a hex color without the "#" symbol, it's automatically added. As soon as a valid hexadecimal color is entered in the input, the colorpicker updates, and the color is applied to the target element. task-3747408
This update improves how Odoo handles journal imports from French FEC files by adding a context option to skip automatic mail alias creation. This prevents errors that occur when multiple journals with the same name but different codes are imported, as each would attempt to create a mail alias with the same name. The change ensures smoother data imports without duplicate alias conflicts.
Original PR description
This is done together with an enterprise commit in order to avoid creating mail alias automatically on journals imported via FEC files, in France. Indeed, such files could contain journals with different codes but same name, each of which would try creating an alias with the same name, raising an error. OPW 3813584 Forward-Port-Of: odoo/odoo#160037 Forward-Port-Of: odoo/odoo#159455
This update improves the automated testing system by providing more detailed information when errors are detected during tests. Instead of just reporting that an error occurred, the system now logs the actual error message and related technical details, making it easier for developers to diagnose and fix issues.
Original PR description
Before this commit, when the clickbot detected an error dialog, it stopped the test and throw an error saying that an error dialog was detected. This information is not enough to check why, and how, the error dialog was produced. Now, we also log the content of the error dialog as well as all the information of the last rpc that was in error. closes odoo/odoo#160103 X-original-commit: 4f26b324a30c5120ea60b6b42fef6cd6000d2859
This update adds the ability to set a maximum number of files that can be uploaded in many-to-many binary fields. This improvement addresses cases where users may have incorrectly used a many-to-many relationship when a simpler structure would be more appropriate, providing better control over file uploads in the WhatsApp integration and other features.
Original PR description
[IMP] web: allow to give a maximum of file to upload in m2m binary People may have used a m2m where we don't really want a m2m relationship. Task-3605612 (WhatsApp: Fix header / upload / reporting usage) Forward-Port-Of: odoo/odoo#159973 Forward-Port-Of: odoo/odoo#157576
This update aligns how portal controllers handle parameters with the backend system controllers. Specifically, the portal_chatter_post and attachment_add functions are being updated to match backend behavior. This is a preparatory change to eventually replace the portal chat feature with the backend chat feature, reducing code duplication and maintenance effort.
Original PR description
This change is a preparation to sync parameters in portal controllers with the backend ones (`portal_chatter_post`, `attachment_add`) in order to reduce the diff in replacing portal chatter with backend chatter. Related to task-2828744
Resolved issues and error corrections
Fixed an issue where the "Create Invoice" button was not appearing when selecting tasks in the Field Service module. The problem was caused by an incorrect context key that was being automatically removed by the system. The fix uses the correct context key to ensure the button displays properly when users select tasks to invoice.
Original PR description
### Steps to reproduce issue: 1. Go to _Field Service > All Tasks > To Invoice_ - If no task is shown, remove To Invoice filter 3. Click on the checkbox of a task 4. The button Create Invoice should appear next to the Print and Actions buttons but it does not ### Explanation: The context key used to show the element contains a `search_default` prefix. Keys with this prefix are specifically used to create a search filter and are deleted in the process. https://github.com/odoo/odoo/blob/71c81e605b2f06889ad8031f021863638edab268/addons/web/static/src/search/search_model.js#L291-L300 ### Suggested fix: No existing key in the context is specific to the action nor is their value. Adding a new specific context key prevents unintended behaviours. opw-3773005
This fix corrects how shipping rates are selected from Sendcloud. Previously, the system was comparing prices as text rather than numbers, causing it to sometimes choose more expensive shipping options (e.g., selecting $11.00 instead of $9.00). The fix ensures prices are properly converted to numbers before comparison, so customers always get the lowest available shipping rate.
Original PR description
Before this commit, the lowest shipping rate was used as the delivery cost, as in: https://github.com/odoo/enterprise/blob/8c40ba77b23c4ccd24c3785bc1e6cf5b3fbe0e51/delivery_sendcloud/models/sendcloud_service.py#L91 However, the prices received from the Sendcloud are strings, and as a result, this line returned the rate with the lowest lexicographical order. As a result, sometimes the rates with a higher value were chosen. The issue happens when a shipping product costs a single digit amount (e.g. `9.00`) but a second product costs in double digits (e.g. `11.00`). In this case the latter is used which is wrong. This commit, converts the prices to float before comparing them to get the actual best price. opw-3815117
This update fixes a system crash that occurred when UPS shipping alerts lacked a description field. The system now properly handles alerts from UPS regardless of whether they include descriptions, ensuring smooth delivery processing without interruptions.
Original PR description
It happens that the alerts message returns by UPS doesn't contains a descirption. In that case the dictionary has no key and traceback. Only returns alerts with description Forward-Port-Of: odoo/enterprise#59606
This fix corrects an issue where custom field labels in worksheets were not displaying correctly for portal users. When a worksheet field had a custom label (like "Proute" for an ID field), portal users would see the default field name instead. The fix ensures that custom labels are properly used when available, improving the consistency of the worksheet experience across all users.
Original PR description
Steps: In the default worksheet template, add the field "ID" and change its label as "Proute". Go to a helpdesk ticket, and create a worksheet. See that the label is "Proute". Now share it with a portal user. Log in as that user, and go on the ticket. Issue: The label of the worksheet's field is "ID". Cause: The back-end template uses `<field name="id" string="Proute">`. It is then translated to a qweb as `<div string="Proute">ID</div>` because it sets the name of the field as the description. Fix: Set the string of the tag if any, or else the name of the field. task-3479545 Forward-Port-Of: odoo/enterprise#47803
This update removes an outdated field from the appointment calendar view that was previously replaced with a newer resource management system. The change ensures the calendar interface displays only current, relevant fields and prevents confusion from duplicate or obsolete options.
Original PR description
Hide correctly appointment_resource_id in the calendar event form view as it has been replaced by resource_ids. task-3839587
This update adds database indexes to speed up the deletion of partner records. Previously, deleting a partner required the system to scan entire tables to find and update related records, which could take a long time. With these new indexes, the system can now quickly locate the relevant records, making partner deletion significantly faster and more efficient.
Original PR description
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406
Fixed an issue where importing FEC files with journals having the same name but different codes would cause errors when trying to create duplicate mail aliases. The system now prevents automatic mail alias creation during FEC imports, allowing users to add them manually later if needed.
Original PR description
It is possible that a FEC file contains journals with different codes but same name. In such case, each of these would try to create a distinct mail alias with the same name ; this is not allowed and raised an error. We now prevent that by not generating any mail alias by default on journals imported via FEC. They can still be added later on by the user if he wishes to do so. OPW 3813584 Forward-Port-Of: odoo/enterprise#59859 Forward-Port-Of: odoo/enterprise#59527
This fix resolves a problem that occurs when the IoT application is uninstalled from a Point of Sale system. Previously, an internal flag was not being reset during uninstall, which caused errors when trying to install other modules afterward. The fix ensures the flag is properly cleared when IoT is removed, preventing installation failures in related modules.
Original PR description
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:…
In `pos_enterprise` we alias `is_posbox` as `module_pos_iot`. If the value is True we install the module `pos_iot` when a write in pos.config model happens:
https://github.com/odoo/odoo/blob/f7ee5633a8c80afca05074b8574e9c2a720e4bc9/addons/point_of_sale/models/pos_config.py#L496
Steps to reproduce:
1. Install PoS and IoT applications -- will install `pos_enterprise` module.
2. Set is_posbox = True, via the PoS settings.
3. Uninstall IoT application -- will uninstall `iot` and `pos_iot` modules.
4. Try to install a module that writes in a column of the pos_config with is_posbox=True
We get an error like:
```
...
File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_module.py", line 569, in _button_immediate_function
raise UserError(_('The method _button_immediate_install cannot be called on init or non loaded registries. Please use button_install instead.'))
odoo.exceptions.UserError: El método _button_immediate_install no puede ser llamado en registros init o no cargados. Por favor, utilice button_install en su luga
```
The issue is that when we uninstall `iot` module the flag is never reset. This then causes issues if we try to install a module that writes on any value of `pos.config`. Observed during upgrades, e.g `l10n_es_pos` at xml load of data files. Other modules also affected.
The solution we propose here is to introduce a _soft_ dependency between pos_iot -- which is an enterprise module -- and pos_enterprise. The former checks at uninstall if the latter is installed to clear the `is_posbox` flag.
Forward-Port-Of: odoo/enterprise#59810This update resolves multiple issues discovered during months of WhatsApp integration usage. It fixes template duplication problems, message retry failures, variable naming inconsistencies, and prevents system crashes in specific scenarios. The changes also enable sending messages with templates flagged as lower-risk quality warnings and improve overall system stability.
Original PR description
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for…
Provide fixes after some months of using WhatsApp. See sub tasks / sub PRs for more details, each being related to a specific issue to fix. Task-3807017, master fix task Contains fixes done for following tasks / tickets * Task-3619004 (WhatsApp: Fix variable computation and name) * Task-3680030 (WhatsApp: Fix buttons / template duplication) * Task-3829328 (WhatsApp: Allow to send yellow quality templates) * Task-3644990 (Whatsapp: Fix retrying message with report on template) * Task-3679715 (WhatsApp: Fix cron block or crash with shared users) * Task-3576712 (WhatsApp: Sync template attachments at sync, avoid missing) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3605612 (WhatsApp: Fix header / upload / reporting usage) * Task-3640336 (WhatsApp: Fix Document Header / Report mismatch) * Task-3794483 (WhatsApp: Add account information in template views) * Task-3794365 (WhatsApp: Ease module / variable name change) * Task-3691887 (WhatsApp: Avoid draft templates in event mail schedulers) * Task-3732188 (Whatsapp Event: Avoid crashing registration process) Co-Authored-By: Amélie Dieudonné <amdi@odoo.com> Co-Authored-By: Akshat Trivedi <aktr@odoo.com> Co-Authored-By: Dato Nefaridze <dane@odoo.com> Co-Authored-By: Nishant Jain <niai@odoo.com> Co-Authored-By: Rahul Prajapati <rapr@odoo.com> Co-Authored-By: Noé Antoine <nan@odoo.com> Co-Authored-By: Thibault Delavallée <tde@odoo.com> Forward-Port-Of: odoo/enterprise#59815 Forward-Port-Of: odoo/enterprise#58535
Read-only accounting users were unable to access the Accounting App Dashboard due to missing permissions for bank connection records. This fix grants read-only access to bank connection and account records for users with read-only accounting privileges, allowing them to view banking information without being able to modify it.
Original PR description
In the system parameters, switch account_online_synchronization.proxy_mode to sandbox
Add a bank with plaid for example and follow the different steps
Have a user [DEMO] with Accounting access set to 'Read-only'
Log in with [DEMO]
Try to access the Accounting App Dashboard
Issue:
Access Error
"""
You are not allowed to access 'Bank Connection' (account.online.link) records.
This operation is allowed for the following groups:
- Accounting/Accountant
- Accounting/Bookkeeper
Contact your administrator to request access if necessary.
"""
This occurs because the read access to the account.online.link
and account.online.account records is granted only to users having at
least the account.group_account_user group
But, as those accesses are defined to be read only, it should be
greanted also to account.group_account_readonly users
opw-3821540This update fixes an issue where users would see duplicate error messages when a website page fails to save. Previously, when an error occurred during saving, both a popup notification and an error dialog would appear, creating confusion. The fix ensures users only see one clear error message displayed as a popup on the edited content block.
Original PR description
If an error happens when a website page is being saved, the error message is displayed as a popup on the edited block. Unfortunately, an error dialog is also displayed. This commit prevents that dialog from being displayed when the error is already shown to the user. task-3599890 Forward-Port-Of: odoo/odoo#154050
This fix resolves an issue where changing text color on buttons in the website editor would cause an error. The problem occurred because the system was incorrectly handling the undo/redo history when color changes were applied. The fix ensures that color changes are properly saved and can be undone without errors.
Original PR description
Steps to reproduce the issue: ============================= - Go to website and open editor - Click on the 'Contact Us' button - Change the color of the text - error Origin of the issue: ==================== `HistoryReverCurrentStep` will call `observerFlush` which will mark `_toRollback = true` and in `_observeOdooFieldChanges` we will update the html with `withoutRollback` but this only works only if `_toRollback` is `false`. Solution: ========= We need to rever the step without rollback too. task-3770287
This fix corrects a display issue in spreadsheets where aggregated values that equal zero (such as 9000 + -9000) were incorrectly shown as empty cells instead of displaying "0". Users will now see the correct zero value in their spreadsheet calculations, ensuring accurate data representation.
Original PR description
When the aggregated value is 0 (9000 + -9000 = 0), it displays an empty cell in spreadsheet, instead of zero. Task: 3827502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug in the Payment Receipt printing feature was causing the invoice number placeholder to display incorrectly in the title. The fix corrects the HTML formatting to properly embed the invoice number within the document title when printing payment receipts.
Original PR description
## Issue: - When printing a Payment Receipt the name "INV0001" is added to the title. ## Steps To Reproduce: - Accounting > Vendors > Payment - create new payment and print payment receipt. ## Solution: - The issue was using a self-closing <span> tag and incorrectly placing the INV0001 placeholder outside it. - I placed INV0001 within an opening and closing <span> tag for correct dynamic content replacement. opw-3820212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where customers couldn't use gift cards or eWallets when they had less than 1 point remaining. The system was incorrectly preventing redemption of these small balances. Now customers can use their remaining gift card balance regardless of the amount.
Original PR description
If user had less than 1 point, which is equivalent to 1 quantity of set currency, on gift card and eWallet, they could not use it due to not enough point on Gift Card and eWallet for claiming reward. opw-3667934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155161
This fix ensures that when creating invoices from Point of Sale transactions, the system now uses the customer's designated invoice address, just like the Sales app does. Previously, invoices were created with the main customer address instead of the specific invoice address, causing inconsistency between the two apps.
Original PR description
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address.…
Currently, when generating the invoice from the PoS shop, the invoicing address of the partner is not used. This differs from the invoice created using the sale app which uses the invoice address. Steps to reproduce: ------------------- * Go to the **Contacts** app * Select any contact (ex: Azure Interior) * Under **Contacts & Addresses** select Add * Select **Invoice Address** * Write the address then **Save & Close** * Go to the **Point of Sale** app * Add items * For customer, select the contact we just modified * Select **Payment** * Select any payment method * Select **Invoice** * Validate > Observation: The invoice address is not used Why the fix: ------------ We observe a discrepancy between the sale and pos output for the same workflow. * Sale * Sale order form: `Customer` -> Azure interior (Has a field for invoice address) * Account move form: `Customer` -> Azure interior, Az inv (Use the invoice address) * PoS * PoS order form: `Customer` -> Azure interior (Does not have a field for invoice address) * Account move form: `Customer` -> Azure interior In stable we can't add the invoice address on the PoS order form but we can still stay consistent with the sale workflow in terms of account move. In the sale workflow, the move is created with `invoice_vals_list` https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1207 Having a look at `invoice_vals_list`, we can see that the customer_id is set using the invoice contact address. https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L1004 With `partner_invoice_id` computed as follows: https://github.com/odoo/odoo/blob/d6973d3cd5ee48539b40f94b8444f5522a080438/addons/sale/models/sale_order.py#L340-L342 Thus, we also send the invoicing contact address as partner_id when creating the move in pos; opw-3797434 Forward-Port-Of: odoo/odoo#159856 Forward-Port-Of: odoo/odoo#159172
This update removes an outdated route from the live chat system that was no longer being used and was causing crashes when accessed. The route attempted to load templates that no longer exist in the system. This fix prevents errors and cleans up unnecessary code.
Original PR description
This route is no longer used in our code and it tries to read templates that are no longer existing, leading to a crash if called manually. Forward-Port-Of: odoo/odoo#160206
This fix addresses an issue where translation data fails to load correctly when item names contain dots. The system was splitting these names into too many parts instead of the expected two parts (module and name), causing database save failures. The fix ensures names are split into exactly two parts, allowing translations to load properly regardless of dots in the name field.
Original PR description
In `ir.model.data` model, there is no SQL constraint which is ensuring that the `name` field can not contain `.` (dot) So when loading the translations to database if the xmlid's `name` contains dot then `xmlid.split('.')` will split it more than 2 parts. Which will cause issue during saving it to database as it is expecting[^1] 2 parts `[<module>, <name>]`. I ensured the splitting to 2 parts with `maxsplit=1`
Description of the issue/feature this PR addresses:
Current behavior before PR:
It is splitting xmlids as many as possible parts.
Desired behavior after PR is merged:
It will split xmlid to the 2 parts `[module, name]`
[^1]: https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1326
and
https://github.com/odoo/odoo/blob/16.0/odoo/tools/translate.py#L1390
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160098This update adds database indexes to speed up the deletion of partner records. Previously, deleting a partner required the system to scan entire tables to find related records, which could take a long time. With these optimizations, partner deletions will now complete much faster, improving overall system performance.
Original PR description
Deleting a partner may take a long time because odoo has to check an entire table to find few records or no records at all that reference the partner and set it to null. So we are adding an index btree not null to speed up the deletion of partners. TASK-ID: 3759406 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The help text displayed in tooltips for the product margins report was not accurately describing the actual calculation being performed. This fix corrects the tooltip text to match the real calculation logic, ensuring users see accurate guidance when reviewing margin information.
Original PR description
Issue ----- The tooltip help text doesn't match the actual calculation made in the product margins report. **opw-3792181** Forward-Port-Of: odoo/odoo#159131
This update corrects the account type classification for Spanish equity accounts (accounts 10x through 13x) to properly reflect them as 'equity' type accounts. This ensures these accounts are correctly displayed under the Equity section of the Balance Sheet, improving financial reporting accuracy for Spanish companies using Odoo.
Original PR description
Accounts 10x -> 13x should be of 'equity' type. (In the Balance Sheet, they are referenced under the Equity section.) Enterprise PR: https://github.com/odoo/enterprise/pull/57117 opw-3743637 Forward-Port-Of: odoo/odoo#160161 Forward-Port-Of: odoo/odoo#154859
This update fixes an automated test for the live chat bot redirect feature. The test was failing because it wasn't properly waiting for the bot's confirmation message when testing multiple redirect scenarios. The fix ensures the test correctly validates that the chat bot continues to work properly after being redirected.
Original PR description
The `website_livechat.chatbot_redirect` tour checks that the chat bot still works after redirection. The tour waits for the chat bot message that indicates the redireciton was made. Since the tour restarts the bot to test two differents flows, this message is already present before the second redirection occurs. The tour should instead wait for two occurences of this message the second time. Forward-Port-Of: odoo/odoo#160276