Wednesday, August 13, 2025
25 changes · saas-18.3
Enhancements to existing features
Company enrichment now sends a standard industry code instead of an internal database ID. This prevents errors when a customer has changed their local industry list and helps match Dun & Bradstreet data more reliably.
Original PR description
Ticket #4992568 highlighted a weird way of sending the industry from IAP to the Odoo client. Before this commit, we were sending the IAP psql id of the industry to the client. There, it would be use as is. It works because these industries haven't been changed in years and they're created in the same order. However the ticket highlighted the fact that a user can edit/delete/create its own industries, therefore some ids that exist on IAP might not exist on the client's Odoo instance. This resulted in a traceback on the client's side. With this commit, we now send the industry code (the ISIC: International Standard Industrial Classification) instead to the client. There it can correctly be mapped if it exists on the client's DB (e.g. not deleted) opw-4992568 https://github.com/odoo/iap-apps/pull/1152 Forward-Port-Of: odoo/odoo#222486
Users can now update only part of an analytic distribution when editing multiple journal items or analytic items at once. This makes bulk accounting updates more practical by avoiding the need to replace the full distribution for every selected record.
Original PR description
In Journal Items list view, mass edition of the Analytic Distribution on several records is disappointing and reported almost unusable. It is impossible to mass edit only one plan on multiple lines using a distribution. This commit is adding the possibility to do so from the list view of analytic items but also from the journal items. task-4937143 Forward-Port-Of: odoo/odoo#222728 Forward-Port-Of: odoo/odoo#219582
The UAE payroll end of service report now calculates worked years using the employee’s full time with the company, rather than only actual worked days. This improves accuracy for end of service reporting and helps businesses reflect total service duration consistently.
Original PR description
- update the calculation for the worked years in the end of service report to return the whole duration worked with the comapny not just the actual worked days. Task: 4703337 Forward-Port-Of: odoo/enterprise#92234 Forward-Port-Of: odoo/enterprise#84223
Resolved issues and error corrections
This fix prevents the Marketing Card module from blocking clean uninstallation when its database fields have already been removed. It helps avoid leftover database data and reinstall errors for Marketing Card and related modules.
Original PR description
Because it overrides the unlink of `IrModel` odoo/odoo#214315 breaks a ton of model uninstall/reinstall (basically all its dependencies, direct or transitive): when `marketing_card` is marked for…
Because it overrides the unlink of `IrModel` odoo/odoo#214315 breaks a ton of model uninstall/reinstall (basically all its dependencies, direct or transitive): when `marketing_card` is marked for uninstallation, all its fields get removed first (because that's how `_module_data_uninstall` does things), so all the non-magic columns are dropped. Then, when trying to `unlink` the `ir.model` records the `unlink` call fails with some sort of "column does not exist" error (on `active` or `res_model`), the unlink fails, which leads the tables to not be removed, leaving a ton of garbage in the database. This in turns means trying to reinstall the module also fails, as many tables will have a few records left for one reason or another before they are dropped, so new columns which are `required` without a `default` fail to set up their constraint, which logs both errors and warnings on reinstall. None of this is necessary, if `marketing_card` is being uninstalled we can just ignore the entire issue as the table should be dropped eventually, even if it worked it would be a waste of time. https://runbot.odoo.com/odoo/error/230837 Forward-Port-Of: odoo/odoo#222789
Restoring an earlier task description from history now keeps the information needed for later saves. This prevents users from seeing an incorrect history-related error after applying a previous version and editing the task again.
Original PR description
Problem: When applying a specific version from history in `task.description`, then updating and saving it, an error appears stating the content was saved from a different history model. Cause: When inserting versioned content, the required `data-last-history-steps` attribute is not included. Solution: Ensure the latest `data-last-history-steps` is added when restoring a version. Steps to reproduce: - Open Project > any task - Change the description - Save - Open version history and apply any version - Update the description - Save - Error appears opw-4829553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216370
Activity list filters now focus on the current user's own activity deadlines instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity views match what users expect from the activity counter and reduces confusing search results.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "future activities" for example will show you all records with *any* future activity so long as the next one is yours. Even if yours is actually late. The mistake seems to be that "my activities" + "next date deadline < X" is equivalent to "my next date deadline < X". But this is not the case as just because the most late activity is not yours does not mean you do not have any late activity. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. As such the filters are reverted to their previous expression. And the "my activities" filter is not selected by default. [1]: 5c5fbc10b7024c7227f03e37897d421bba64df82 task-4988330
This fixes an error that could block invoice printing when online payment QR codes were enabled. Sales-created invoices can now be printed normally with the QR payment link included, avoiding disruption in the invoicing workflow.
Original PR description
### Issue When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error. The report printing process internally calls…
### Issue
When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error.
The report printing process internally calls
`_generate_portal_payment_qr`, which creates a `payment.link.wizard` record. This model overrides `default_get` and reads `self.env.context.get('active_model')`.
At that moment, the context still contains `'sale.advance.payment.inv'`, a model that does not implement `_get_default_payment_link_values`. This causes:
AttributeError: 'sale.advance.payment.inv' object has no attribute '_get_default_payment_link_values'
#### Affected versions
- saas-18.3 and later
### Steps to reproduce
1. Install `account_accountant`, `sale_management`
2. Go to Settings
3. Enable "Invoice Online Payment" and "Add QR-code link on PDF"
4. Go to Sales → Quotations
5. Create any quotation
6. Confirm quotation
7. Create invoice (full)
8. Confirm invoice
9. Click "Print"
#### Current behavior
- Error is raised
#### Expected behavior
- Invoice prints with QR code without error
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUnbuilding a manufacturing order now restores component stock with the correct ownership information. This prevents consigned materials from being incorrectly converted into company-owned stock, improving inventory accuracy for manufacturing and consignment workflows.
Original PR description
**Problem:** when a MO is unbuild, if some components where consigned, they will come back in stock as not consigned **Steps to reproduce:** - enable "consignemnet" setting - create a storable…
**Problem:** when a MO is unbuild, if some components where consigned, they will come back in stock as not consigned **Steps to reproduce:** - enable "consignemnet" setting - create a storable product (the comp) - set on on hand quantity of 3 without owner - set on on hand quantity of 4 with an owner - create another product (the final product), with a BOM of 7 of the comp product - create a manufacturing order for the final product, confirm and produce all. - unbuild it - open the comp product form, click on the on hand smart button **Current behavior:** - there is a quantity of 7 unconsigned **Expected behavior:** - there should be a quantity of 3 unconsigned and a quantity of 4 consigned **Cause of the issue:** when the stock move line is create in action_unbuild() there is no mechanism to get back the owner of the original stock move line from the MO https://github.com/odoo/odoo/blob/ceccb92af19a6a3fc0c7b5924d9f497b1aec1d55/addons/mrp/models/mrp_unbuild.py#L204 opw-4900386 Forward-Port-Of: odoo/odoo#222491 Forward-Port-Of: odoo/odoo#219905
Internal users without administrator rights can now send Spanish Facturae invoices without seeing an access error. The fix lets the system safely check the company certificate needed for sending, reducing blocked invoice workflows for affected users.
Original PR description
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate…
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate records , resulting in an “Access Error” popup. This changes Wrap the certificate lookup in company.sudo(). It's handled the same in https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L140 https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L770 install l10n_es_edi_facturae Go to Contacts and create an new contact with Spain as country in the same page (creating contact page) click on Accounting scroll down and set eInvoice format as facturaE Go to Accountant and create an invoice with that client pay the invoice log out and log in with a user with no administration (e.g. Marc demo) try to send the create invoice OPW:4989007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222207
This fix prevents an error when users from one company browse an e-commerce website belonging to another company. It ensures the website can retrieve the correct company currency even when the browsing user does not have direct access to that company, improving reliability for multi-company setups.
Original PR description
A multi-company issue can occur when a user from another company tries to access products belonging to a different company. Steps to reproduce: 1. Create a e-commerce website without a pricelist on company A 2. Create a user assigned with only access to company B 3. Connect with this user and try to access the products on the website of company A An error will be raised because the user does not have access to company A. opw-4983506 Forward-Port-Of: odoo/odoo#222656 Forward-Port-Of: odoo/odoo#222457
PDF reports covering multiple records now fall back to generating each document separately when the usual automatic splitting cannot be trusted. This prevents missing or incorrect PDFs for users, with a possible slowdown for large report batches.
Original PR description
When generating PDF reports with multiple records, the system tries to split the concatenated PDF using outlines. However, in cases where the number of outlines doesn't match the number of records or…
When generating PDF reports with multiple records, the system tries to split the concatenated PDF using outlines. However, in cases where the number of outlines doesn't match the number of records or outlines are missing, it falls back to generating individual PDFs per record by recursively calling `_render_qweb_pdf_prepare_streams()` for each `res_id`.
This ensures that each record gets its corresponding PDF even if splitting the combined PDF is not possible due to template or wkhtmltopdf inconsistencies.
issue related: https://github.com/odoo/odoo/issues/202299
Current Behavior:
The _render_qweb_pdf_prepare_streams method does not correctly generate PDF streams under specific conditions, causing the PDF to not be properly split for each res_id. When these conditions are met, the generated streams are set to None, resulting in incorrect PDF processing.
The issue occurs when all the following conditions are true:
reader.numPages != len(res_ids_wo_stream)
len(res_ids_wo_stream) > 1 and set(res_ids_wo_stream) == set(html_ids_wo_none) is True
not has_valid_outlines is False
has_same_number_of_outlines and has_top_level_heading is False, since has_same_number_of_outlines is False
Expected Behavior:
The method should correctly assign a valid PDF stream to each res_id, ensuring proper document splitting even when outlines cannot be used.
Steps to Reproduce:
Generate a PDF report where the number of pages does not match the number of res_ids.
Ensure that the report includes multiple records, and the outlines structure is not valid for splitting.
Debug and Observe that the streams assigned to res_ids are None, leading to issues in PDF rendering.
Error:
Odoo Server Error
RPC_ERROR
Odoo Server Error
Occured on 172.20.18.5:8069 on model ir.cron and id 31 on 2025-03-18 12:02:43 GMT
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/tools/safe_eval.py", line 397, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(309,)", line 1, in
File "/home/odoo/src/odoo/addons/account/models/account_move.py", line 5481, in _cron_account_move_send
self.env['account.move.send']._generate_and_send_invoices(
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 687, in _generate_and_send_invoices
self._generate_invoice_documents(moves_data, allow_fallback_pdf=allow_fallback_pdf)
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 612, in _generate_invoice_documents
self._prepare_invoice_pdf_report(batch)
File "/home/odoo/src/odoo/addons/account/models/account_move_send.py", line 333, in _prepare_invoice_pdf_report
content_by_id = self.env['ir.actions.report']._get_splitted_report(pdf_report.report_name, content, report_type)
File "/home/odoo/src/odoo/addons/account/models/ir_actions_report.py", line 60, in _get_splitted_report
pdf_dict = {res_id: stream['stream'].getvalue() for res_id, stream in content.items()}
File "/home/odoo/src/odoo/addons/account/models/ir_actions_report.py", line 60, in
pdf_dict = {res_id: stream['stream'].getvalue() for res_id, stream in content.items()}
AttributeError: 'NoneType' object has no attribute 'getvalue'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/http.py", line 1962, in _transactioning
return service_model.retrying(func, env=self.env)
File "/home/odoo/src/odoo/odoo/service/model.py", line 156, in retrying
result = func()
File "/home/odoo/src/odoo/odoo/http.py", line 1929, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/odoo/http.py", line 2177, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_http.py", line 333, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/odoo/http.py", line 727, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/addons/web/controllers/dataset.py", line 42, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/odoo/api.py", line 533, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_cron.py", line 120, in method_direct_trigger
self.ir_actions_server_id.run()
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_actions.py", line 995, in run
res = runner(run_self, eval_context=eval_context)
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_actions.py", line 827, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "/home/odoo/src/odoo/odoo/tools/safe_eval.py", line 411, in safe_eval
raise ValueError('%r while evaluating\n%r' % (e, expr))
ValueError: AttributeError("'NoneType' object has no attribute 'getvalue'") while evaluating
'model._cron_account_move_send(job_count=20)'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://172.20.18.5:8069/web/assets/0604b65/web.assets_web.min.js:3140:163)
at XMLHttpRequest. (http://172.20.18.5:8069/web/assets/0604b65/web.assets_web.min.js:3145:13)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#213900This fix prevents Odoo from crashing when a user opens an app while multiple modules are still being installed. It makes the web interface handle partially loaded view information safely, improving reliability during installation workflows.
Original PR description
Currently, an error occurs when the user tries to install multiple modules and, during installation user tries to access any app. This issue happens because line [1] tries to get view info by view…
Currently, an error occurs when the user tries to install multiple modules and, during installation user tries to access any app. This issue happens because line [1] tries to get view info by view name, like `hierarchy`. Normally, we get the view information from the `_get_view_info` method (see [2]), and we override this method to add another view to the returned data (as in [3]). But during installation, when the user tries to access any app, the view is already loaded into the database. So when the `fields_get` method is called, the view is found. However, since the module isn't fully loaded yet, the overridden `get_view_info` method hasn't taken effect. As a result, the additional view we expect isn’t included, and accessing that view key causes an error. This commit fixes the above error by ensuring that `_view_info` is accessed only when `type_` is present in `_view_info` at [1]. [1]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web/models/ir_ui_view.py#L14 [2]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web/models/ir_ui_view.py#L22-L31 [3]: https://github.com/odoo/odoo/blob/80976e3579db4862c16cafab2ec183a7a0d0b63c/addons/web_hierarchy/models/ir_ui_view.py#L56-L57 sentry-5661154820 Forward-Port-Of: odoo/odoo#221847
Saudi e-invoicing QR codes now use the actual amount due on each invoice instead of the total sale order amount. This prevents ZATCA warnings on regular invoices following down payments and helps invoices be accepted cleanly.
Original PR description
#### Step to reproduce: - In a company in Saudi Arabia - Create a sale order to a customer (B2C) - Create an invoice as a downpayment and confirm it - Process the ZATCA invoice if needed (blue banner at the top) - Create an invoice as a regular payment and confirm it - Process the ZATCA invoice if needed (blue banner at the top) #### Current behavior: - ZATCA return a 200 code for the downpayment invoice. - ZATCA return a 202 code with a Warning for the regular payment invoice. The warning states that the invoice was accepted however it needs the Tag 4 of the QR code to be Amount due payment (BT-115) #### Expected behavior - ZATCA return a 200 code on both invoices. opw-4848578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#219464
Employees assigned to recurring tasks in private projects can now mark those tasks as done without seeing an access error. This ensures private project permissions are respected while allowing normal task completion workflows to continue.
Original PR description
to reproduce: ============= - create a private project and a recurrent task in it - assign the task to an employee - log in as the employee - mark the task as done - the task should be closed but it is not and the employee gets an error Problem: ======== while changing the state of a recurrent task, we need to read the project which is not allowed for this employee since the project is private. Solution: ======== we need to use sudo() to read the project in this case. opw-5012231 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Editing quantities on receipts for products valued by lot now avoids an unexpected system traceback. Users get the intended handling or a clear error when lot information is missing, helping warehouse and purchasing teams correct the issue without disruption.
Original PR description
Steps to reproduce: 1) Create a product tracked by lot and with valuation by lot. 2) Create a Purchase Order with this product and Confirm it. 3) Go to Receipt 4) Add a Lot number and validate 3) Unlock the receipt and modify the `quantity`. Current behavior - Get a traceback. Expected behavior: - If there is only one lot: - update the lot quantity - Else : - raise an error The fix should be applied before the `web_save` call to prevent the creation of a new `stock.move.line`. Therefore it's done on the `onchange` call. opw-4841162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221620 Forward-Port-Of: odoo/odoo#213534
Calendar reminders are now limited to upcoming events within the correct reminder window. This prevents users from receiving outdated notifications for recurring meetings that already happened, reducing confusion and improving reminder reliability.
Original PR description
Steps to reproduce the issue: 1. Create a calendar event (meeting, for example) 2. Set the start date as yesterday and in 30 minutes from now. 3. Set it to be recurrent every week with end_type set…
Steps to reproduce the issue: 1. Create a calendar event (meeting, for example) 2. Set the start date as yesterday and in 30 minutes from now. 3. Set it to be recurrent every week with end_type set to end_date and in the future(1 month from now). 4. Add a reminder to the event (30 mins, for example) and ensure that calendar_last_notif_ack is set before the alarm window for your user's res.partner. 5. Save the event and observe an alarm notification made for an event in the past. After the fix, the calendar alarms will only trigger for events in the future and in their designated time windows. The recurrence logic was also removed from the query to align with this [[REF]](https://github.com/odoo/odoo/pull/42031/commits/a27afdb5434166c3ea48c18ccfba9e8245d18e62) since recurring events are all persistent records in the database. opw-4776638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222610 Forward-Port-Of: odoo/odoo#222214
Physical Inventory no longer shows a duplicate serial number warning after an item with a unique serial number is moved between locations. This avoids unnecessary confusion for warehouse users and helps keep inventory adjustments focused on real stock issues.
Original PR description
## Issue: ## A warning appears in Physical Inventory when transferring a product with a serial number between two locations ## Cause: ## The `_compute_sn_duplicated()` method incorrectly considered…
## Issue: ## A warning appears in Physical Inventory when transferring a product with a serial number between two locations ## Cause: ## The `_compute_sn_duplicated()` method incorrectly considered `stock.quant` records with quantity 0 That mean that it will considered a duplication even if the quant indicate that the product isn't in that location Additionally, the system parameter `stock.skip_quant_tasks` is enabled on all SaaS environments since version 18.2 It was added for performance issues: (see: https://github.com/odoo/odoo/commit/207ba01819577cf6a2a686fae39dd3d673aec6dd) When enabled, the quant merging and removal of zero quants are skipped when opening a Physical Inventory, causing this issue to appear ## Steps to reproduce: ## - Enable Developer Mode - Create a New System Parameter (Key: stock.skip_quant_tasks, Value: True) - In Settings, enable Storage Locations and Lots & Serial Numbers - Duplicate WH/Stock as WH/Stock (copy) - Create a product tracked by Unique Serial Number - Update its quantity: one at WH/Stock - Process an Internal Transfert from WH/Stock to WH/Stock (copy) - Go in Operations > Adjustments > Physical Inventory opw-4944011 Forward-Port-Of: odoo/odoo#221578
Activity filters now focus on each user's own next activity deadline instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity counts and filtered lists match more reliably across business apps.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "late activities" for example will show you all records with *any* late activity, instead of records where you personally have late activities. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. [1]: ad95d7d42f195527bbaccdf349da8316e9c9df12 task-4988330
This fix ensures the payment widget shows the correct remaining bank statement amounts after partial reconciliation and applies the right currency conversion for multi-currency payments. It also prevents removing unrelated invoice matches when undoing one partial payment, reducing accounting errors and manual corrections.
Original PR description
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the…
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the statement line - Duplicate the invoice and post it => First issue, you don't see the 100$ left on the statement line It's still reconciliable To fix that, we only remove fully reconciled statement lines. Second issue: - Have a bank journal in EUR with a rate of 2 - Make a statement line for 400€ in this journal - Create an invoice for the same partner of 100$ => The widget proposes a statement line of 400$ instead of a 200$ equivalent (with the rate conversion) The issue is that we convert with a foreign_currency_id that is not present in that case. To fix both, we change the way we compute the amount to always use the residual converted from the right currency [FIX] account_accountant: partial on statement line for invoice widget To reproduce: - Make a statement line for partner_a for 200 $ - Make 2 invoice for same partner for 100 $ - Reconcile them with the statement line (via the widget) - Unreconcile first invoice via the payment widget => The second invoice is also unreconciled To solve: Only unreconcile the lines that are part of the partial that we want to unlink
This fixes an error that could block customers from adding a new address during website checkout when the company is configured for Colombia. The checkout form now handles the identification type field correctly in all display modes, improving reliability for Colombian eCommerce flows.
Original PR description
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" →…
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" → Traceback occurs Problem & Solution: =================== The field l10n_latam_identification_type_id is always present in the address form but its HTML element changes: it's rendered as a `select` when is_commercial_address and can_edit_vat is true, and as an `input` otherwise. The JS code only looked for the `select`, so when the `input` was rendered instead, the selector was null and caused a traceback. Update the selector to look for the field in either `select` or `input` form, so the code works regardless of the rendering conditions. useful-links: https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L10-L11 https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L32-L33 opw-4969089
The portal now shows total task hours based only on validated timesheets when that invoicing policy is selected. This keeps the displayed total consistent with the visible timesheet lines and avoids overstating billable or reported work.
Original PR description
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines…
### Steps to reproduce: - Set timesheets inovicing policy to 'Validated Timesheets Only' - From the portal go to any task that has some validated timesheet and some other not - Notice that the lines shown is the validated ones only but the Hours spent includes the non-validated ones too ### Current behavior before PR: The total hours spent for timesheets in portal view when setting the invoicing policy to 'Validate Timesheets Only' is calculated wrongly as it takes the non validated ones into account. This is happening as when passing the values to the view we pass 'task_sudo' variable which will have the SUPERUSER as the env.user https://github.com/odoo/odoo/blob/saas-17.2/addons/project/controllers/portal.py#L569 so it won't pass the condition if the user is portal or not https://github.com/odoo/enterprise/blob/saas-17.2/sale_timesheet_enterprise/models/project_task.py#L33:L35 and it will calculate all the timesheet without taking validation into condisderation. ### Desired behavior after PR is merged: As we are using those computed fields only in portal views so we don't have to check if the user is portal user as even if an internal user is showing the same view for testing he should be able to see the same data as the portal user. opw-4193842 Forward-Port-Of: odoo/enterprise#70557
Fixed an issue in the Spanish SME Balance Sheet where certain group company investment accounts could be counted twice, making reported amounts appear doubled. This improves the accuracy of Spanish financial reporting for affected companies.
Original PR description
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to…
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to multiple balance sheet sections Root Cause: - Account codes 5523% and 5524% were included in BOTH: 1. 12400 (Assets): 'Current investments in group companies' 2. 32400 (Liabilities): 'Group companies current liabilities' - This double-counting caused investment amounts to appear twice in the balance sheet How to Reproduce: 1. with Spain - SMEs Fiscal Localization's Package 2. Go to Accounting -> Configuration -> Journal -> Bank 3. Change suspense account to code 5523X or 5524X (should be added to chart of accounts before) 4. Post journal entries to accounts 55230X or 55240X 5. Generate 'Balance Sheet - SMEs (ES)' report 6. Observe amounts are exactly doubled compared to account balances Fix: - Removed duplicate account codes from balance_pymes_line_12400_sub_balances - These accounts are properly handled by the domain formula in line 32400 - Each account code now appears in only one balance sheet section" opw-4983300
Internal users can now see the Documents app button, making it easier to access shared documents from the main app menu. This also clarifies that users do not need the full Documents User role to access documents shared with all internal users.
Original PR description
The app is accessible to all internal users via smart buttons and their portal already, showing the button is helpful in two ways: 1/ Easier access to the app, duh. 2/ Makes it explicit that you don't need to be a "Documents User" to have access to documents shared with all **internal users**, even those that are not documents user (that didn't have the app button available). In 18.0 so that new installations have it. Task-4889053 Forward-Port-Of: odoo/enterprise#92124 Forward-Port-Of: odoo/enterprise#90937
Belgian Group S payroll exports now use the company selected by the user when multiple companies are active, instead of only the current company. The export also checks that the required Group S company code is set before proceeding, helping prevent incomplete or rejected work entry exports.
Original PR description
before this commit only the current company was taken into account when exporting work entries now another company can be selected if multiple companies are active for the current user In addition to that this commit also add a check for the company's group s code to enforce the user to set it before exporting work entries task-4213675 closes old PR: odoo/enterprise/pull/71521 Forward-Port-Of: odoo/enterprise#89438
Tickets created from timesheets now default to the helpdesk team linked to the selected project. This prevents new tickets from being assigned to the wrong team and limits team choices to teams that support timesheets.
Original PR description
Steps to Reproduce: - 1. Go to Timesheets > My Timesheets, start the timer, and select the project linked to the helpdesk team. 2. In the timer header, quick-create a new ticket via the "Ticket" field dropdown 3. Observe that the default helpdesk team on the new ticket is incorrect. Issue: - - When creating a ticket from the Timesheets module (e.g., via timer header or views), the system selects an incorrect default helpdesk team, leading to misassigned tickets. Cause: - - The core default logic for team_id prioritizes user membership or the first team without considering the selected project's linked helpdesk team. Fix: - - Override `_default_team_id` to set the correct Helpdesk Team based on the selected project. - A domain has been added to the team selection field within the timesheet views to only show teams that have the timesheet feature enabled. task-4885679 Forward-Port-Of: odoo/enterprise#92112 Forward-Port-Of: odoo/enterprise#89503