Thursday, April 11, 2024
51 changes
1 change
Resolved issues and error corrections
This fix prevents the Point of Sale screen from going blank when validating orders using the India localization. It corrects an import issue so cashiers can complete sales normally without disruption.
Original PR description
Prior to this commit, validating an order in the PoS would result in a blank screen. This issue was caused by an incorrect function import. opw-3853411 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
3 changes
New functionality added to Odoo
Ecuador electronic documents can now include an auxiliary code on product records. This helps businesses meet local electronic invoicing requirements and keeps required product identifiers managed directly in Odoo.
Original PR description
- Add a new field to the product template for the auxiliary code required for electronic documents
Enhancements to existing features
Account managers can now see more sales, purchase, subscription, and invoice records linked to the partners they manage, including cases where those partners are listed as referrers. This makes it easier for commission teams to track customer activity and related documents from the right menus without extra navigation barriers.
Original PR description
[IMP] partner_commission: account manager access rights This commit intends to give access to account managers to more records of the partners they manage. It mainly gives a range of new permissions…
[IMP] partner_commission: account manager access rights This commit intends to give access to account managers to more records of the partners they manage. It mainly gives a range of new permissions to the Commission/Own Documents and Commission/All Documents groups as well as changing stat buttons to include records where the partner is set as referrer. Commission Managers have access to sale orders/purchase orders/subscriptions/ invoices with a "referrer" set while Commission Users have access to a range of documents where the `partner_id` field is an account they manage or the `referrer_id` field is an account they manage. At creation, a child partner will be propagated its parent's account manager (= user_id). So an account manager will have access to the children's records as well as long as that field is propagated. The groups also give access to Invoicing and Accounting top menu so that members of the group can easily access account.move records. Task-2842675
The Barcode app now hides reserved serial number lines with no completed quantity by default, reducing clutter during stock operations. Businesses can still enable a new operation-type setting to show those reserved serial numbers when the previous workflow is needed.
Original PR description
Before this PR: =================== - the operation type in the barcode displayed lines even when the quantity done was 0 . - when the setting is on create new only then in barcode, show lines with done=0 - when use existing not checked AND create new not checked, in barcode we have multiple lines . After this PR: ==================== - Introduces a new option in operations type 'show_reserved_sns,' in the sale module with default value False . - This option becomes active only when the 'use_existing_type' is enabled . - When unchecked, it ensures that lines where the quantity done is 0 are hidden , only the selected ones will be added. - When checked, it will work same as before this commit . - when the setting is on create new only then in barcode, never show show lines with done=0 - when use existing not checked AND create new not checked, Then there should be one line in the aggregate with no serial and a +qty . Task ID : 3284600
47 changes
New functionality added to Odoo
This update adds Catalan language translations to the Spanish localization module, allowing users who prefer Catalan to see accounting terms and account names in their language. Previously, Catalan-speaking users would see English account names; now they will see properly translated Catalan names across all accounting templates.
Original PR description
* addons/l10n_es/i18n/ca.po: Add the catalan language translation for the spanish localization. * addons/l10n_es/data/template/account.account-es_assec.csv: Add name@ca field with account names in…
* addons/l10n_es/i18n/ca.po: Add the catalan language translation for the spanish localization. * addons/l10n_es/data/template/account.account-es_assec.csv: Add name@ca field with account names in catalan. * addons/l10n_es/data/template/account.account-es_common.csv: Add name@ca field with account names in catalan. * addons/l10n_es/data/template/account.account-es_full.csv: Add name@ca field with account names in catalan. * addons/l10n_es/data/template/account.account-es_pymes.csv: Add name@ca field with account names in catalan. * addons/l10n_es/data/template/account.group-es_common.csv: Add name@ca field with account names in catalan. Description of the issue/feature this PR addresses: Add the name@ca for catalan translation at the main account plans in the spain l10n_es localization, and the l10n_es/i18n/ca.po file too. Current behavior before PR: The accounts names are in english when user configures her environment to use the catalan language. Desired behavior after PR is merged: The accounts names are in catalan. Previously crashed PR https://github.com/odoo/odoo/pull/160486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
This update enhances Chilean electronic point-of-sale receipts by adding a bidimensional (2D) code and displaying the requirements needed for valid electronic document compliance. This improvement ensures receipts meet Chilean regulatory standards for electronic documents and provides customers with a verifiable digital receipt.
Original PR description
This is a backport of odoo/enterprise#58479 This commit adds the bidimensional code on the receipt, it also adds to the receipt header the requirements for considering the receipt as a valid electronic document. task-id: 3747828 Community PR: odoo/odoo#161342
The German tax number (Steuernummer) validation has been moved from the tax report generation process to the company form, where it now triggers immediately when users enter the information. This ensures data quality at the point of entry rather than later during report generation, preventing invalid data from being saved in the first place.
Original PR description
Steuernummer was being validated at tax report xml generation. The check was moved to the company form view. It should be a constraint raising when trying to set the steuernummer to the company; there is no point in only checking it at XML generation. task-3809218 Forward-Port-Of: odoo/enterprise#60479 Forward-Port-Of: odoo/enterprise#59348
This update improves how Odoo handles shipping methods when databases are copied for testing or staging. Previously, all shipping methods were disabled during this process. Now, only shipping methods that connect to external providers (like real courier services) are disabled, while internal shipping methods based on fixed prices or custom rules remain active. This allows teams to continue testing order fulfillment workflows without losing their standard shipping options.
Original PR description
Only delivery carriers that can communicate with the outside should be deactivated. Every time a database is neutralized, all delivery carriers are deactivated. In staging or test databases this should not be the case, only delivery carriers with an external connection, i.e. delivery carriers with an external provider should be deactivated. Delivery carriers with fixed price or based on rules should not be deactivated with every neutralization. This way Odoo can continue to operate with shipping methods without prejudice to the users in neutralized databases. @moduon @yajo @Shide MT-5612 Description of the issue/feature this PR addresses: Current behavior before PR: Deactivated every delivery carriers. Desired behavior after PR is merged: Deactivated only delivery carriers with external provider. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160443
This update enhances the Point of Sale receipt functionality for Chilean businesses by adding support for bidimensional codes. This improvement aligns with Chilean regulatory requirements for receipts, making the system more compliant with local standards and improving the receipt documentation process.
Original PR description
This is a backport of odoo/odoo#159671 This commit adds the requirements in order to add the bidimensional code on the receipt of the point of sale for the Chilean localization. task-id: 3747828 Enterprise PR: odoo/enterprise#60451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The German tax number (Steuernummer) validation has been moved from the tax report generation stage to the company form, where it now validates immediately when the field is updated. This ensures invalid tax numbers are caught early and prevents errors during report generation. The field is now also visible for multi-VAT company configurations.
Original PR description
Steuernummer was being validated at tax report xml generation. The check was moved to the company form view. Moreover, the field was set visible in the company form view for multivat. It should be a constraint raising when trying to set the steuernummer to the company; there is no point in only checking it at XML generation. task-3809218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161395 Forward-Port-Of: odoo/odoo#159057
Resolved issues and error corrections
This update adds validation checks to YouTube video uploads to prevent common errors before they occur. The system now checks that video titles don't exceed 100 characters and descriptions don't exceed 5000 characters, and prevents forbidden characters (< and >) in both fields. Users will now see clear, specific error messages instead of generic failures, reducing frustration from repeated failed upload attempts.
Original PR description
Before this PR ================== At the time of the upload failure we display the standard error msg, Because of this, the user will try to upload the video again and again and never know the exact reason for the failure. After this PR ================= This commit adds some validation so that we avoid any upload failure from the YouTube side and display a proper error msg. 1). Checks that Title is not more than 100 characters. 2). Check that the Description is not more than 5000 characters. 3). Checks that Title does not contain > or < forbidden character. 4). Checks that the description does not contain > or < forbidden character. These checks are done at the time of the upload video and also at the time of the post. Task-3392167
This fix prevents Google Meet links from being automatically added to appointment calendar events unless Google Meet is explicitly selected in the configuration. Previously, meeting links were being generated even when not requested, which could confuse users. Now, video conference links are only added when the user has specifically chosen to enable Google Meet for their appointment type.
Original PR description
Steps to reproduce ==================== 1. Install Appointment and the Gcal sync. 2. Connect your Google Account. 3. Create an appointment type and keep the videoConference field blank. 4. Book an appointment. The meeting link is added to the calendar event of Google in sync. After this PR ================== - Add a meeting link only if Google Meet is selected in the configuration. - The appointment_google_calendar module is automatically installed based on dependencies. Task-3614890
Interviewers were unable to view refused or archived job applicants in the recruitment module due to a restriction in the hr_referral module. This fix restores their ability to see all applicant statuses, ensuring interviewers have complete visibility into the candidate pipeline regardless of application status.
Original PR description
An interviewer cannot see refused or archived applicants in the hr_recruitment module. The problem comes from hr_referral. With this fix, the interviewer can see refused and archived applicants. Task: 3802121
Added a helpful error message that appears when users try to start a work order without having employees set up in their company. This prevents confusion when new companies don't have default employees, making it clear why the work order cannot be started and what needs to be done to fix it.
Original PR description
Work order can be start by employee, in scenario when creating new company there is no employees added by default, hence the work order can't be started. This commit is added an error message informing about it. ### [Reproduce] - Install: mrp,account - Create a new company, Select it - Update Settings: - Enable "work orders" (Settings/Manufacturing/Operations) - Set "Generic Chart Template" (Accounting/ Settings/ Fiscal Localization) - Create a new Manufacturing Order (Manufacturing/ Operations/ Manufacturing Orders) - Select any product - Create a work order line - Confirm Manufacturing Order - Click on the start button in the operation line - BUG: Timer not timing opw-3770873
Fixed an issue where sharing a spreadsheet workspace containing only one file would incorrectly share just the document view instead of the workspace view. Users can now properly access the full workspace folder, upload additional documents if permitted, and view all contents when accessing a shared workspace link.
Original PR description
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving…
Issue: when trying to share the spreadsheet workspace with only one document on it, instead of selecting the right view for the workspace we currently share the document view directly without giving the user any change to get to the workspace view where we are able to upload new file if allowed or see the rest of documents in the folder. Steps to reproduce: 1. Install Documents and go to Spreadsheet. 2. Create or Upload a new spreadsheet. 3. Click next to the upload button and in the dropdown, select share to open the share popup. 4. Inside here just select the allow to download and upload documents and we click on share again. 5. Open the link in a new tab and we will see only the document already opened, without any posibility of see the entire folder or uploading a new document. Solution: Inside the `share_portal` of `SpreadsheetShareRoute` when checking for a single document, we also need to check if we are working with a selection, or if it's the folder what we want to share. opw-3688409 Forward-Port-Of: odoo/enterprise#57394
This fix adds a missing dependency to the WhatsApp Delivery module to ensure it works correctly when installed in any order. Previously, if a related module was uninstalled before WhatsApp Delivery was set up, the system would encounter errors. This change prevents those errors by explicitly declaring the required dependency.
Original PR description
The module uses the field `stock_picking.carrier_tracking_url`, defined in module `stock_delivery`, which is not listed as dependency. Although it is auto-installed, if it gets uninstalled before `whatsapp_delivery` is installed, it will trigger an error as the field is missing. Steps to reproduce: - On a fresh 17.0 db, install `stock` and `delivery`, `stock_delivery` will be auto-installed. - Uninstall `stock_delivery`. - Install `whatsapp_delivery` or just `whatsapp`. Forward-Port-Of: odoo/enterprise#60322
This update fixes a bug where users working in right-to-left language interfaces (like Arabic or Hebrew) couldn't resize tasks in Gantt chart views. The issue was that the resize handles were incorrectly positioned based on text direction. Now resizing works properly regardless of the language direction being used.
Original PR description
Forward-Port-Of: odoo/enterprise#60316 Forward-Port-Of: odoo/enterprise#60166
This update improves the Belgian CodaBox integration by deprecating outdated module methods and adding support for companies without Tax IDs (such as non-profit organizations). When a company lacks a Tax ID, the system now falls back to using the Company ID instead, ensuring broader compatibility across different organization types in Belgium.
Original PR description
### [FIX] l10n_be_codabox: deprecate module methods in 17.0 We refactored the CodaBox module in https://github.com/odoo/enterprise/pull/55858 and made `l10n_be_codabox` and `l10n_be_codabox_bridge` deprecated. All methods of `l10n_be_codabox_bridge` were marked as deprecated and that should have been sufficient since this module was on auto_install=True if `l10n_be_codabox` is installed. However, some DBs seem to have `l10n_be_codabox` without `l10n_be_codabox_bridge`. Therefore, with this commit, we also deprecate the methods in `l10n_be_codabox` just to be sure. task-id: none (validated with WTA) ### [FIX] l10n_be_codabox: fallback or Company ID if not Tax ID In Belgium, some companies may not have a Tax ID (for instance non-profit organisations). In that case, we should fallback on the Company ID. task-id: none (validated with LAJE)
This update corrects how Unaffected Earnings and Current Year Earnings are calculated in Swiss financial reports. Previously, these figures were calculated using domain filters that could cause the Balance Sheet to be unbalanced. The fix now uses cross-report formulas that properly link to the Profit & Loss statement, ensuring accurate and balanced financial reporting.
Original PR description
At the moment, the Unaffected Earnings and Current Year Earnings lines are expressed using domains. We change them to use cross-report formulas to the Profit & Loss. This ensures that the Balance Sheet is balanced. taskid: 3060790 Forward-Port-Of: odoo/enterprise#59132
This update corrects how the declining depreciation method calculates asset depreciation. The declining method now properly compares against linear depreciation of the remaining depreciable value over the asset's remaining lifespan, ensuring more accurate depreciation calculations for assets using this method.
Original PR description
The declining method, even though its name doesn't tell it explicitly, implies a comparison with the output of a linear depreciation of the depreciable value on the remaining duration of the asset's lifecycle. task-3734735 Forward-Port-Of: odoo/enterprise#60352 Forward-Port-Of: odoo/enterprise#56601
Users without HR permissions can now view timesheet leaderboard timer displays without encountering errors. The fix allows the system to retrieve billable time target information using elevated permissions when needed, ensuring all employees can access these views regardless of their HR access level.
Original PR description
Currently, in the timesheet leaderboard timer grid, kanban and list views, a search_read is done on hr.employee to retrieve the billable_time_target field. However, this field is exclusive to users that have the hr.group_hr_user, and so if a user without that group tries to open any of these views, a traceback is raised. To fix this, a method was added to retrieve the billable time targets using a sudo().
Fixed an issue where the project settings page was displaying the total count of all tasks instead of only open tasks. The fix updates the underlying data field reference to correctly show only active, incomplete tasks, giving project managers an accurate view of remaining work.
Original PR description
Steps to Reproduce: - Install Project App - Go inside any project and set the state of task as done - Click on project burger menu and click on settings Issue: - The count on the stat button refers to count of all tasks Causes: - Reference of wrong field in the XML i.e ., 'task_count' instead of 'open_task_count'. Solution: - Changing the field to reference it to open tasks count i.e., 'open_task_count' task-3741260 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes how Argentina withholding type information is handled in tax configurations. Previously, when tax settings changed, outdated withholding type values would remain in the system even when no longer applicable. Now the system automatically clears these values when they're not needed, ensuring tax records stay accurate and prevent incorrect data from being used in calculations.
Original PR description
LATAM 1175, ADHOC Task 34189 ---- ### Description of the issue/feature this PR addresses: Clean up field value when is not going to be used: if tax type != none or we are not Argentinean tax then we clean up the value of the Argentinean Withholding type and set it to False. We want it to behave as an onchange: for that, we change the field to be a compute one stored True and continue to be editable by the user. ### Current behavior before PR: If we change the configuration of a tax the Argentinean Withholding type will maitain set not matter is not needed and it is not used. ### Desired behavior after PR is merged: If we change the tax configuration the Argentinean Withholding type field will be clean up in the needed cases Here is a video showing an example https://drive.google.com/file/d/1yMcC-QOJQrh53l-krFDRY7K4xZxMmE8n/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects how payment references are imported from Factur-X formatted invoices. Previously, the system was reading the payment reference from an incorrect field. Now it reads from the same field used when exporting invoices, ensuring consistency between import and export operations.
Original PR description
When importing an invoice from a Factur-X format a payment reference is now read from correct field. From the same field where the original payment reference is exported. Description of the issue/feature this PR addresses: Current behavior before PR: When importing an invoice from a Factur-X format a payment reference was imported from wrong field related to a buyer order referenced document. But when the invoice is exported to Factur-X the original payment reference is exported to a specific field "PaymentReference" under "SupplyChainTradeTransaction" section. Desired behavior after PR is merged: The imported field is the same as exported. I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This fix resolves a crash that occurred when users deleted journal item lines and then tried to save an invoice with a currency change. The system was incorrectly trying to process deleted line data, causing the application to fail. Users can now safely delete journal items and save their invoices without encountering errors.
Original PR description
When user deletes line of journal items and tries to save invoice, a traceback appear. Steps to reproduce the error: - Create a new invoice > add 1 product > Save - Go to journal items > delete 1…
When user deletes line of journal items and tries to save invoice,
a traceback appear.
Steps to reproduce the error:
- Create a new invoice > add 1 product > Save
- Go to journal items > delete 1 line
- Change currency > Save
Traceback:
```
ValueError: not enough values to unpack (expected 3, got 2)
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 72, in web_save
self.write(vals)
File "home/odoo/src/enterprise/saas-17.1/documents_account/models/account_move.py", line 30, in write
res = super().write(vals)
File "addons/account/models/account_move.py", line 2669, in write
self._sanitize_vals(vals)
File "addons/account/models/account_move.py", line 2630, in _sanitize_vals
for command, line_id, line_vals in vals['line_ids']:
```
https://github.com/odoo/odoo/blob/6768cf06138bb5c94a6c77db79ed5d802333b290/addons/account/models/account_move.py#L2422 Here, vals['line_ids'] have 2 values, so for 'line_vals' there is no value.
So when user tries to save invoice,
It will lead to the above traceback.
sentry-5119406548
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix corrects an issue where time-off accrual amounts were calculated incorrectly when employees changed the start date of an allocation without clearing the allocation field. The fix ensures that accrual calculations are properly reset when dates are modified, so employees receive the correct amount of time-off based on their actual work hours.
Original PR description
## Issue: - when creating an accrual plan based on attendance,the duration is not computed accurately when allocating. - the computation is not correct if you select a different start date in the allocation without emptying the field "Allocation" ## Steps To Reproduce: - In the time-off app create an accrual plan: where employee accrue 1h for every hour worked based on attendance. - In the attendance app create a new attendance for 8 hours. - add a new allocation to Mitchell Admin with the plan you created. - Change the date on the validity period, new allocation is 8h. - change the date again and notice the Allocation not computed correctly. ## Solution: - In `_onchange_date_from` when simulating how many days an accrual plan would give from a certian `date_from` we don't reset `number_of_days` to 0. reseting it to 0 fixes the issue. opw-3793961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update disables the QR code feature on Point of Sale receipts for companies using French localization. French tax law prevents customers from modifying orders after payment, which causes the QR code feature to fail when customers try to use it. By removing this unavailable feature for French users, we eliminate confusion and improve the user experience.
Original PR description
Currently, when the company has a french localization and activates the qr code option on the pos bill, if a customer scans the qr code, he will 'inevitably' meet an error: > According to the french…
Currently, when the company has a french localization and activates the qr code option on the pos bill, if a customer scans the qr code, he will 'inevitably' meet an error: > According to the french law, you cannot modify a point of sale order. Forbidden fields: date_order, user_id, lines, payment_ids, ... Steps to reproduce: ------------------- * Install **France - Accounting** * Switch to `FR Company` * Go to the app **Point of Sale** * Select **Configuration** > **Settings** * Enable `Use QR code on ticket` * Open a shop session * Add anything * Select/or not a customer * Select **Payment** * Select any payment method then validate * Scan the qr code on the ticket * Try filling the form and saving > Observation: Error Why the fix: ------------ We understand the confusion for french localization users to be presented with a feature which they are not able to use as intended. The Qr code feature was implemented to make it easier and quicker at the cashier but will always end up in an error, unless a client was selected and the invoice was created when validating the payment at the register. But then, it doesn't save time. Since they are not able to use the feature as intended, we decided to make it unavailable for companies with a french localization. There has been a lot of discussion about how to solve this issue. However, a lot of the ideas discussed were not doable in stable versions and this is the only solution we agreed on. opw-3704767 Forward-Port-Of: odoo/odoo#160304 Forward-Port-Of: odoo/odoo#158786
This fix resolves an issue where users would see an unfriendly error page when accessing extended website controllers. The problem occurred when custom modules extended controller methods with HTTP routes. The fix ensures the system uses the correct routing configuration that accounts for inherited controller methods, resulting in proper error page handling.
Original PR description
-Step to reproduce: create a custom module and try to extend method in
website_slides controller like this:
```
@http.route(sitemap=sitemap_slide_view)
def slide_view(self, slide, **kwargs):
return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs)
```
From there, 'rule.endpoint.original_routing' will take the value from
the extend method not the original one therefore user will one again go
to the the forbidden error page which is'n friendly. We shouldn't access
original_routing because that's the "function's specific @http.route"
-Solution: we only need rule.endpoint.routing because it is the one holding the "merged @http.route accross inherited controllers".
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed a bug where changes to currency settings (like symbol position) weren't showing up in invoice views until the server was restarted. The system now properly refreshes its internal cache when currency configurations are updated, so changes appear immediately without requiring a restart.
Original PR description
Issue ----- The cache is not updated properly when the configuration of a currency changes. This leads to reading stale values in other places. For instance, changing currency symbol position isn't reflected in invoice tree views unless after a server restart. Steps ----- - Open Accounting -> Configuration -> Currencies. - Pick the active currency, say USD. - Change 'Currency Symbol Position' to a different value. - Go to Accounting -> Customers -> Invoices. The displayed amounts don't reflect the change. Cause ----- Cache refresh was misplaced after a premature return, so the cache wasn't refreshed when 'digits', 'position' or 'symbol' fields of `res.currency` are written, although that was the intent. opw-3849155
Fixed an issue where newly added grid items weren't always visible to users when adding elements to a scrolled grid layout. The page now automatically scrolls to show the newly added item, improving the user experience when building web pages with grid layouts.
Original PR description
Before this commit, when adding a new grid item in a grid by using the "Add Elements" option, if the page was scrolled such that the top of the grid was not visible, this new grid item may not always be visible. This is annoying as the user could add an element and not see where it appeared and would therefore need to look for it. This commit fixes this by making the page scroll to the added grid item if it is not fully visible. Steps to reproduce: - Drop the "Text-Image" snippet and enough snippets under it to have a scrollbar. - Toggle the "Text-Image" snippet to grid mode. - Scroll the page so the top of the grid is not visible. - Add a new "Button" with the "Add Elements" option. => The button is not visible. task-3616138 Forward-Port-Of: odoo/odoo#158838
This update reverts a previous change that was causing the product configurator to open unnecessarily when customers didn't select any multi-checkbox options. The fix restores proper behavior for the quick buy feature on the shop page while maintaining support for custom, no-variant, and dynamic attributes.
Original PR description
This reverts commit 436c1c6. The commit was fixing an issue where the product configurator dialog would not be shown for custom attribute, no variant, and dynamic attribute using the quick buy add button on the '/shop' page. The commit introduces an undesirable behavior: the product configurator would always be open if customers choose none of the multi-checkbox options.
This update fixes a technical issue in the web editor that was causing the system to crash when trying to retrieve content in certain situations. The fix ensures the editor handles these edge cases gracefully, improving overall stability and user experience when working with rich text content.
Original PR description
This commit fixes a traceback that occurs when calling `getValue` on `wysiwyg` while the `odooEditor` instance variable is not defined for whatever reason. task-3600667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160710 Forward-Port-Of: odoo/odoo#157979
This fix resolves an issue where sale order lines were incorrectly being added to project subtasks when a partner's company status changed. The problem occurred because the system was recalculating sale line assignments based on partner type changes, even when those changes shouldn't affect the assignment. The fix simplifies the logic to only track direct partner changes, preventing unwanted reassignments.
Original PR description
Steps to reproduce: ------------------- - create a partner which is "individual"; - create a project (with timesheets and billable); - create a task A with timesheets; - link the task A to a sale order line with the partner created; - create a sub task A in task A with timesheets; - remove the sale order line linked to sub task A; - change the partner to "Company" Issue: ------ The sale order line is added to subtask A. The sale order to the partner will not be correct. Cause: ------ We trigger the logic `_compute_sale_line` when the `is_company` of the partner is modified. This is due to the construction of the dependencies, which takes implicit dependencies into account. Solution: --------- Remove the dependency and keep only the dependency with `partner_id` because it is an ORM limitation. opw-3836986
This fix resolves a scheduling inconsistency in manufacturing operations where changing a workorder's duration and then moving it to a different workcenter would update the duration but not the finish date, causing the schedule to display incorrectly. The fix ensures both the duration and finish date are properly synchronized when workcenters are changed, providing accurate visibility into manufacturing timelines.
Original PR description
Current behavior: If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This…
Current behavior: If you change the expected duration of a workorder, then move the workorder to another workcenter, the expected duration is recomputed to but the finish date is not adapted. This leads to an inconsistency in the gannt view. Visually it will look like the duration expected has not changed because the date are still the same. Fix: To fix this we make sure that the finish date is recomputed when the expected duration is modified. This way both date and expected duration are consistent. Steps to reproduce: - Create a product with a BOM - The BOM should have at least 1 operations with a duration of 1 hour linked to a workcenter - Create a manufacturing order for this product, confirm and plan it - Go to the planning by workcenter - Change the duration of the workorder by sliding its finishing date - At this point if you click on it the duration should have changed - Move the workorder to another workcenter - The duration has been recomputed, but the finish date is not adapted (You can click on the workorder to see the duration has changed) opw-3717361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158141
This fix resolves an issue where task titles would disappear when assigning an assignee to a newly created task in the Projects module. The problem was caused by unnecessary dependencies in how the task title field was calculated, which triggered unintended updates when other fields changed. This fix removes those problematic dependencies to ensure task titles remain stable.
Original PR description
### Steps to reproduce issue: 1. In settings, activate Timesheets 2. Go to _Project > Tasks > All Tasks_ 3. Create a new task 4. Give the task a title 5. Choose an Assignee 6. The title disappeared ### Explanation: The title field, `display_name`, is a computed field that gets its value from `name`. This compute has dependencies coming from other computed values. Those dependencies lead to other dependencies up to `project_id`. Because of it, changing `project_id` will trigger `_compute_display_name`. ### Suggested fix: Backporting odoo/odoo@8178ad79bbda92a77d2d6a9e91159b626aca97c7, the cause of the issue is the same. opw-3823040 Forward-Port-Of: odoo/odoo#161071
This fix resolves a confusing issue where website snippets appeared draggable on the login page when a cookies bar was enabled, even though they could only be dropped in the invisible cookies bar. The system now correctly disables snippet dragging when there are no visible drop zones available, providing a clearer and more intuitive editing experience for users managing the login page.
Original PR description
When editing the login page, most snippets are disabled by default and cannot be dropped because there is no place to drop them. However, if you enable the cookies bar, then all snippets are enabled even on the login page, because they can be dropped within the cookies bar. It then looks like a bug for the users who try to drop blocks on the main page and cannot. To avoid that, this commit also disables the snippets if the only spot available is within a cookies bar. opw-3829660 Forward-Port-Of: odoo/odoo#160880
This fix resolves an issue where analytic distributions were not being properly reversed when moving account lines. When users moved an invoice line with analytic distribution to a different account, the analytic distribution data was not being reversed as expected. This update ensures that analytic distributions are correctly handled during account move operations.
Original PR description
Description of the issue/feature this PR addresses: Create an invoice with analytic_distribution. Go to account.move.line, select the line with analytic_distribution, click on action 'Move account' validate --> Issue the analytic_distribution is not reversed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160981 Forward-Port-Of: odoo/odoo#159751
Users can now assign vehicles to expense lines in locked accounting periods without encountering an error. Previously, the system incorrectly prevented this action by treating unchanged tax information as a modification. This fix allows the vehicle field to be updated independently while preserving the integrity of locked accounting records.
Original PR description
### Steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of…
### Steps to reproduce: - Go to Accounting > Accounting > Actions > Lock Dates - Set a Tax Return Lock Date to a date of the previous month - Create and confirm vendor Bill with a taxed line of positive price - Go to Accounting > Reporting > Audit Reports > Journal Report - Hover over the Vendor Bills and click on "journal items" - Add the optional vehicle field to the record - Select your expense line and try to add a vehicle #### > Invalid Operation "You cannot modify the taxes related to a posted journal item..." ### Cause of the issue: Modifying the "vehicle_id" of the account move line will trigger a call of the `_sync_dynamic_line` method in order to modify other account move line linked to the same account move: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move.py#L2285-L2287 During the call of this write method, the account move line that we did not directly modified will not be excluded: https://github.com/odoo/odoo/blob/6a4808802c67f98696338d0b6f6a07934c8003fb/addons/account/models/account_move_line.py#L1571 as `..._field_will_change(line, vals,"vehicule_id")` will be `True`. The error will therefore be raised two lines later because a 'tax_id' is present in vals as a 'tax_id' was set on our related account move line. ### Expected behaviour: Since the 'tax_id' present in vals is the same as the one already set on our account move line, we are not modifying the taxes related to a posted journal item and we should not raise the error. opw-3810718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159919
This update fixes a display issue in the accounting module where search panel content was being cut off due to an incorrect fixed width setting. The fix allows the search panel to automatically adjust its width based on the content it contains, ensuring all information is properly visible to users.
Original PR description
This PR fixes an issue about the search panel content being cut in some accounting interfaces. This is due to the fact that the searchpanel with a specific class would get an arbitrary width value in px. To avoid this issue, we set a `w-auto` to the searchpanel, allowing it to adapt its width to its content. task-3560617 | saas-16.4 | saas-16.4-accounting-searchpanel-width-chgo | |--------|--------| | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/ac479776-76f1-471b-b20b-927abf2fef2f"> | <img alt="image" src="https://github.com/odoo/odoo/assets/128030743/a683f0fd-16b1-49a5-9621-315288c6d186"> | Forward-Port-Of: odoo/odoo#143803
The spreadsheet component has been updated to the latest version, which includes several improvements and bug fixes. These changes enhance performance when working with spreadsheets, fix issues with context menus and filters, and improve the reliability of spreadsheet calculations. Users will experience faster spreadsheet operations and more reliable functionality when exporting and filtering data.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/62947587b [REL] 17.0.18 https://github.com/odoo/o-spreadsheet/commit/0d8547c82 [FIX] misc: faster `deepEquals`…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/62947587b [REL] 17.0.18 https://github.com/odoo/o-spreadsheet/commit/0d8547c82 [FIX] misc: faster `deepEquals` https://github.com/odoo/o-spreadsheet/commit/b934dcafc [FIX] xlsx: Shortcut `deepEquals` for primitive types in `pushElement` Task: 3733743 https://github.com/odoo/o-spreadsheet/commit/0b2be2266 [FIX]xlsx: replace json.stringify with deepEquals Task: 3733743 https://github.com/odoo/o-spreadsheet/commit/0e0f31a38 [FIX] xlsx: remove useless normalization Task: 3733743 https://github.com/odoo/o-spreadsheet/commit/a87b0d0b5 [FIX] XLSX: simplify `pushElement` helper Task: 3733743 https://github.com/odoo/o-spreadsheet/commit/9f6996086 [FIX] Evaluation: ignore invalid ranges in dependency graph https://github.com/odoo/o-spreadsheet/commit/c678905b3 [FIX] Grid: Context menu position was broken https://github.com/odoo/o-spreadsheet/commit/fe8161032 [FIX]: Filters: Do not export 1-row filters to xlsx files Task: 3839556
Users can now easily show or hide Terms and Conditions on product pages directly from the web editor's Customize tab, without needing to manually delete text. This restores functionality that was available in previous versions and provides a more user-friendly way to manage Terms and Conditions visibility.
Original PR description
Before this commit, users could not disable the Terms and Conditions display on the product page from the Customize tab of the web editor. To remove it from the product page, the only workaround was to remove the text in that div. Now, a button will be available in the Customize tab of the web editor to quickly show or hide the Terms and Conditions. Forward-Port-Of: odoo/odoo#161230
This fix corrects an error in how sales order section subtotals were being calculated when taxes were included in the price. Previously, the system was incorrectly mixing tax-included and tax-excluded amounts, resulting in inaccurate subtotal displays. This ensures customers see the correct subtotal amounts on their sales orders.
Original PR description
Subtotal for section with tax included was wrongly calculated, taking into account subtotal of tax excluded and tax icnluded. opw-3850406 Forward-Port-Of: odoo/odoo#161441
This update corrects how taxes are rounded when using the global rounding method in Odoo's accounting system. The fix allows companies using Mexican CFDI invoicing to comply with government requirements by preventing over-distribution of tax amounts across invoice lines, which was causing calculation errors.
Original PR description
The MX CFDI is designed to only work with 'round_globally' as taxes computation method. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160379
This update corrects an incorrect payment code that was preventing MobilePay transactions from processing successfully. The fix ensures customers can complete payments using the MobilePay payment method without errors.
Original PR description
The payment with MobilePay payment method failed due to the wrong code. opw-3859956
This fix prevents a duplicate reservation process that was causing issues with package assignments in the manufacturing subcontracting dropshipping workflow. The system was reserving inventory twice during order validation, which led to incorrect package tracking and data corruption. By removing the redundant reservation call, the process now works correctly on the first pass.
Original PR description
The `stock.move:_action_done()` already reserve the next mto moves at validation. Calling the reservation method after the validation again may lead to unwanted results like calling `check_entire_pack()` and messed up the result_package_id on the stock move lines. Task : 3764822 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161327 Forward-Port-Of: odoo/odoo#160337
Fixed an issue where loyalty rewards with product tags were automatically applied without letting users choose which product they wanted. Now the system only auto-applies rewards when there's truly only one option available, ensuring users can select their preferred reward when multiple tagged products are available.
Original PR description
Currently, when there is only one loyalty program available for an order, we apply it automatically without opening the wizard. This is a problem when the reward is a free product among all with a specific tags because the user can not choose it (it takes the first one by default) We now automatically apply only when there is only one reward possible opw-3774944
Users can now properly uncheck the "Generate Facturae EDI file" option when sending and printing invoices in Spanish companies. Previously, this checkbox was locked and couldn't be unchecked due to a technical issue with how the field was configured. This fix restores the ability for users to control whether Facturae files are generated for their invoices.
Original PR description
### Steps to reproduce * install l10n_es_edi_facturae * create and confirm an invoice * click on 'Send & Print' You should see that you are unable to uncheck 'Generate Facturae edi file' ### Cause In 0d3d6c8, `l10n_es_edi_facturae_checkbox_xml` changed to a non-stored and read-only computed field. ### Fix A proper fix would consist in making the field `l10n_es_edi_facturae_checkbox_xml` stored. But we can't do that in stable. So we make it `company_dependent` as a workaround. opw-3772085
Fixed an issue where comparison prices weren't updating when customers switched the website's currency. The system now properly converts all pricing information to match the selected currency, ensuring customers see accurate prices regardless of which currency they choose.
Original PR description
`compare_list_price` wasn't updated when the user changed the website's currency. Now, it's converted to the website's currency. This change also makes the conversion of `price_extra` and `list_price` safer by fetching both the `from` currency and the `from` amount from the same record. opw-3845887
This update fixes an issue where placeholder text was incorrectly appearing in actual printed stock reports (delivery slips and picking operations). The fix removes unnecessary placeholders for optional fields, hides the Unit of Measure field when not enabled, and corrects a confusing placeholder label. This ensures reports print cleanly without test or placeholder content.
Original PR description
Fixes a few things: - A couple placeholders existed for non-required fields, which means in certain cases they would be printed in real reports (i.e. not just shown in studio) - hide the UoM from the deliveryslip when the setting isn't active (this is broken in earlier versions too, but fix can be backported if someone finally complains about it since it's been there for awhile) - Updates a placeholder that was confusing (a location instead of a package name) Note only `stock` reports were checked for this fix, there are probably still other problematic reports. See PR: https://github.com/odoo/odoo/pull/129310 for reference of when placeholders were added in --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161360
This fix resolves an issue preventing users from sending credit notes to Facturae (Spanish electronic invoicing system) when those credit notes were created from already-paid invoices. The problem was caused by a data type mismatch in the credit note processing function that would crash with a database error. Users can now successfully submit credit notes regardless of the payment status of the original invoice.
Original PR description
Currently, you cannot send a credit note to Facturae if it was created from a paid invoice ### Steps to reproduce * install `l10n_es_edi_facturae` * create an invoice and register its payment * created and confirm a credit note from your invoice * attempt to send that invoice to Facturae You should be met with the following traceback: `psycopg2.ProgrammingError: can't adapt type 'account.move'` ### Cause In the function `_l10n_es_edi_facturae_get_corrective_data()`, there is an attempt to browse the output of a call to `_l10n_es_edi_facturae_get_refunded_invoices()`. This function is expected to return a mapping of id to id. However, in certain scenarios, it may return a mapping of id to recordset instead. opw-3811170 Forward-Port-Of: odoo/odoo#161486
This fix resolves an issue where custom-named direct message conversations were not appearing in the Discuss app's quick search sidebar. Previously, the search function was looking at the wrong field to match conversation names, causing renamed DM chats to be invisible when filtering. Now the search correctly uses the display name field, making all renamed conversations searchable.
Original PR description
Before this commit, when a DM chat had a custom name, the search was not taking it into account. Steps to reproduce: - Log in as Mitchell Admin - Open a DM chat with Marc Demo in Discuss app - Rename conversation to "Test" - Open more than 20 chat/channels (can create 20 channels) - type "Test" in the quick search of discuss app sidebar => The DM chat with Marc Demo is not visible in filtered sidebar. This happens because the quick search was relying on `thread.name`, which actually only matches exactly the UI when this is the name of a channel or when a group chat is explictly named. The actual thread field used that matches textual name of thread is `thread.displayName`, and this field is synced with custom DM chat if any. Before/After <img width="297" alt="before" src="https://github.com/odoo/odoo/assets/6569390/ee82a9c5-8413-4887-96d1-85c80120bb43"> <img width="290" alt="after" src="https://github.com/odoo/odoo/assets/6569390/06f2a25f-34f2-413a-9408-70292113ea9b">