Daily updates from Odoo
Friday, March 8, 2024
47 changes · 17.0
Resolved issues and error corrections
This fix resolves an error that occurred when users tried to open the Customer Statements report for editing in Web Studio. The issue was caused by missing context data during report initialization. The fix ensures the report can be opened properly by using alternative data when context is not available.
Original PR description
This issue occurs when the customer tries to open the Statements report using studio, at that time error will be generated. step to reproduce- - Install the `Accounting Customer Statements & Studio`…
This issue occurs when the customer tries to open the Statements report using studio, at that time error will be generated.
step to reproduce-
- Install the `Accounting Customer Statements & Studio`
- Open the Accounting.
- Go to Customers Menu > Customers > open any record.
- Click on the web_studio button > Reports.
- Open the `Customer Statements`.
- Error will be generated.
sentry traceback-
```
KeyError: 'context'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "home/odoo/src/enterprise/17.0/web_studio/controllers/report.py", line 351, in load_report_editor
report_qweb = self._get_report_qweb(report)
File "home/odoo/src/enterprise/17.0/web_studio/controllers/report.py", line 441, in _get_report_qweb
render_context = report._get_rendering_context(report, [0], {"studio": True})
File "home/odoo/src/enterprise/17.0/web_studio/models/ir_actions_report.py", line 44, in _get_rendering_context
ctx = super()._get_rendering_context(report, docids, data)
File "addons/stock/models/ir_actions_report.py", line 8, in _get_rendering_context
data = super()._get_rendering_context(report, docids, data)
File "odoo/addons/base/models/ir_actions_report.py", line 930, in _get_rendering_context
data.update(report_model._get_report_values(docids, data=data))
File "home/odoo/src/enterprise/17.0/l10n_account_customer_statements/report/customer_statements.py", line 11, in _get_report_values
docs = self.env['res.partner'].browse(data['context']['active_ids'])
```
[1]-https://github.com/odoo/enterprise/blob/661249d3ed4cbcbeff4ed96f5cbc31d5307d55e2/l10n_account_customer_statements/report/customer_statements.py#L11
This error occurs because the context[1] hadn't been prepared when the statement was opened.
after this commit, Should the context not be prepared, The `docids` will be passed to open the statement.
sentry-4721784639Fixed the positioning of the SLA Deadline filter in the Help Desk search interface. The filter was incorrectly appearing under Properties instead of being grouped with the Create Date filter. This improves the user experience by organizing related date filters together in a more logical way.
Original PR description
-master -saas-17.1 Steps to reproduce: - Open Help Desk app - Open any help-desk team - Click on search bar on the top Issue: - The issue here is that the SLA deadline filter in under properties which is separated and should be under Create Date filter Cause: - The SLA Deadline is added newly into the XML file but the field above i.e, Create Data is used as an Xpath(Field as an Xpath) to add a separator in a inherited record causing the the filter to be displaced Solution: - Changing the Xpath(Field as an Xpath) as SLA DeadLine allows the Properties filter to be added and SLA Deadline to be under Create Date Filter task-3707563
This fix resolves an issue where users couldn't edit product quantities in the catalog when accessing it from Field Service tasks. The problem occurred when multiple tasks referenced the same product—the system was incorrectly computing quantities from all tasks instead of just the current one, making products read-only. Now the catalog correctly shows editable quantities based on the specific task being viewed.
Original PR description
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products`…
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in the catalog”** Cause of the issue: - The way the catalogue is computed was refactored between 16.4 and 17.0 see: odoo commit bc01c7bcec974ee095f5855f225667645ef40213 The above situtation is not yet handled by this refactoring. In 16.4, since the catalogue was acceced from the task linked to the Field service, the quantities it displayed were computed with respect to that task. However, in 17.0 the quantities appearing in the catalogue are computed from the main SO containing both `Field services` SOL instead of being computed contextually from the task they are linked to. To be more precise: - When clicking on the smart button, the quantities appearing in the calatalogue are computed by the `_get_product_catalog_order_line_info`. This method starts by grouping the SOL referencing each product of the catalogue using the `_get_product_catalog_record_lines`: https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/product/models/product_catalog_mixin.py#L91-L92 https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/sale/models/sale_order.py#L1823-L1829 But here is the problem, since both SOL were able to reference the same product of the catalogue the product of the catalog will be set to 'readOnly' here (because `self` will contain both SOL): https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1222-L1227 Hence, we will not be able to edit its value from the catalogue: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/product/static/src/product_catalog/order_line/order_line.xml#L18-L20 Fix: - As discussed with the PO of the Field Service module (see conversation of the ticket), the catalogue should be computed contextually using the task from which we access it and not from all tasks referring to that product in the main SO. Doing so will solve the problem since only one SOL will be associated to that product of the catalogue and the product will be set to `'readOnly' : False`: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1212-L1216 opw-3748833 ---
This fix corrects how payment policies are assigned to Mexican invoices (CFDI v4.0) to comply with official tax regulations. Previously, invoices with due dates later than the invoice date were incorrectly marked as immediate payment (PUE) instead of deferred payment (PPD). The update ensures invoices are now correctly classified based on actual payment terms and method specifications.
Original PR description
**Incorrect Payment Policy Calculation for CFDI v4.0** Impacted versions: - 17.0 **Current behavior:** When an invoice is created with a due date that is later than the invoice date, yet still within the same month, the system incorrectly assigns a payment policy of 'PUE'. This issue persists even when specific invoice payment terms are indicated. **Expected behavior:** According to [Anexo 20](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), [Rule 2.7.1.39](http://omawww.sat.gob.mx/normatividad_RMF_RGCE/Paginas/documentos2024/rmf/rmf/RMF_2024-29122023.pdf) as well as rule 2.7.1.32 (same link as rule 2.7.1.39) an invoice must be assigned a payment policy of 'PPD' if payment will not be made on the day of issuance, or if the method of payment is not specified.
Fixed an issue where users couldn't properly select their preferred resource when returning to the time selection screen in appointment scheduling. Previously, a pre-selected resource would be automatically chosen, preventing users from changing it. Now users can freely select their resource when booking appointments with the 'Time then resource' option.
Original PR description
When coming back to the time selection screen, from an error or through chevrons, the previously chosen resource (resource_selected_id in the url) was selected for 'Time then resource' in the resource dropdown, and at loading, also when computing available slots. In order to let the user choose their resource in that case, do not use the selected resource for time_resource types, nor for computing availabilities at first loading, nor to restrict the resource dropdown. Task-3603354 Forward-Port-Of: odoo/enterprise#56586
This fix resolves a crash that occurred when users tried to delete a newly added product line from a batch transfer in the barcode app. The issue happened because the system tried to access information about a product line after it had been removed, causing an error. The fix adds a simple check to ensure the product line still exists before trying to access its details.
Original PR description
Steps to reproduce ================== - Go to the barcode app - Click on "Batch transfers" - Open a record - Add a new product and confirm - Click on the pencil next to the newly added product - Click on the delete button => `Cannot read properties of undefined (reading 'suggested_package')` Cause of the issue ================== When deleting a line, it is removed from the state [0] Solution ======== We simply need to check that the line exists --- [0]: https://github.com/odoo/enterprise/blob/5ef4a85febcde0a690a71cb1886a8a74daf31f47/stock_barcode/static/src/models/barcode_model.js#L390 opw-3688415 Forward-Port-Of: odoo/enterprise#58201 Forward-Port-Of: odoo/enterprise#57691
This update fixes two issues in the Knowledge app: portal users can now properly view embedded kanban boards in published articles without errors, and the Share Wizard no longer displays unnecessary separators when articles have no members. These fixes improve the user experience when sharing and viewing knowledge articles across different user types.
Original PR description
**Current behavior before this PR:** - Create 1 article that has an embedded kanban and 1 article inside a kanban(both articles are published). Now if the user opens this article from another user - member/portal, the user gets an error like 'Something went wrong'. - When an article has no members, the separator appears under the Shareable URLs section in the Share Wizard. **Reason:** - Access to the Kanban stage was only for the user who had access to that article, there was no condition that the stage was shown to the member/portal user if the article was published and the article was an item article. - There was no condition for not showing a separator when that article had no members. **Desired behavior after this PR:** - Kanban will appear properly with read access to the portal if the article is published. - If there is no member then the separator will not appear. **Task**-3486083 Forward-Port-Of: odoo/enterprise#56230
The "insert in spreadsheet" button in pivot views was incorrectly showing a tooltip with "0" when active. This fix removes the unwanted tooltip, which should only appear when the button is disabled due to duplicate grouping options. The update also removes redundant test code that was duplicating existing test coverage.
Original PR description
The button "insert in spreadsheet" added in the pivot view would display a tooltip of "0" when the button was active. The tooltip was only meant to be present when the button was disabled due to the presence of duplicated group bys in the pivot. This revision fixes the tooltip presence on the button and also removes a test that: - had a description that did not match the actual test - was in fact testing the same behaviour as another test -> useless redundancy Task: 3790072 Forward-Port-Of: odoo/enterprise#58297 Forward-Port-Of: odoo/enterprise#58160
This fix prevents manually entered discounts from being automatically reset when confirming a subscription order. Previously, when a start date was automatically set during confirmation, it would trigger an unintended recalculation of discount fields, overwriting any manual adjustments made by users. The fix protects discount values from being recomputed during the confirmation process.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have SOL discounts enabled; 2. create a pricelist with a discount; 3. set Discount Policy to Show public price & discount; 4. create a quotation; 5. using the pricelist, add a product it's applicable to; 6. manually modify the discount; 7. in Other Info, add a Start Date. Issue ----- The manually modified discount was reset. Cause ----- The sale_subscription's override of `_compute_discount` adds `start_date` as a dependant field. When no start date is at confirmation, it will be set to the current date, triggering a recomputation of discount fields. Solution -------- Add an `action_confirm` value to the context when confirming a subscription, and check for it in `_compute_discount` to avoid recomputing non-upsell line discounts. opw-3646915 Forward-Port-Of: odoo/enterprise#58022 Forward-Port-Of: odoo/enterprise#57222
This fix corrects how the system identifies invoices by disabling layout-based matching for customer invoices. The layout detection feature was incorrectly being used to identify customers, when it should only identify suppliers. This change ensures the feature works correctly by limiting it to vendor bills only, improving invoice processing accuracy.
Original PR description
The idea behind this matching is that invoices emitted by the same supplier will often look very much alike and thus share the same layout. Using the detected layout to identify the customer of a customer invoice doesn't make sense since the layout only identifies the supplier of the invoice. This feature should only be used on vendor bills. Forward-Port-Of: odoo/enterprise#58294
Timesheets added to helpdesk tickets now correctly inherit the commercial partner information from the ticket itself, rather than leaving it blank. This ensures consistent behavior with how timesheets work in regular projects and improves billing accuracy for helpdesk-related work.
Original PR description
Issue: ------ In the helpdesk application, when a timesheet is added to a helpdesk ticket, it does not have a commercial partner (we can add the field with studio to see this behaviour). There may be one if a commercial partner exists for the helpdesk project. This behaviour is contradictory to that found in project. Solution: --------- Add the `helpdesk_ticket_id` field invisibly in the view so that this field is in the fields to be updated with the onchange. It will be correctly updated during the onchange. Override the compute method to obtain the `commercial_partner_id` field in order to take the commercial partner from the helpdesk ticket and not from the task. opw-3759824 Forward-Port-Of: odoo/enterprise#58214 Forward-Port-Of: odoo/enterprise#58043
This fix resolves an issue where users without specific permissions to event registrations would encounter an access error when trying to change the partner on a sales order, even if no registrations were linked to that order. The change applies proper permission handling to prevent unnecessary access restrictions.
Original PR description
If the user doesn't have rights to registrations and tries to change the partner on a SO, this will raise an access error even if there's no registrations linked to the SO. We use sudo to be coherent with what is done in _update_registrations. 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#151782 Forward-Port-Of: odoo/odoo#151506
This update fixes a memory issue in the delivery module that occurred when processing large numbers of stock movements. The system now retrieves only the necessary data instead of loading everything into memory, resulting in faster processing times (27% improvement) and preventing crashes when handling thousands of records.
Original PR description
compute_packages method fetches all columns for stock_move_lines and its result_package_id. If stock_move_lines are a big number, it causes memoryerror. Pre fetch only the required fields. Also its better to use _read_group then search count in a loop. ``` select COUNT(*) from stock_move_line +---------+ | count | |---------| | 2546604 | +---------+ ``` While fetching 4000 records. time before: 4.77s time after: 3.50s 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 fix resolves a crash that occurred when editing links in the website editor, particularly when double-clicking the "Contact Us" button. The issue was caused by a timing problem where the system tried to access link editing tools before they were fully loaded. The fix ensures the system waits for all components to be properly initialized before attempting to edit links.
Original PR description
Steps to reproduce: - Go to website (Homepage) > Switch to "Edit" mode. - double-click the "Contact Us" button in the header or keep clicking it many times > Traceback: Cannot read properties of…
Steps to reproduce: - Go to website (Homepage) > Switch to "Edit" mode. - double-click the "Contact Us" button in the header or keep clicking it many times > Traceback: Cannot read properties of undefined (reading 'find')... After converting the `linktools` widget to Owl in [1], the DOM element of the component [2] was retrieved in an async process after it was mounted, (some legacy code can trigger the instantiation of the `linktools` when its parent component is not in the DOM and `this.linkComponentWrapperRef.el` won't be returned, see: `Link` > `onMounted`). When double-clicking the link, This implementation will lead to a race condition where the `onWillUpdateProps()` (mainly triggered by the click to focus the URL input...) will try to access the DOM element from [2] before being correctly set in `onMounted()`. The goal of this commit is to fix this behaviour by simply waiting for `onMounted` changes to be done before doing any adaptation on the `linktools` DOM. [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997 opw-3706902
When receiving electronic invoices through the Italian EDI system, documents were incorrectly assigned sequence numbers from the MISC journal instead of their proper journal type. This fix ensures that imported bills and other documents receive the correct sequence number based on their actual document type, improving invoice organization and tracking accuracy.
Original PR description
Currently, if you have an empty MISC journal and receive a document, that document will be assigned a MISC sequence, regardless of the actual document's type. ### Cause When a document is received, it is processed in two steps: 1. An empty account move is created and linked with the document. 2. The newly created move is populated with data extracted from the document. At stage 1, when the move is created, it is temporarily placed in the MISC journal. In the event that this journal is empty, a sequence is assigned to the move. Consequently, even if the move's journal is subsequently changed, the sequence remains unaltered. ### Fix Manually recompute the sequence when the move's type is set. opw-3663873
This fix corrects a bug where landed costs were being calculated based on the original planned quantity instead of the actual produced quantity. For example, if a manufacturing order planned to produce 1000 units but only 900 were actually produced, the landed cost would incorrectly be applied to all 1000 units. This update ensures landed costs are now properly applied only to the units that were actually produced.
Original PR description
Steps to reproduce: - Create an MO qty = 1000 - Only produce 900 - Create a landed cost for that MO Bug: landed cost is applied on 1000 units instead of 900 starting V17 definition of the field (product_ty) has been changed to reflect the intial demand apply same fix as in: https://github.com/odoo/odoo/pull/137864/files#diff-d41327f63c4c3d8d369a3f8622f794aa03f79f5f93d9ec01dfa5c179fd8f31eaR159-R162 opw-3696385
This fix resolves an error that occurred when POS users without access to the first company tried to use the self-order mobile menu. The issue was caused by incorrect company permissions in the system context. Users can now access the self-order page regardless of which company they have permissions for.
Original PR description
Before this commit, if the POS user didn't have access to the first company, an access error would be raised when accessing the self-order page. The steps to reproduce this issue are as follows: 1. Add another company and set up POS self-order. 2. Remove the other company from the Marc user. 3. Open the POS in the new company. 4. Try to access the mobile menu. This would result in an access error. The issue was that the first company existed in the `allowed_company_ids` in the context. To solve this, we need to correctly set the `allowed_company_ids` in the context. opw-3744500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug in the Saudi electronic invoice system where invoices created during specific times (12:00 to 3:00) were incorrectly validated due to timezone handling. The fix ensures that invoice dates are properly compared while accounting for the user's timezone, preventing validation errors for Saudi companies.
Original PR description
Steps to reproduce ------------------ * install `l10n_sa_edi` * switch to a Saudi company * make sure user timezone is Asia/Riyadh * create and post an invoice between these time from 12:00 to 3:00 Cause ----- EDI Invoice could be validated closes odoo/odoo#155363 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#155895
This fix enables users to select a default temporary account when setting up Point of Sale accounting for branch companies. Previously, this option was unavailable for branch company users, limiting their ability to configure POS settings properly. Now branch companies have the same account selection capabilities as main companies.
Original PR description
**Before this PR:** When the user creates a branch company, the pos(accounting) setting does not allow the selection of a default temporary account for the user. **After this PR:** The user is allowed to choose a temporary account from the branch company. **Task**-3775873
This fix resolves an issue where users couldn't select sales orders when working with individual contacts within a company structure. The system was incorrectly filtering results by comparing company-level and individual-level contact identifiers. Now the correct contact information is used, allowing employees to properly record timesheets against their company's sales orders.
Original PR description
Steps to reproduce:
- Create a new company contact and add a contact inside that company
- Create two service product that are service with following config:
- Invoicing policy: Based on Timesheets
- Create on Order: Project & Task
- Make an SO for the contact inside the company with the two service in
the order
- Confirm the SO
- Click on the smart button "Recorded"
- Click on new
- Click on new line at the "Sale Order item" column
Issues:
The list display "No records"
Solution:
Make sure that we search with the correct attributes, before we were
trying to match partner_id and commercial_partner_id.
Although similar in our case they are not equal as commercial_partner_id
represent the company and partner_id represent the individual.
opw-3750939This fix resolves an issue where Italian EDI invoices were being imported into only the first company when the automated import process ran in a multi-company setup. Now invoices are correctly imported into their respective companies. This ensures proper invoice organization and accounting accuracy across multiple company entities.
Original PR description
When the Cron runs in a multi-company environment, all invoices imported only in first company. They should be imported in the company they belong to. Ticket link: https://www.odoo.com/web#model=project.task&id=3744537 opw-3744537
This fix allows company branch locations to set their own default tax rates in Point of Sale settings, instead of being forced to use the parent company's taxes. This gives multi-location businesses more flexibility to configure tax settings appropriate for each branch.
Original PR description
Before this commit: When a company having branches, they uses the same taxes as the parent company, In POS settings, the default tax used a company domain which does not allow branch to change the default tax After this commit: A branch is allowed to change the default tax task-3775857 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 fix corrects an issue where invoice tax totals were displaying incorrectly (87.53 instead of 87.52) when using child contacts as invoice partners. The problem occurred because the system wasn't properly tracking the correct partner information when calculating and rounding tax amounts. This ensures accurate tax calculations regardless of which contact level is used on an invoice.
Original PR description
Set 'Rounding Method' to 'Round globally' Set 'Cash Discount Tax Reduction' to 'Always (upon invoice)' Create a Payment term with 1% discount if paid before 30 days Create a company partner with child contact Create an invoice: - Add as partner the company partner (parent contact) or no contact at all (makes no difference) - Add a line with product 420.99, tax 21% not included - Add the payment term Tax total will show 87.52 Add the child contact as partner (set again payment terms if needed) Issue: Tax total will show 87.53 This occurs because, when simulating the not yet stored epd vals, we create the line using the `partner_id` and not the commercial partner. Then, when tax amounts are aggregated and rounding errors are managed the partner is used as grouping key to retrieve vals, so we don't fix the rounding error correctly opw-3661210 Forward-Port-Of: odoo/odoo#154174
The purchase dashboard was using a fixed date from September 2022 that no longer reflected current data. This fix updates the dashboard to automatically use today's date, ensuring the purchase and stock information displayed is always current and relevant to your business needs.
Original PR description
Replace the hardcoded date "09-15-2022" in the list domain by `context_today().strftime(\"%Y-%m-%d\")` The domain is now stringified since it contains a dynamic value which is not valid in a json file. Task: 3756934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix enables branch companies in the point-of-sale system to use their parent company's fiscal position settings. Previously, branches were unable to access parent fiscal positions, which limited configuration flexibility. This change improves operational efficiency for multi-branch retail operations.
Original PR description
**Before PR:** - In the point-of-sale, when a company had branches, - The branch company was unable to use the fiscal position of its parent company. **After PR:** - The branch company can now use the fiscal position of its parent company in the point-of-sale. Task ID: 3775865
This fix corrects how project stages are displayed when creating subtasks from the portal. Previously, personal stages were incorrectly included in the stage options. Now only the relevant project stages are shown, making it easier for users to select the correct stage when creating subtasks.
Original PR description
When creating a sub-task from a task form view in portal, the domain of the stage should exclude personal stages and include only the one of the project. taskid:3551354 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#156580 Forward-Port-Of: odoo/odoo#142555
This fix corrects how the accounting dashboard displays financial data when your company has multiple branches or related companies. Previously, users could see data from companies they shouldn't have access to. Now the dashboard properly respects company access permissions, ensuring each user only sees data from companies they're authorized to view.
Original PR description
Setup 2 companies with a COA: compA & compB For compA, have a journal having some data Give you access to compA & compB but make sure compB is your main company => samples data are displayed on the accounting dashboard for the journal Setup 2 companies with a COA: compA & compB, compB being a branch of compA For compA, create a journal Add some data into this journal using compB Give you access to only compA => you should not be able to see the data from compA since the data belongs to compB Introduced by: https://github.com/odoo/odoo/commit/24789b2c906e71d347924bfa1bcc7d3ca77d8daf issue: 3722386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153641
This fix resolves an error that occurred when stock managers tried to deactivate picking types without having access to point of sale settings. The system now properly handles permission checks so that stock managers can manage picking types independently without requiring point of sale configuration access.
Original PR description
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#154888
Fixed a bug in the website blog module where blog post redirects were keeping unnecessary extra parameters in the URL. The fix simplifies the redirect logic to avoid duplicate query parameters that were being added in an incorrect format, resulting in cleaner and more reliable blog post URLs.
Original PR description
Don't try to keep extra params and co. Keep it simple... Else we should pop from request.params `blog` and `post` keys because now they are converted as query param with the slug format: /blog/name-1/post-1?blog=blog.blog(1,)&question=blog.post(1,) Forward-Port-Of: odoo/odoo#156890
This update prevents companies from being archived if they are linked to a website. When a company associated with a website is archived, public users lose access to that website and encounter errors. This fix ensures websites remain accessible by blocking the archival of companies that power them.
Original PR description
This commit prohibits the archival of a company if it is associated with a website. opw-3749772 Forward-Port-Of: odoo/odoo#156470
Fixed an issue where technical codes in Italian electronic invoice XML templates were being translated into other languages. These codes have strict character limits and must remain unchanged for compatibility with the Italian Tax Agency and domestic systems. The fix ensures codes like "Exch.Rate" stay in their original form rather than being translated to alternatives like "Currency".
Original PR description
Codes like "Exch.Rate" in the Italian EDI XML template for invoices were translated. They shouldn't be, as they have pretty short char limit and it's risky to people change that. The XML users are either domestic or the Italian Tax Agency itself, so no point in translating "Divisa" into "Currency" anyway. Link: https://www.odoo.com/web#model=project.task&id=3627379 opw-3627379 Forward-Port-Of: odoo/odoo#156781 Forward-Port-Of: odoo/odoo#153111
This fix resolves a problem where taxes were incorrectly marked as outdated (with [old] prefix) when reloading fiscal localization settings. The issue occurred because the system was incorrectly detecting changes in grouped taxes that don't have repartition lines defined. Now the system properly recognizes when these taxes haven't actually changed, preventing unnecessary updates.
Original PR description
To reproduce: - Install l10n_it - Go in settings - Fiscal Localization => reload - Go to the taxes => You will find taxes with [old] prefix The issue comes that we want to consider that a tax has changed if it has different repartition lines. We don't consider taxes that are defined without repartition lines. The template will have no lines, but the compute on actual taxes will generate default ones. It then considers that the tax has changed. task-3777629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156028
This fix prevents the system from incorrectly validating customers as valid Peppol participants when they don't have Peppol identification details (EAS or endpoint) configured. Previously, users could run verification on any customer in the list view, causing non-Peppol customers to appear as valid participants. Now verification only runs when proper Peppol details are present.
Original PR description
If a partner doesn't have peppol eas or endpoint set, we still go through with checking participant's registration. This is not an issue if checking on a partner form, as the Verify button is invisible without these details being filled in. However, in the partner list view the button is always visible and it is possible to run verification for non-peppol customers. As a result, all of them show up as valid Peppol participants. With this commit we only run verification if there are eas and endpoint details. opw-3784945 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156877
This update fixes a technical error that occurred when users created inventory reorder points if archived storage locations existed in the system. The system now properly handles archived locations during reorder point creation, preventing errors and allowing the process to complete successfully.
Original PR description
orderpoint creation should also consider archived location while building the domain or else users will be faced with a `KeyError` Description of the issue/feature this PR addresses: Fixes KeyError when creating orderpoints Current behavior before PR: Users are faced with a KeyError Desired behavior after PR is merged: KeyError is fixed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156906 Forward-Port-Of: odoo/odoo#155397
Blog post cover images were displaying blurry when using the dynamic "Blog Posts" snippet with certain layouts, especially when showing fewer items. This fix improves the image sizing in the snippet templates to ensure blog post images display clearly and professionally on your website pages.
Original PR description
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are…
Some templates are rendering the blog post cover in a very blurry way. It was not detected sooner because of a mix of: - The default blog posts img do not go through the `/web/image` route and are not resized down / impacted - Some of the layout are working fine - For the problematic layouts, the problem gets worst when you select only one or two "Fetched Elements". Steps to reproduce: - Add an image on a blog post (you can just download the one on the PR, see at the end of this message) - Add a "Blog Posts" dynamic snippet on a page - Select "Card Layout" - By default, you'll see that the image is very blurry. If you select 2 (or 1) instead of 3 fetched elements, it will get even worst. Note that it's like that since forever, when it was introduced with https://github.com/odoo/odoo/commit/3c0d98bcd8adf9325ee3497eb8d25ec7f904d6a5 opw-3771992 Image to test:  Forward-Port-Of: odoo/odoo#156381
This fix resolves an issue where duplicate exchange difference entries were being created in the stock accounting system when using multi-currency purchases with anglo-saxon accounting. The fix ensures exchange differences are properly created with correct conditions and reconciled in the right order, preventing duplicate journal entries and maintaining accurate financial records.
Original PR description
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday:…
When mixing anglo-saxon accounting and multi-currency, it sometimes leads to incorrect AMLs in the stock-in account To reproduce the issue: (Company in USD) 1. Setup some currency rates: - Yesterday: 1000 EUR = 4335.1 USD - Today: 1000 EUR = 4348.0 USD 2. Create an auto-avco product 3. (Yesterday) Buy one product at 1000 EUR and receive it 4. Deliver the product 5. Bill the PO 6. Open the journal items of stock-in account Error: The AML for the exchange difference has been created twice When posting the bill, it leads to `_generate_price_difference_vals` where we generate AML/SVL in case of price differences. There, we also generate such records in case of exchange difference. This is what we do in the above use case. However, the AML is wrongly encoded, we need to respect some specific conditions: https://github.com/odoo/odoo/blob/d780a2fc73259244411329027349fad1cb353f34/addons/account/models/account_move_line.py#L1773-L1779 Otherwise, the reconciliation process won't work correctly and will generate its own AMLs for the exchange difference (hence the above error). On top of that, to ensure a full reconciliation, we need to first reconcile the exchange diff AML with the bill one. This is what we are supposed to do in `/stock_account`: we split all stock-in AMLs into three recordsets: `correction_amls`, `invoice_aml`, `stock_aml`. However, we don't correctly isolate the correction AMLs. Therefore, we try to reconcile all AMLs at once, which will not work. Note: This commit brings a behaviour change since the amount currency of exch-diff AML will now be zero, as it should (again, see the comment of the code quoted above in the reconciliation process). This also explains why this commit modifies an existing test: comparing the `balance` and the `amount_currency` of such AML is incorrect. OPW-3544318 Forward-Port-Of: odoo/odoo#155421
This fix ensures that QR codes are included when receipts are reprinted in the Point of Sale system. Previously, reprinted receipts were missing QR codes, which could cause problems with receipt validation and scanning. This update restores full functionality for receipt reprints.
Original PR description
Before this commit, if a receipt was reprinted, the QR code was not included. This could lead to issues with receipt validation and scanning. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent code update accidentally removed the ability to translate the "Save current search" option in the filters dropdown. This fix restores translation support for this feature, ensuring users in different languages can see this option in their preferred language.
Original PR description
Due to a refactor of the code in [1], the string "Save current search" in the filters dropdown was not translatable anymore. This commit fixes that, so it is translatable again. [1] 976491e01272336bc34abcdcec2718f83e19c5fc --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156915
This fix resolves a validation error that occurred when users tried to close recurring tasks in the Project module. The issue was caused by duplicate follower records being created when generating the next occurrence of a recurring task. The fix prevents this duplication by adjusting how followers are handled during task creation.
Original PR description
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the…
to reproduce: ============= - make a task recureent - change its state to a closing one -> Validation Error Problem: ======== - when creating the next occurence, we insert the followers of the original task in the new one, but it happens that we create a `mail_followers` twice which violates an SQL constraint of `mail_followers`. https://github.com/odoo/odoo/blob/ea170be9089ee6c784664475ac4ec1218d23dccd/addons/mail/models/mail_thread.py#L253-L262 the create method will create `mail_followers` for the task and as the condition that follows is truthy in this use-case `_insert_followers` will be called and create `mail_followers` again. - In previous versions we didn't face this issue because the creation of occurences was done by a cron, so the condition was never truthy thanks to `and self.env.user.active`. Solution: ========= to make sure the conditon stays falsy, we set `mail_create_nosubscribe` in context to `True` when creating the next occurence. opw-3742737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156900 Forward-Port-Of: odoo/odoo#154927
Fixed a bug in the online shop where clicking on a product tag would incorrectly select a product category if they shared the same ID number. The fix ensures each filter element has a unique identifier so customers can properly filter products by tags without unintended category selections.
Original PR description
To reproduce: ============= - create a `product.public.category` -> (id = 15 for example) - create a `product.tag` with same id as the created category - create two products, one with the category…
To reproduce: ============= - create a `product.public.category` -> (id = 15 for example) - create a `product.tag` with same id as the created category - create two products, one with the category and the other with the tag - go to the shop and make sure to have the categories positioned on left (by default they are on top) - select the tag (by clicking on the label not the checkbox) -> the category is selected Problem: ======== with this configuration the checkbox of the category has `id=15` attribute and the tag has `id=15` attribute too. so when we click on the tag label and thanks to the `for=15` attribute of the label, we will trigger click event on `input#15` which is the category checkbox because it's the first one in the DOM. Solution: ========= set id of the tag to `tag_15` and the for attribute of the label to `tag_15` to avoid the conflict with the category checkbox. opw-3759654 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156940
This update includes several important fixes and improvements across Odoo's core modules. Key changes address issues with contact widget crashes when handling missing data, improve the user experience in accounting workflows, fix kanban view functionality, and add support for new countries. These updates enhance system stability and usability for end users.
Original PR description
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 fix resolves crashes that occurred when users searched on outdated job listing pages. The system now automatically redirects users from old job URLs to the new ones while preserving their search parameters, ensuring a smooth experience without errors.
Original PR description
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page,…
__Current behavior before commit:__ `/jobs` routes have been modified in [this commit][1]. Old ones are deprecated but are still working for backward compatibility. When searching on this page, search params are now just added at the end of the URL (instead of being part of the path like before). If the URL of the page is a deprecated one, this can create a conflict with the previous way the params were handled and produce an error. __Description of the fix:__ Redirect the user to the new route any time he tries to reach the deprecated ones. Any parameters included in the old URL will be carried over to the new route to maintain expected behavior. If a parameter is provided both in the path and as a kwarg, the kwarg value will take precedence. __Steps to reproduce the issue on runbot:__ 1. Go to `/jobs/country/20` 2. Make a search using the search bar -> Crash opw-3781374 [1]: https://github.com/odoo/odoo/commit/54f246f9c75b8f1ebdc637c6000f3e4773d702d5 Forward-Port-Of: odoo/odoo#156918
This fix resolves an issue where Stripe payment information could cause errors when certain card data fields are missing or empty. The system now properly handles cases where card details aren't provided by Stripe, and also supports alternative payment methods used in Canada. This prevents system crashes when processing certain types of card transactions.
Original PR description
According to stripe documentation, the `card_present` attribute can be nullable, see: https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-card_present https://docs.stripe.com/api/payment_methods/object#payment_method_object-card_present As a consequence, if it is not given, card_present values would be undefined which create a JS traceback when the `brand` attribute is get. It also looks like Canada can give the brand under a different key `interac_present`: https://docs.stripe.com/api/charges/object#charge_object-payment_method_details-interac_present If the `card_present` key is missing, we'll try to read it from there opw-3752751 Forward-Port-Of: odoo/odoo#156009 Forward-Port-Of: odoo/odoo#155702
This update corrects a translation mistake in the French localization module that was introduced in a previous commit. The fix ensures that French language text displays correctly for users in France, improving the accuracy of the system's French interface.
Original PR description
During this commit: https://github.com/odoo/odoo/commit/8bee46f117b1e6822429e8688f70cb27cc237bb4 We have translated the l10n_fr localisation, but we made a mistake on a line. This PR will correct the translation issue Task: 3792865 opw-3754691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a configuration issue in the German accounting localization (SKR03) where fiscal positions for EU business partners with VAT IDs were incorrectly marked as not requiring VAT identification. The fix ensures that when a fiscal position is designated for partners with VAT IDs, the system properly enforces VAT ID requirements during transactions.
Original PR description
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal…
Steps to reproduce: - - Install the l10n_de package - Create and select a german company - Accounting > Configuration > Settings > Fiscal localization - Set: Deutscher Kontenplan SKR03 for the fiscal localization - Accounting > Configuration > Accounting > Fiscal Positions - Click on "Geschäftspartner EU (mit USt-ID)" (this fiscal position translates to "Business partner EU (with VAT ID)". Issue: The `vat_required` field of this fiscal position is False but sould be True as the fiscal position is "(with VAT id)". Cause of the issue: - The `vat_required` field is a Boolean of the account.fiscal.position model without defaut value nor compute method. As such it is interpreted as "False" when unset (just like any unset python boolean). Since the `vat_required` field is not set in the data file of the `l10n_de_skr03` localization for the "Geschäftspartner EU (mit USt-ID)" fiscal position, it will be interpreted as False. Fix: - We update the data file of the fiscal localization to the expected value opw-3721912 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156934 Forward-Port-Of: odoo/odoo#156444
This fix enables keyboard controls (arrow keys and escape) to work immediately when an image gallery slideshow opens, without requiring users to click on navigation arrows first. The change also corrects accessibility labels to improve screen reader compatibility.
Original PR description
When a slideshow opens, the keyboard events don't work right off the bat. You first need to click on one of the arrows before being able to interact with the keyboard, which defeats the purpose. We also correct the attribute `aria-labbelledby` (both wrongly spelled and wrongly used) to `aria-label`. (A [previous commit] already corrected it in 16.0.) Steps to reproduce: - Drop an Images Wall snippet and save. - Click on an image: the slideshow appears. => Pressing left, right or escape doesn't work. - Switch to the next image. => Pressing left, right or escape now works. [previous commit]: https://github.com/odoo/odoo/commit/d36c14e346f1b2ce3c8e4218c3dfaaa2d2a1db4a Forward-Port-Of: odoo/odoo#156889 Forward-Port-Of: odoo/odoo#155724
This update fixes a broken action in the expense management system that was using an outdated filter. The action for approving department expense sheets has been updated to use the new side panel view, ensuring managers can properly access and review expense sheets awaiting approval.
Original PR description
In odoo/odoo#93802 some filters (including submitted) were removed from hr.expense.sheet view in favor of the side panel. Meanwhile, action_hr_expense_sheet_department_to_approve was not adjusted and was still using the removed filter. This commit changes the action to also use panel view. task - 3578235 Forward-Port-Of: odoo/odoo#143759