Daily updates from Odoo
Navigate
Branch
Friday, October 18, 2024
89 changes
25 changes
Resolved issues and error corrections
Project visibility changes will continue to appear in the project’s own activity log, but they will no longer be repeated in individual task discussions. This keeps task chatter cleaner and focused on task-specific updates.
Original PR description
The project's visibility should be tracked in the chatter of the project, but not in the tasks chatter. This PR will set the tracking of the "project_privacy_visibility" field to False, so that it is no longer displayed in the tasks chatter. task-4210181
Closing a template-saving dialog from the full mail composer no longer triggers an error. This prevents an unnecessary traceback and keeps the message composer stable when users close related pop-ups before saving or cancelling.
Original PR description
- open a composer in full view - click to save a template - close the modal before saving/cancelling - get a traceback The issue is that `onClose` when passed to an action is called even if the dialog closed did not come from the original action. This seems intended as documented by `_removeDialog`. `onClose` needs to be able to handle the composer not being in the DOM at all. task-4246399
Receipts in Point of Sale no longer show a product/cart image when an order has no items. This avoids confusing or cluttered receipt previews and makes empty orders display more appropriately.
Original PR description
Before this commit: == - When there is no order line(s) in the order, a message saying 'Start adding products' along with a cart icon will be displayed on the receipt. After this commit: == - Added a check for the product image, which will be displayed when order line(s) exist. task - 4267700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Issue ----- The activities from the calendar, which should be today's meetings, are in some circumstances displaying meetings from the next day. Steps ----- - Set the user timezone to "Asia/Manila". - In Calendar, create a meeting early (before 18:00) the next day. - Check the activities (clock in the navbar), tomorrow's meeting appears. Cause ----- `datetime.datetime` objects are not timezone aware, and using the `replace` function on them will simply lead to a naive convers
Original PR description
Issue
-----
The activities from the calendar, which should be today's
meetings, are in some circumstances displaying meetings
from the next day.
Steps
-----
- Set the user timezone to "Asia/Manila".
- In Calendar, create a meeting early (before 18:00) the
next day.
- Check the activities (clock in the navbar), tomorrow's
meeting appears.
Cause
-----
`datetime.datetime` objects are not timezone aware, and using
the `replace` function on them will simply lead to a naive
conversion which causes potential issues.
Example:
```
import pytz
import datetime
dt = datetime.datetime(2024,1,1,0,0)
dt = dt.replace(tzinfo=pytz.timezone("Asia/Manila")).astimezone(pytz.UTC)
print(dt)
>>> 2024-01-01 15:56:00+00:00 # 1 day offset to expected result
```
Instead, it is better to use the pytz `localize` function.
opw-4142911
Forward-Port-Of: odoo/odoo#181795Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the
Original PR description
Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the edit plan button will be visible. Forward-Port-Of: odoo/odoo#182702
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make SO and add the same product to order line. - In the Product Configurator, there is no strikethrough price. Issue: When the comparison price is activated the strikethrough price is not visible in the product configurator Cause: There was no `compare_price_list` in the template, hence the co
Original PR description
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make…
Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make SO and add the same product to order line. - In the Product Configurator, there is no strikethrough price. Issue: When the comparison price is activated the strikethrough price is not visible in the product configurator Cause: There was no `compare_price_list` in the template, hence the comparison price was never visible. Fix: - Added the `compare_price_list` to the template using XPath because `compare_price_list` is added to the `combination_info` dictionary in the website_sale module and made it conditionally hidden using `t-if` (not with `d-none` as we do for other cases) because the same product configurator template is being used in the backend (like while making a Sale or Rental order) where the `compare_list_price` is not present in `combination_info` which gives a key not found error. opw-3992683 Forward-Port-Of: odoo/odoo#184100 Forward-Port-Of: odoo/odoo#171354
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing > Customers > Invoices > Select any invoice > Actions > Send payment status to SInvoice Traceback: ``` SyntaxError: syntax error at or near ")" LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO... ^ File "odoo/tool
Original PR description
When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing >…
When User Clicks on Send payment status to SInvoice action,
a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
Send payment status to SInvoice
Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
File "odoo/tools/safe_eval.py", line 391, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(2134,)", line 3, in <module>
File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
self.env['res.company']._with_locked_records(self)
File "addons/account/models/company.py", line 785, in _with_locked_records
self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
File "odoo/sql_db.py", line 347, in execute
res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
^
```
https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.
This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.
sentry-5954926261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#182621This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used
Original PR description
This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI"…
This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used to in the SPV. This might be caused by the state name. Changes: - After receiving the `key_download`, log it in the invoice's chatter. - Save the `key_download` data and pass it in-between documents, to make sure that relevant documents displays the index. (and the idx doesn't get lost when "sending" document is deleted) - Change the display name of the statuses of the document. - Add a tooltip on the E-Factura status fields (move & document). The create document function helpers are changed to have one dictionary as the param signature so that we can pass on the new `key_loading` data (and any other important data in the future, for easier stable fix), and also to make it general (the same for all ro-documents) task-id: 4059522 Forward-Port-Of: odoo/odoo#179278
Reproduce --- - -i event_crm_sale,website_event_questions - Create new "Lead Generation Rule" (Events/Configuration/Lead Generation) - "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]` - add some tag - Add new attendee to an EVENT - Add new question to the EVENT - BUG: `KeyError: 'registration_answer_ids'` opw-4125944 Forward-Port-Of: odoo/odoo#179734
Original PR description
Reproduce
---
- -i event_crm_sale,website_event_questions
- Create new "Lead Generation Rule" (Events/Configuration/Lead Generation)
- "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]`
- add some tag
- Add new attendee to an EVENT
- Add new question to the EVENT
- BUG: `KeyError: 'registration_answer_ids'`
opw-4125944
Forward-Port-Of: odoo/odoo#179734**Rational:** for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user. **Note:** We apply exactly the same logic as for the model sale.order and sale.order.line. See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15 F
Original PR description
**Rational:**
for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user.
**Note:**
We apply exactly the same logic as for the model sale.order and sale.order.line.
See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15
Forward-Port-Of: odoo/odoo#183045Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#183687 Forward-Port-Of: odoo/odoo#183614
Original PR description
Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#183687 Forward-Port-Of: odoo/odoo#183614
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179344
Original PR description
Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179344
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable #
Original PR description
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a…
### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable ### Cause of the issue: Since you unreserved the PICK delivery, the demand of the outgoing move is not null in the forecast lines computations: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L278 In addition, since you deliver in 2 steps the outgoing moves are part of a move chain. To generate this chain, the moves were created with an `make_to_order` `procure_method` and as such, the quantity considered to reconcile this move from stock is set to be at 0 here: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L283-L287 Furthermore, since there is no incoming moves made to reconcile this outgoing move (whcih happen for real "MTO" moves and not these flagged as MTO because they were part of a chain) the line will be created here and flagged as not repleinshed nor available: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L295-L299 The forecast error ### Note: The issue is not reproducible in 16.0 since the forecast datas computed by the `_get_report_lines` was drastically prior to the 17.0 version. opw-4164403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#183526 Forward-Port-Of: odoo/odoo#183211
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06
Original PR description
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located…
Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12) 2- We moved the taxes from files to match the same structure as l10n_ar Current behavior before PR: After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates. [[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a) Desired behavior after PR is merged: The taxes are no longer duplicated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168945
Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined. Forward-Port-Of: odoo/odoo#184113
Original PR description
Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined. Forward-Port-Of: odoo/odoo#184113
The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608 Forward-Port-Of: odoo/odoo#181399
Original PR description
The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608 Forward-Port-Of: odoo/odoo#181399
Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a defau
Original PR description
Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a default rule, we skip the test if account is not present but hr.timesheet is. runbot-100530 Forward-Port-Of: odoo/odoo#184067
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guid
Original PR description
**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180187
This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#183772 Forward-Port-O
Original PR description
This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#183772 Forward-Port-Of: odoo/odoo#183730
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS op
Original PR description
- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS opw-4131695 Forward-Port-Of: odoo/odoo#178844
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-
Original PR description
Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182156
Steps to reproduce: - install project app - create project without any task - change the language Issue: The helper string is not being translated. Reason: This issue occurs because the existing context is lost, particularly the `lang` variable, which impacts the translation functionality. Solution: In this commit, we have updated the method from with_context({'active_id': self.id}) to with_context(active_id=self.id). This fix ensures that the previous context is ret
Original PR description
Steps to reproduce:
- install project app
- create project without any task
- change the language
Issue: The helper string is not being translated.
Reason:
This issue occurs because the existing context is lost, particularly
the `lang` variable, which impacts the translation functionality.
Solution:
In this commit, we have updated the method from
with_context({'active_id': self.id}) to with_context(active_id=self.id).
This fix ensures that the previous context is retained.
task-3940540
Forward-Port-Of: odoo/odoo#184149
Forward-Port-Of: odoo/odoo#170720We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#183359
Original PR description
We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#183359
There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form is submitted Both call self._login_redirect but only the latter updates the env and context. This is a snippet to reproduce the bug: ```python @http.route() def web_totp(): response = super().web_totp(*args, **kw) if not request.env.user or request.env.user.is_public:
Original PR description
There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form…
There are two paths for a successful login via web_totp
1. The user has a cookie saved which saves them from having to enter the TOTP
2. The user is a new device / browser, enter the TOTP and a form is submitted
Both call self._login_redirect but only the latter updates the env and context.
This is a snippet to reproduce the bug:
```python
@http.route()
def web_totp():
response = super().web_totp(*args, **kw)
if not request.env.user or request.env.user.is_public:
return response
do_something()
...
```
This would call `do_something` only when a user successfully logs in by putting the TOTP explicitly but not when they log in thanks to a cookie being set.
Description of the issue/feature this PR addresses:
Makes web_totp consistent for the 2 flows (submit totp or use cookie)
Current behavior before PR:
A code logic that works for web_login does not work for web_totp, or rather, it works only for one flow but not the other
Desired behavior after PR is merged:
A code logic that works for web_login also works for web_totp
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#183838Current behavior before PR: -Nested list numbering appeared differently in the preview compared to printed PDFs, causing inconsistencies in document appearance. Desired behavior after PR is merged: -Nested list numbering appears consistent between the preview and printed PDFs. task-4008883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172626
Original PR description
Current behavior before PR: -Nested list numbering appeared differently in the preview compared to printed PDFs, causing inconsistencies in document appearance. Desired behavior after PR is merged: -Nested list numbering appears consistent between the preview and printed PDFs. task-4008883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172626
31 changes
New functionality added to Odoo
Documents now includes a dedicated Trash folder where archived files are gathered from all folders, replacing the previous archived filter. Files in Trash will be automatically deleted after 30 days, so users should use regular folders for long-term archiving.
Original PR description
Adds a new Trash folder (fake folder) within the documents views, it will contain any file that has been archived from any folder. We also remove the archived filter as we now want user to use that fake folder instead. Archived documents will now be deleted after 30 days. Users are invited to managed "archives" using regular folders instead of actually archiving files if they do not want their files to be deleted after 30 days. TaskId-3046516
Intrastat reports can now include service transactions, not just goods, helping businesses meet reporting requirements such as Belgian F01DGS and F02CMS declarations. The existing report gains service-focused filters, categories, and codes so users can manage commodity and service reporting in one place.
Original PR description
Currently, the Intrastat report is restricted to products whose product type is different than services. Though, statistics report can also be required on Services, such as Declarations F01DGS & F02CMS (Manual : https://www.nbb.be/doc/dq/e_pdf_bb/f01dgs-f02cms_manual_en.pdf) This commit intend to improve the Intrastat report to also include services. Since both the commodities and the services share a lot of similarities, we didn't create a new report but rather added a filter inside the current Intrastat report. It also adds a new column for the category of the service and all the service codes. On the product, the string of the commodity code changes if the product is a commodity or a service ( and become Service Code in that case) task-2835786
Enhancements to existing features
Brazilian electronic invoicing now shows the CFOP fiscal code calculated for each invoice line before submission. This helps users spot configuration issues earlier and avoid correcting or reversing electronic invoices after they have been issued.
Original PR description
Avatax determines the CFOP [1] of each invoice line during tax calculation. It bases it on the chosen operation type, product, contact and company configuration. The CFOP values are submitted during electronic invoicing. Displaying them to the user before electronic invoicing gives the user a chance to detect misconfiguration earlier, and correct it without having to deal with reversing an electronic invoice. This commit updates the translations to include these new terms, and also cleans them up so they match the code again [2]. [1] Código Fiscal de Operações e de Prestações: a fiscal code defined by the Brazilian authorities to describe the type of business transaction. [2] Went out of sync due to 402326b64c14faf1658fc1c42ca19218df4c401d not updating the translations. task-4250764
Document requests now better reflect who asked for the file by showing the requester as the owner, making follow-up responsibilities clearer. Users can also reply to request emails with an attachment to submit the requested document, and teams can send reminder emails for overdue requests.
Documents now keeps the selected workspace, categories, and filters in the page URL. This lets users share a link that opens directly to the same Documents workspace and view, reducing navigation time and confusion.
Original PR description
The documents view will now track the current workspace in the url, making it possible to directly share a specific workspace with a colleague. Instead of the link landing on the last workspace/the first workspace available. TaskId-3128953
Odoo now avoids labeling all internal RPC errors with a misleading success-like code. This makes error reporting clearer for integrations and support teams, reducing confusion when diagnosing issues across accounting, reports, mobile, and Studio features.
Original PR description
The JSONRPC specification specifies what "code" should be used with what kind of errors. Odoo never cared to implement those errors correctly and frankly 200 is the single worst value to pick. Use 0 instead. It doesn't respect the specification either but at least it is not 200. task-4257153
Projects created from helpdesk teams will now have the Documents feature turned off by default. This keeps new helpdesk-related projects simpler and avoids enabling document management unless the business chooses to use it.
Original PR description
_*= helpdesk_sale_timesheet Currently, the 'documents' feature is enabled by default on the projects created from the helpdesk team. This commit ensures that the 'documents' feature is disabled by default on projects created from helpdesk teams. task-3996664
Timesheet grid configuration now supports specifying the right display widget directly instead of relying on a workaround. This helps prevent future warning messages and keeps the timesheet interface more reliable as validation is tightened.
Original PR description
Until now, if a widget needed to be specified for the renderer, a hack was needed, the widget needed to be set as a field type. The task 4224192 aim to add a warning when using a widget on a wrong field (field type) and the current hack will raise the warning. This commit adds widget, a new parameter, to the getPropertyFieldInfo function. This parameter, will allow specifying the widget that we want to use on the fieldInfo. task-id: 4224192
GSTR-1 reports now use the original invoice amount when reporting credit and debit notes, improving accuracy for Indian GST filings. If a credit note is missing its linked invoice, the report warns users and the credit note form now provides a field to select the original invoice.
Original PR description
Previously, in the GSTR-1 report, credit and debit notes were reported based on their own amounts. With this PR, the reporting will now check the amount of the original invoice. Additionally, if a credit note is created without an associated invoice, the user will receive a warning in the report, and a field will be displayed in credit notes to select the original invoice. task-4175690
This update improves how social media feeds load across supported platforms, reducing waiting time for users managing social content in Odoo. It should make day-to-day monitoring of Facebook, Instagram, LinkedIn, X/Twitter, and YouTube streams feel more responsive.
Original PR description
Task-4146092
Resolved issues and error corrections
This change prevents an error from appearing when completing a sale and reaching the receipt screen in Point of Sale with Urban Piper enabled. It updates the receipt layout handling so customers and staff can finish transactions smoothly without interruptions.
Original PR description
Steps to Reproduce: === - Install the point_of_sale and pos_urban_piper. - Add some items to the cart. - Proceed with the payment process. - A trackback error occurs. Issue: === - Traceback at receipt screen. Cause: === - After this PR (https://github.com/odoo/odoo/pull/181345) x-path not found. Fix: === - Handle x-path correctly. Additional improvement: === - Before this commit  - After this commit  task-4247002
Code cleanup and technical improvements
This internal cleanup makes Point of Sale records keep their related information in sync automatically when values are changed. It reduces the chance of developer mistakes and supports more reliable behavior across localized POS features such as Chilean and Ecuadorian electronic invoicing and due settlement.
Original PR description
In this commit, we are now instantiating a record as a Proxy that traps the setter. When setting a value for a certain key on a record, we call the `update` internally to ensure that related records are linked. This means that developers are no longer required to use `record.update` to apply changes on a record, they can just set the value as if the record is a normal object. Community: https://github.com/odoo/odoo/pull/184108
US payroll state tax calculation functionality has been consolidated into the main US payroll module. This simplifies maintenance and keeps payroll configuration in one place without changing the business purpose of the feature.
Original PR description
The module l10n_us_hr_payroll_state_calculation was added in 17.0. In master, it needs to be merged to l10n_us_hr_payroll. Task: 4191924
Miscellaneous changes
Steps: - create 2 boms: -- bom_A: product_A with component_A -- bom_B: product_B with component_B - add all 4 products to the MPS - go to bom_A and click on the 'Schedules' smart button, there should only be 2 records (product_A & component_A) - open the search dropdown menu and select a 'Rows' option Issue: When changing the rows to be shown in the MPS (e.g. Actual Demand), OWL calls `write` directly via the orm on res.company because those fields are set on res.company. This is du
Original PR description
Steps: - create 2 boms: -- bom_A: product_A with component_A -- bom_B: product_B with component_B - add all 4 products to the MPS - go to bom_A and click on the 'Schedules' smart button, there should…
Steps:
- create 2 boms:
-- bom_A: product_A with component_A
-- bom_B: product_B with component_B
- add all 4 products to the MPS
- go to bom_A and click on the 'Schedules' smart button, there should
only be 2 records (product_A & component_A)
- open the search dropdown menu and select a 'Rows' option
Issue:
When changing the rows to be shown in the MPS (e.g. Actual Demand),
OWL calls `write` directly via the orm on res.company because those
fields are set on res.company. This is due to 'company_service.js':
```js
if (!error && model === "res.company" && UPDATE_METHODS.includes(method)) {
if (!browser.localStorage.getItem("running_tour")) {
action.doAction("reload_context");
}
}
```
This cause the page to do a full refresh, which loses the domain.
Fix:
This fix makes it so that when changing the rows in the search menu,
OWL calls a specific function that will do the same job but without
the full reload, thus keeping the domain.
Forward-Port-Of: odoo/enterprise#72215Since [odoo/pull/176483](https://github.com/odoo/odoo/pull/176483), the product_document_kanban_controller methods have been modified but in MRP. This commit fixes it. Before ------ When clicking on the document icon of a bom line, and then adding a document, the document whill shortly appear and then disappear because the visibility is not set on bom https://drive.google.com/file/d/1gXiqtU3zEoFP76ue2pk-0FHnf5MyRT-P/view The same logic applies to PLM After ----- The document visibility
Original PR description
Since [odoo/pull/176483](https://github.com/odoo/odoo/pull/176483), the product_document_kanban_controller methods have been modified but in MRP. This commit fixes it. Before ------ When clicking on the document icon of a bom line, and then adding a document, the document whill shortly appear and then disappear because the visibility is not set on bom https://drive.google.com/file/d/1gXiqtU3zEoFP76ue2pk-0FHnf5MyRT-P/view The same logic applies to PLM After ----- The document visibility is set on 'bom' and the document is visible when added Forward-Port-Of: odoo/enterprise#72272
Before this commit: === - When attempting to open a session, when there is no API key and username in pos_config, a validation error occurred. After this commit: === - No validation error occurs when the API key and username are missing in pos_config. task-4266405 Forward-Port-Of: odoo/enterprise#72183
Original PR description
Before this commit: === - When attempting to open a session, when there is no API key and username in pos_config, a validation error occurred. After this commit: === - No validation error occurs when the API key and username are missing in pos_config. task-4266405 Forward-Port-Of: odoo/enterprise#72183
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration
Original PR description
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration, on the move we will have 2 tax lines for the same tax, as the lines needs a different analytic account and cannot be grouped together. When we compare the amount per tax we'll have a recordset and it will raise an error. A solution is to acknowledge that we might have more than 1 line and split the possible difference evenly on the tax lines opw-3976597 Forward-Port-Of: odoo/enterprise#71937 Forward-Port-Of: odoo/enterprise#69090
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589 Forward-Port-Of: odoo/enterprise#72225 Forward-Port-Of: odoo/enterprise#71243
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#72240 Forward-Port-Of: odoo/enterprise#71741
Original PR description
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#72240 Forward-Port-Of: odoo/enterprise#71741
The issue occurred because `vals_list` is a list of dictionaries, and calling `get()` on it caused an AttributeError. Updated the logic to iterate over the list and properly handle each dictionary entry. Forward-Port-Of: odoo/enterprise#72180
Original PR description
The issue occurred because `vals_list` is a list of dictionaries, and calling `get()` on it caused an AttributeError. Updated the logic to iterate over the list and properly handle each dictionary entry. Forward-Port-Of: odoo/enterprise#72180
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Original PR description
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Starting from 18.0, the default shopfloor filter "This Station" was removed from existence. See Commit 4e6038617586b669c00a23da0ea4355f869ecc94 This filter was initially added to odoo for performance reasons [1] and was removed since the shopfloor performance do not require it anymore to work properly. However, this filters appeard to be usefull for certain user in case for instance they want to filters out all the MO's that do not have an operation which belongs to at least one of the selected
Original PR description
Starting from 18.0, the default shopfloor filter "This Station" was removed from existence. See Commit 4e6038617586b669c00a23da0ea4355f869ecc94 This filter was initially added to odoo for performance reasons [1] and was removed since the shopfloor performance do not require it anymore to work properly. However, this filters appeard to be usefull for certain user in case for instance they want to filters out all the MO's that do not have an operation which belongs to at least one of the selected workcenter. In addition, this filter is reactive and quite hard to manually create since it requires that the user identifies the ids of its active workcenters. It was therefore decided to add it back to the list of filters that can be selected in the shopfloor in case the user would like to use it. [1] https://github.com/odoo/enterprise/pull/64551 opw-4241699 Forward-Port-Of: odoo/enterprise#72103
The studio onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour. Forward-Port-Of: odoo/enterprise#71623
Original PR description
The studio onboarding tour was missing because it was in the tests assets. It has been moved and change for the new system of onboarding tour. Forward-Port-Of: odoo/enterprise#71623
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Add a new bridge module for timesheeted product with recurring invoice. This module overwrite the computation of delivered quantity for recurring line invoiced on delivered timesheet to only account for those delivered during the invoice deferred period. + several fixes task-id: 4221354 Forward-Port-Of: odoo/enterprise#71546
Original PR description
Add a new bridge module for timesheeted product with recurring invoice. This module overwrite the computation of delivered quantity for recurring line invoiced on delivered timesheet to only account for those delivered during the invoice deferred period. + several fixes task-id: 4221354 Forward-Port-Of: odoo/enterprise#71546
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterpri
Original PR description
When doing a groupby on a non-relational field (e.g. a char), if the field contains NULL values in DB, they appear as `None` in the keys of the `group_lines_by_keys` dict. If the comparison operator is not implemented between the field type and `NoneType`, `sorted` will fail with a traceback. Solution: sort on keys `(k is None, k)`. if k is None, then `k is None = True`. Because `True > False`, these values are pushed to the end by the sorting. task-none Forward-Port-Of: odoo/enterprise#72160 Forward-Port-Of: odoo/enterprise#72008
Fixed incorrect error messages that were previously displayed. task-4193991 Forward-Port-Of: odoo/enterprise#70619
Original PR description
Fixed incorrect error messages that were previously displayed. task-4193991 Forward-Port-Of: odoo/enterprise#70619
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the ma
Original PR description
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the main company those taxes are not found and will be created again but we have a constraint that tax name must be unique opw-3962212 Forward-Port-Of: odoo/enterprise#72130
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
Original PR description
When a MO consumes components that have a MPS record, the MPS does not take the consumption moves into account for the starting quantity of the MPS record. This PR removes that condition to make sure the starting inventory is correctly computed. Forward-Port-Of: odoo/enterprise#69412
Forward-Port-Of: odoo/enterprise#71381
Original PR description
Forward-Port-Of: odoo/enterprise#71381
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768
Original PR description
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768
23 changes
Resolved issues and error corrections
Changing visible rows in the Master Production Schedule no longer resets the page filter. This keeps users in the expected schedule view, such as the products linked to a specific bill of materials, avoiding confusion and extra navigation.
Original PR description
Steps:
- create 2 boms:
-- bom_A: product_A with component_A
-- bom_B: product_B with component_B
- add all 4 products to the MPS
- go to bom_A and click on the 'Schedules' smart button, there should
only be 2 records (product_A & component_A)
- open the search dropdown menu and select a 'Rows' option
Issue:
When changing the rows to be shown in the MPS (e.g. Actual Demand),
OWL calls `write` directly via the orm on res.company because those
fields are set on res.company. This is due to 'company_service.js':
```js
if (!error && model === "res.company" && UPDATE_METHODS.includes(method)) {
if (!browser.localStorage.getItem("running_tour")) {
action.doAction("reload_context");
}
}
```
This cause the page to do a full refresh, which loses the domain.
Fix:
This fix makes it so that when changing the rows in the search menu,
OWL calls a specific function that will do the same job but without
the full reload, thus keeping the domain.Administrators can now access all quote calculator spreadsheet templates from the technical settings. This makes it easier to clean up unused templates or import templates from JSON files without cluttering the Sales app menus.
Original PR description
Currently, there's no menu to get a list of all quote calculator spreadsheet templates. This commits adds a menu in the technical settings. It allows to: - delete/clean unused spreadsheet templates - import a template from its json file (BA do that quite often for dashboards, I expect they'll want to do it for spreadsheet quotation templates) Feedback from OXP Note: we don't add the menu in the Sales app menus because we don't want to add noise in there. It must be kept clean. Task: 4236559
The product form no longer shows an empty Accounting page to users who do not have the relevant accounting read-only access. This removes confusion for sales users by only displaying the page when meaningful accounting information can be shown.
Original PR description
Steps: - Install sale app. - Go to sale module. - Open product form. - Go to accounting page. Issue: - Empty accounting page. Cause: - In account_accountant module added invoice group to display accounting page even though there is no content added in that module to display which should be visible without have account readonly access. Fix: - Remove invoice group for stable to display that page only for readonly group. To-do master: Remove that view. opw-4209850
This fixes Mexican electronic invoicing calculations so local taxes, withholdings, refunds, and rounding are handled more accurately. Global invoices are now calculated as a single invoice and block unsupported mixed-currency cases, reducing the risk of incorrect tax reporting or rejected documents.
Original PR description
- We used the wrong variable to compute the total of withholding taxes. - The subtotal must not include the local amounts. - According to the SAT, the local vat amounts/rate must be rounded to 2…
- We used the wrong variable to compute the total of withholding taxes. - The subtotal must not include the local amounts. - According to the SAT, the local vat amounts/rate must be rounded to 2 decimals. - Make the GI be computed as a big invoice instead of being an aggregator of CFDI This is more accurate regarding the purpose of the global invoice. Also, it allows to manage the local taxes on it without copy pasting the whole code in both the invoice itself and the aggregator for the global invoice. That way, we also fix a rounding issue when '_round_base_line_tax_details' is called on each invoice separately and not on the whole global invoice. By design, this case is fixed by this commit. - No multi-currency allowed in the global invoice Currently, the GI allows mixing multiple invoice having foreign currencies but we take the first encountered currency as reference. In this case, the whole GI is wrong. Also, it's not well defined how the global invoice is supposed to work in the global invoice and how the rate should be handled in that case. For those reasons, we prevent the user from creating a global invoice if any of the aggregated invoice has a foreign currency. - Improve the dispatching of negative lines. The scope of each aggregated document in the global invoice is well defined now. Each document tries to dispatch its negative lines on the current document first. Then, each refund tries to dispatch its remaining negative lines with the target document refunded by the refund. This way, we no longer needs to define prior documents when dispatching the negative lines. Before this commit, if you fail to dispatch the negative lines on the "prior document" being the refunded document, it should fail. - Fix the dispatching of negative lines when using round globally. The method '_round_base_lines_tax_details' must be called after the dispatching of negative lines. Suppose a line has a delta due to round globally with price included taxes. Then this line is refunded completely by a line without a delta. The current delta is lost and probably should go to another line. task-id: 4261885
Users can now confirm multiple assets at once even when those assets use different journals. This prevents an error during depreciation confirmation and helps accounting teams process assets in bulk reliably.
Original PR description
Reproduce: * create an asset * duplicate it, and change the journal * in list view, compute the depreciation * in list view, confirm Traceback because we try to get the lock date related to multiple journals.
Documents added from a bill of materials line now remain visible instead of briefly appearing and disappearing. This ensures teams using manufacturing and PLM can reliably attach and view documents where they expect them.
Original PR description
Since [odoo/pull/176483](https://github.com/odoo/odoo/pull/176483), the product_document_kanban_controller methods have been modified but in MRP. This commit fixes it. Before ------ When clicking on the document icon of a bom line, and then adding a document, the document whill shortly appear and then disappear because the visibility is not set on bom https://drive.google.com/file/d/1gXiqtU3zEoFP76ue2pk-0FHnf5MyRT-P/view The same logic applies to PLM After ----- The document visibility is set on 'bom' and the document is visible when added
Opening a point-of-sale session no longer fails when UrbanPiper API credentials have not been entered. This prevents unnecessary blocking for users who do not need or have not yet configured the UrbanPiper integration.
Original PR description
Before this commit: === - When attempting to open a session, when there is no API key and username in pos_config, a validation error occurred. After this commit: === - No validation error occurs when the API key and username are missing in pos_config. task-4266405
Signature request emails now use one selected language consistently across both the email layout and message content. This prevents recipients from seeing mixed-language emails and improves the professionalism of translated communications.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
Signature request emails now use the selected recipient language consistently across both the email layout and message content. This prevents mixed-language emails and improves the experience for customers receiving documents to sign.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translations issues.
This fix prevents an error when generating Indian payroll payment reports by correctly processing multiple report entries. It improves reliability for payroll teams without changing the report’s intended behavior.
Original PR description
The issue occurred because `vals_list` is a list of dictionaries, and calling `get()` on it caused an AttributeError. Updated the logic to iterate over the list and properly handle each dictionary entry.
Signing-related emails now use the requested recipient language consistently across both the email layout and message content. This prevents mixed-language emails and provides a clearer experience for customers receiving documents to sign.
Original PR description
Before this commit, the language of the logged in user and the language given in kwargs would be used to translate the content. The email layout would translate to the user language and the body content would use the kwarg's language. This lead to translation discrepancies. After this commit, only the language given in the kwargs is used and therefore fixing the translation issues.
This fixes an issue where saving a document folder without a name could display an incorrect placeholder value. Users will now be prompted to enter a valid folder name before saving, improving clarity and data quality.
Original PR description
When we save the folder without a name, it shows 'False' because the field isn't set as 'required.' Making it mandatory will trigger a red alert on save, ensuring a valid name is entered. Task-4247496
Opening the backend appointment calendar from Point of Sale could fail because the system tried to read information that was not available. This fix adds a safeguard so users can open the view without encountering an error.
Original PR description
Issue: ========== - Modify the point of sale module manifest file as per the reference PR. Then, you get an error on runbot for accessing the tag value from null (check referenced PR runbot). Cause: ========== - When trying to open the backend appointment view in the point of sale, the current controller was not found. Consequently, the `_getCurrentAction()` method returns a null value, leading to an error when trying to access the tag value from null. FIX: ========== - We need to add a condition to avoid accessing a value from null. Related PR: Community: https://github.com/odoo/odoo/pull/181828 Enterprise: https://github.com/odoo/enterprise/pull/70891
Miscellaneous changes
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time wit
Original PR description
**Steps to reproduce:** - Create a working calendar 8:00 - 12:00 13:00 - 15:00 - Set in employee and company, as you mentioned everywhere. - The create a shift template 11 :00 - 15:00 (3 hrs) - Now create a planning slot with this shift template. - Expected start date - End date 11:00 - 15:00 - Actual start - end 11:00 - 14:00 **Current behavior before PR:** The end time is not calculated correctly if we have working calendar because we just add the duration to the start time without taking into consideration that there might be a break hour in the middle of the duration. **Desired behavior after PR is merged:** We are now considering the employee resource calendar in our calculation for the time of the slot. opw-3890629 Forward-Port-Of: odoo/enterprise#72145 Forward-Port-Of: odoo/enterprise#63002
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Original PR description
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'sav
Original PR description
A previous [commit](https://github.com/odoo/enterprise/pull/63926/commits/c749e1358dbd0175d0de5f32eab2c4dd98053905) added a readonly condition on the field auto_sync of the account.online.link view. This was made to prevent the automatic fetching of transaction from interactive providers when the connexion had expired. The issue lies in that condition being based on the field it applies to. This does not work well with manual editing as the readonly condition would update before hitting 'save', preventing to save the changes when unticking the 'auto_sync' checkbox. After discussion with FLG, we decided to keep things simple and remove that condition altogether. Else, one would have had to create a new field and import new data from the institution (is_interactive). No opw but the issue was raised in a odoofin support discord thread. Forward-Port-Of: odoo/enterprise#71643
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration
Original PR description
Set up Avatax environment Create an Invoice with 2 lines: - Prod A, Analytic Account A - Prod B, Analytic Account B Compute taxes Now open one of the newly added taxes On the repartition line click on the 3 dots menu, show 'Tax Closing Entry' Disable 'Tax Closing Entry' on the invoice repartition line Now go back to the invoice Compute taxes again Issue: Traceback will raise 'ValueError: Expected singleton: account.move.line(...' This occurs because, with this tax configuration, on the move we will have 2 tax lines for the same tax, as the lines needs a different analytic account and cannot be grouped together. When we compare the amount per tax we'll have a recordset and it will raise an error. A solution is to acknowledge that we might have more than 1 line and split the possible difference evenly on the tax lines opw-3976597 Forward-Port-Of: odoo/enterprise#69090
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All
Original PR description
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always…
There are currently these issues in the bank reconcilation report 1. There may be a traceback due to a division by 0 error 2. The residual amounts are not correctly computed in the report. It always displays the full amount; even if the move is partly "reconciled" already. 3. Duplicate entries can appear. All issues are solved by rewriting the generation logic a bit. Issue (1) i.e. happens due to move lines with a 0 balance in the move associated with the bank statement (line). All 3 issues can happen due to the way the entries in the report are generated: Consider a single bank statement (line) / its associated "bank move". To generate the line the report we join the bank statement line and bank move to each line of the bank move (except the liquidity line). The report groups by move line id. This generates 1 row in the report per move line (except the liquidity line) of the bank move. This directly causes issue (3). It also causes issue (2) due to the following: The reason we join all the move lines in the first place is to compute the unreconciled amount of the bank move. (By summing amounts on the move lines). But when generating a single row of the report we only have the information about 1 line (due to the grouping by id) and not the whole sum. Thus we do not have the full residual information. opw-4178134 (Issue 1) community PR: https://github.com/odoo/odoo/pull/182589 Forward-Port-Of: odoo/enterprise#72146 Forward-Port-Of: odoo/enterprise#71243
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
Original PR description
Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the ma
Original PR description
Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the main company those taxes are not found and will be created again but we have a constraint that tax name must be unique opw-3962212 Forward-Port-Of: odoo/enterprise#72130
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
Original PR description
The definition of these records include the field `requires_allocation`, so updating them will trigger the constraint for that field. There's already a [fix for this](https://github.com/odoo/odoo/pull/182533) but it will be interesting to still mark these records as noupdate to be coherent with all the other `hr.leave.type` records. To reproduce: - Install `l10n_hk_hr_payroll` with demo data - Upgrade the module Forward-Port-Of: odoo/enterprise#71844
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Original PR description
With this commit, the user will not have to wait for the acknowledge message coming through the websocket to process it, it will be processed directly after the message is sent, if the message is accepted server-side. With this commit, we are now robust to the case the websocket connection is dropped **and** the user is alone in the spreadsheet. Task: 4243943 Forward-Port-Of: odoo/enterprise#72187 Forward-Port-Of: odoo/enterprise#71782
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768
Original PR description
Turn off 'Show Timezone' and 'Show Duration' by default in 'Table' demo data. Task-4247801 Forward-Port-Of: odoo/enterprise#71768
10 changes
Enhancements to existing features
This update adds a new XLSX export option for Colombian companies that provides a detailed trial balance report broken down by both accounts and business partners. Previously, the trial balance only grouped data by accounts. This enhancement makes it easier for Colombian businesses to analyze their financial data with partner-level detail, improving financial reporting and analysis capabilities.
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#70110
Resolved issues and error corrections
Fixed a bug in Morocco's balance sheet reporting where profit/loss amounts were being counted multiple times, causing the balance sheet to be unbalanced. The issue occurred when transferring previous year results to the appropriate accounts at the start of the fiscal year. The fix ensures that only result affectation entries are considered, not current year income and expenses, resulting in accurate financial reporting.
Original PR description
In Morocco, the result can be affected from accounts 1181 and 1189, depending whether it's a profit or loss. To that effect, an entry must be passed at the beginning of the fiscal year to empty 9999 (unaffacted earnings) account, and put the result of the previous year to one of those accounts. When trying to do that, the same amounts were taken multiple times into account, leading to an unbalanced balance sheet. The problem was the income/expense lines from the current year musn't be considered by that line of the BS. Only affectation must also be considered from within the current fiscal year.
This fix prevents the customer display feature from unexpectedly closing its connection when opened. The issue was causing the display to disconnect, similar to a previously reported problem with the self-order feature. This ensures the customer display remains reliably connected during point-of-sale operations.
Original PR description
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060
This fix resolves an issue where components manually added to a manufacturing operation on the shopfloor were not visible to users, even though they were correctly added to the system. The problem occurred because newly added components were not being marked with the correct visibility flag. Now when operators add components directly from the shopfloor interface, those components will properly display in the work order.
Original PR description
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component -…
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = True` see: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L188-L191 However, when a product is added via the `action_add_component` > `add_product`, the `manual_consumption` of the move is computed as if it was added to the MO without being linked to a `bom_line_id`: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/wizard/additional_product.py#L36-L46 https://github.com/odoo/odoo/blob/2d652f42f63c2501b1a9feb7a4830ea3d7d05f51/addons/mrp/models/mrp_production.py#L1198 As a result the move_raw is added as a manual_consumption = False. ### Note: Thank to Commit eb751b5f861b25205dbb0b0fb90ddcdbbcd10f55 , the issue is not reproducible in 18.0 anymore. This was soved in the same manner: https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L36-L38 https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L107-L114 opw-4199156
This fix ensures that analytic distributions are correctly applied to depreciation entries when computing asset depreciation. Previously, the system was not propagating the analytic distribution model settings to the depreciation journal entries, which could lead to incomplete cost tracking and reporting for assets in companies using analytic accounting.
Original PR description
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Regular users with access to the IoT app were unable to pair IoT boxes due to permission errors. This fix adds the necessary access permissions so that regular users can now successfully pair IoT boxes without encountering errors.
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
This fix resolves an issue in Web Studio where adding a field to one section and removing another section in a form were being incorrectly combined into a single operation. Now these actions are properly handled as separate, independent operations, allowing users to make multiple edits to form layouts without unexpected results.
Original PR description
…ifferent trees
Add a field at the end of the "left" subgroup and remove the "right" subgroup.
```xml
<form>
<group>
<group>
<field name="display_name" />
[ADD A FIELD]
</group>
[ REMOVE THIS GROUP
<group>
</group>
]
</group>
</form>
```
Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml
<xpath expr="[..]/group[2]" position="replace">
<field name="added_field" />
</xpath>
```
After this commit, this flow works and the two operations are independent.
part of task-4207793
Forward-Port-Of: odoo/enterprise#71289This fix restores the missing confirmation dialog that should appear when users delete appointment bookings from the Gantt calendar view. Previously, users could accidentally delete bookings without any warning prompt. Now the system properly asks for confirmation before removing any appointment records.
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681
This fix resolves a critical error that prevented users from accessing Accounting Settings when using Spanish (Latin America) as their language preference in Argentina. The bug caused the settings page to crash with an error message. This fix restores functionality for Argentine companies using the localization module.
Original PR description
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on…
There is a bug with traceback while going to "Accounting / Configuration / Settings" with "Spanish (Latin America)" language selected on user config (install l10n_ar_edi module and take position on company "(AR) Responsable Inscripto"). This pr fixes it. The bug was introduced on this pr https://github.com/odoo/enterprise/pull/71027 .
Bug with traceback:
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:916:101)
at App.handleError (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1548:29)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:941:19)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Caused by: EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
EvalError: Can not parse python expression: (bool(“l10n_ar_afip_ws_crt”))
Error: Invalid expression
at evaluateExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3050:128)
at SettingsFormRenderer.evaluateBooleanExpr (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:3054:8)
at SettingsFormRenderer.slot533 (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:9209:26)
at callSlot (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1108:25)
at SearchableSetting.template (eval at compile (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1502:374), <anonymous>:56:13)
at Fiber._render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:940:96)
at Fiber.render (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:939:6)
at ComponentNode.initiateRender (https://69506271-17-0-all.runbot176.odoo.com/web/assets/fc8bbf7/web.assets_web.min.js:1007:47)
Ticket Adhoc side: 81698
Task latam side: 1279This update corrects the private transport reimbursement calculations in the Belgian payroll system. The changes ensure that employee reimbursements for using personal vehicles for work purposes are calculated accurately according to current Belgian regulations and company policies.