Daily updates from Odoo
Navigate
Branch
Wednesday, January 29, 2025
111 changes
7 changes
Resolved issues and error corrections
When a user deletes or archives a record opened directly from a URL, Odoo now avoids showing an empty or broken record page. If there is no previous page to return to, the system safely redirects to the default application, reducing errors and confusion.
Original PR description
- open a record with an URL: `/{model}/{id}`;
- delete or archive the record;
Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button.
This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is :
- if a pager exists, display the next record;
- if not, return to the previous controller (the previous action, usually the multi-record view);
The issue here is that we don't have a previous action or a multi-record view.
Now, in this particular case, we will fallback to the default application.
opw-4354129Miscellaneous changes
**Problem**: The cropper buttons are positioned at the end of the page instead of directly under the image being cropped. **Solution**: Remove `position: fixed` from the buttons container, allowing it to be positioned just below the image being cropped/edited. **Steps to Reproduce**: 1. Navigate to Email Marketing > Start from scratch. 2. Add "Blocks" > "Body" > "Columns". 3. Open the cropping tool on the first image. 4. Observe that the cropping buttons appear at the end of the page
Original PR description
**Problem**: The cropper buttons are positioned at the end of the page instead of directly under the image being cropped. **Solution**: Remove `position: fixed` from the buttons container, allowing it to be positioned just below the image being cropped/edited. **Steps to Reproduce**: 1. Navigate to Email Marketing > Start from scratch. 2. Add "Blocks" > "Body" > "Columns". 3. Open the cropping tool on the first image. 4. Observe that the cropping buttons appear at the end of the page, requiring scrolling to access them. opw-4461565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193016
Since render.qweb was replaced by renderToElement, the spam input search crashes if more than one post meets the search. This commit renders a fragment instead of an element to bypass this limitation. Steps to reproduce: - Connect as Admin - Flag 2 posts on the forum ("..." at the bottom of a post > Flag) - Go to the flagged posts in the moderation tools (left bar) - Click on "Filter Tool" - Select the "Text" tab - Type "e" (to select both posts) => Traceback. (No linked task) Forwa
Original PR description
Since render.qweb was replaced by renderToElement, the spam input search crashes if more than one post meets the search. This commit renders a fragment instead of an element to bypass this limitation.
Steps to reproduce:
- Connect as Admin
- Flag 2 posts on the forum ("..." at the bottom of a post > Flag)
- Go to the flagged posts in the moderation tools (left bar)
- Click on "Filter Tool"
- Select the "Text" tab
- Type "e" (to select both posts) => Traceback.
(No linked task)
Forward-Port-Of: odoo/odoo#191389### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug i
Original PR description
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug is the new version of the library which implements a verification method that corresponds to Moroccan ICE numbers and not VAT numbers. ### Solution: Create the method to check the Moroccan VAT numbers. The format is just a number with 8 digits. opw-4447478 Forward-Port-Of: odoo/odoo#194592
Fix the error displayed error. The current code causes a key error. task-no Forward-Port-Of: odoo/odoo#195388
Original PR description
Fix the error displayed error. The current code causes a key error. task-no Forward-Port-Of: odoo/odoo#195388
Versions -------- - 17.0+ Steps ----- 1. Enable Wire Transfer as a payment provider; 2. in eCommerce, add an item to cart; 3. go to checkout; 4. pay via wire transfer. Issue ----- The order reference isn't shown below the "Thank you for your order" message because the payment transaction hasn't been approved yet. Solution -------- Show the order reference regardless of transaction status. opw-3844583 Forward-Port-Of: odoo/odoo#195228
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable Wire Transfer as a payment provider; 2. in eCommerce, add an item to cart; 3. go to checkout; 4. pay via wire transfer. Issue ----- The order reference isn't shown below the "Thank you for your order" message because the payment transaction hasn't been approved yet. Solution -------- Show the order reference regardless of transaction status. opw-3844583 Forward-Port-Of: odoo/odoo#195228
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but no
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but not for partners. Instead it relies on the partner's country_id, which could be empty. Solution -------- When computing the `property_product_pricelist`, add the geoip country to the context. Use this value in the fallback for partners without specific pricelist property set, and without a `country_id`. opw-4398543 Forward-Port-Of: odoo/odoo#194885
19 changes
New functionality added to Odoo
Calendar events can now send reminders through WhatsApp, in addition to existing email and SMS options. Businesses can use WhatsApp templates for attendee reminders and choose whether the event organizer should also be notified.
Original PR description
PURPOSE The purpose of this commit is to introduce a new reminder of WhatsApp type for calendar events. Now the user can send WhatsApp messages as a reminder of calendar events by defining a WhatsApp template for the remainder, similar to the existing functionalities for emails and SMS. SPECIFICATION A new feature is added by this module to send a reminder of calendar events through WhatsApp. The users can create a reminder of WhatsApp type by defining a WhatsApp template that applies to the `calendar.attendee` model. Users can also define whether to send the remainder to the organizer of the calendar event or not by defining the `notify responsible` boolean. Related Upgrade PR: https://github.com/odoo/upgrade/pull/5709 Task-3506616
Enhancements to existing features
Map markers in stock operations can now show summary details for multiple records that share the same location. This helps users quickly understand grouped deliveries or transfers without opening each record individually.
Original PR description
This commit adds support for showing the summary of multiple records in the marker popup in map view, in case multiple records shared the same location via a setting a new attribute called `full_popup`. Previously, the summary was only shown if the marker corresponded to a single record. If multiple records shared the same marker, only the "Navigate" (or "Open") button(s) were shown along with the address if not hidden.
The manufacturing bill of materials overview now uses the standard planning action for simulations. This helps keep planning behavior consistent and easier to maintain for manufacturing users.
Original PR description
Change simulation to use 'button_plan'.
Salary package offers now better check whether a signature template is ready before an offer is sent by email. Users are guided to upload the required PDF when needed, reducing failed or incomplete pre-offer signature requests.
Original PR description
A new related field for `sign_template_id` is needed to control the warning message's visibility and enable or disable the `send_by_email` button. The `Upload a PDF` hyperlink triggers an action for the `sign.template` model with a context that contains `'upload_pdf': True`, ensuring that when a redirection occurs via the hyperlink, a check is performed when the component is mounted, and `requestFile('sign_send_request')` is triggered accordingly.
task-4427308Code cleanup and technical improvements
The online bank synchronization portal code was reorganized to use a newer internal structure. This should not change day-to-day behavior, but it helps maintain the feature more easily going forward.
Miscellaneous changes
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front
Original PR description
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different…
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front of the code (e.g., 04.10 instead of 4.10), presumably because that's what non-service NCM codes look like. Other cities may not require periods. Cities reject invoices with "wrong" NCM codes, so at the moment our service invoice integration doesn't work there. This seems to affect around 25% of cities. Avalara states they cannot translate the codes for us due to the large number of cities involved. So, users will have to figure out the required format of the NCM code from their city hall and edit the NCM codes based on that. In order to do so we make the NCM codes editable for accountants and provide views and menu items. NCM codes are loaded from CSV and are non-updateable (noupdate=False) by default. To avoid changes being overwritten during module updates we turn them updateable in the model's init() (called during module update). In master this can be removed and done in post_init_hook instead, so that it only happens once during module installation. It's not needed to change the post_init_hook here. After module installation the records will be noupdate=False, but init() always runs before l10n_br.ncm.code.csv is reloaded so manual changes will persist. [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm task-4374334 Forward-Port-Of: odoo/enterprise#77805
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise
Original PR description
Steps to reproduce ================== - Install account_accountant,contacts,web_studio - Go to contacts - Open any record - Open studio - Switch to the Accounting notebook - Edit the subview form - Add a smart button => It crashes Cause of the issue ================== The button_box operation is not made to work inside a subview. We should not be able to add buttons inside subviews as they are not displayed outside studio anyways. opw-4379868 Forward-Port-Of: odoo/enterprise#77364 Forward-Port-Of: odoo/enterprise#76297
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_defaul
Original PR description
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_default_role_id' in the context to get our role_id. - however when we have an array of `role_id`, `search_default_` eventually calls `visitField` https://github.com/odoo/odoo/blob/a711818e93fb253d52a8925a9b12540e4d83d798/addons/web/static/src/search/search_arch_parser.js#L132 where we take only the first value of the array. - So I added a domain. opw-4350959 Forward-Port-Of: odoo/enterprise#78026 Forward-Port-Of: odoo/enterprise#77724
The problem right now is that if you use a new UoM, the related Kenya eTIMS code is not in the category view. Also, the error message you get, does not tell there is a problem with the UoM in itself as it is not checked before sending the item to eTIMS. So, we add the code in the UoM category view and provide a message when it is missing. opw-4395902 Forward-Port-Of: odoo/enterprise#77377 Forward-Port-Of: odoo/enterprise#77116
Original PR description
The problem right now is that if you use a new UoM, the related Kenya eTIMS code is not in the category view. Also, the error message you get, does not tell there is a problem with the UoM in itself as it is not checked before sending the item to eTIMS. So, we add the code in the UoM category view and provide a message when it is missing. opw-4395902 Forward-Port-Of: odoo/enterprise#77377 Forward-Port-Of: odoo/enterprise#77116
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-P
Original PR description
Before this commit, we used the size of the first page to determine the size of the canvas for reportlab. This would cause issues if we uploaded a PDF with any subsequent page larger than the first as we would attempt to draw the signature outside the canvas. Example PDF included in the support ticket. This seems to only be an issue with PyPDF2 2.12.1. This commit fixes this issue by setting the height and width of the canvas to the respective maximum for all pages. opw-4293390 Forward-Port-Of: odoo/enterprise#76618 Forward-Port-Of: odoo/enterprise#76072
Steps to reproduce the bug: - Create a storable product "P1" with a BoM. - Go to ECO stage > In Progress > add two approvals: - approval 1: Mitchel admin + Marc Demo - approval 2: Mitchel admin + Marc Demo - Navigate to PLM > BoM Update and create a new ECO: - Create a new ECO: - Type: BoM Update - Apply On: BoM - Product P1 - Start the revision - Move the ECO to In Progress. Problem: A validation error occurs: “The operation cannot be completed: Error
Original PR description
Steps to reproduce the bug:
- Create a storable product "P1" with a BoM.
- Go to ECO stage > In Progress > add two approvals:
- approval 1: Mitchel admin + Marc Demo
- approval 2: Mitchel admin + Marc Demo
- Navigate to PLM > BoM Update and create a new ECO:
- Create a new ECO:
- Type: BoM Update
- Apply On: BoM
- Product P1
- Start the revision
- Move the ECO to In Progress.
Problem:
A validation error occurs:
“The operation cannot be completed: Error, a partner cannot follow twice the same object.”
opw-4421352
Forward-Port-Of: odoo/enterprise#77950
Forward-Port-Of: odoo/enterprise#76232This error occurs when clicking the ``Send to eTIMS`` button because the move lines lack a product name. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module > Switch to ``KE Company`` - Create a NEW Vendors Bill > Add a Product and remove the product name > Save - Click ``Send to eTIMS`` Traceback: --- ``ZeroDivisionError: float division by zero`` At [1], we encounter ``product = False`` because, at [2], the ``product_id`` is being retrieved from the move lines, but no p
Original PR description
This error occurs when clicking the ``Send to eTIMS`` button because the move lines lack a product name. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module > Switch to ``KE Company`` - Create a NEW Vendors Bill > Add a Product and remove the product name > Save - Click ``Send to eTIMS`` Traceback: --- ``ZeroDivisionError: float division by zero`` At [1], we encounter ``product = False`` because, at [2], the ``product_id`` is being retrieved from the move lines, but no product name is present in the move lines. After this commit, we will ensure that valid values are present in product lines; otherwise, an warning will be raised. [1] - https://github.com/odoo/enterprise/blob/4832c81b89f8831d5a06671ee9c06ac06973b7b5/l10n_ke_edi_oscu/models/account_move.py#L265 [2]- https://github.com/odoo/enterprise/blob/4832c81b89f8831d5a06671ee9c06ac06973b7b5/l10n_ke_edi_oscu/models/account_move.py#L240 sentry-6242406302 Forward-Port-Of: odoo/enterprise#77750
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Original PR description
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by add
Original PR description
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by adding country id in searching state so we always get state based on country. [1] - https://github.com/odoo/enterprise/blob/f3957dc33d956f55b77520167fc9b8ce9dad8c43/account_invoice_extract/models/account_invoice.py#L574 Sentry-6130462157 Forward-Port-Of: odoo/enterprise#77166
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
Original PR description
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Original PR description
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Since odoo/enterprise#75709, the 'Payment Policy' field is always visible on move form view, including for non-MX companies (multi company context). This commit make it visible only when needed for EDI. Forward-Port-Of: odoo/enterprise#77659
Original PR description
Since odoo/enterprise#75709, the 'Payment Policy' field is always visible on move form view, including for non-MX companies (multi company context). This commit make it visible only when needed for EDI. Forward-Port-Of: odoo/enterprise#77659
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long and quite thorough research what was discovered are the following: - this issue happens only once the `website` module has been installed - the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load. - the "blur" event triggered by the `text_
Original PR description
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long…
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name.
After very long and quite thorough research what was discovered are the following:
- this issue happens only once the `website` module has been installed
- the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load.
- the "blur" event triggered by the `text_run ...` tour's command never reaches the `t-on-blur` OWL's handler, while no listener that may have "eaten" the event has been found...
- making the "blur" event bubble (which is not its normal behavior) does have some impact on the issue...
- running the tour directly from the backend (e.g. `start_tour("/web", ...)` doesn't present this issue.
While the exact root cause of this issue hasn't been identified so fare, this commit sets the tour to be run directly from the backend (which makes sense as it is a backend-only test tour anyway) as a workaround.
Note: while being an issue in automated test, the feature operated by an actual user looks to be working properly.
Forward-Port-Of: odoo/enterprise#77823Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182 Forward-Port-Of: odoo/enterprise#78052 Forward-Port-Of: odoo/enterprise#77355
Original PR description
Before this commit their was a little undeterminism in a tour. Adding a bit of delay within a step should do the trick. runbot-error-112182 Forward-Port-Of: odoo/enterprise#78052 Forward-Port-Of: odoo/enterprise#77355
74 changes
New functionality added to Odoo
This update adds Mexican CFDI electronic payroll XML generation for individual payslips, helping businesses meet local payroll reporting requirements. It makes payroll documents more complete and compliant for companies operating in Mexico.
Original PR description
This adds the CFDI xml on individual payslips. Task: 4299196
Enhancements to existing features
Accounting users can now enter several account prefixes in a single analytic plan line, such as 51, 61, and 71 together. This makes analytic plan setup faster and easier to maintain when the same rules apply to multiple account ranges.
Original PR description
This commit allows the user to put multiple accounts prefix on a single analytic plan line. So, if the user want to add the accounts 51000, 61000 and 71000, he can now add this: 51, 61, 71 in the same line. task-4294662
Users can now use “child of” and “parent of” hierarchy filters more easily in the domain selector when the selected relationship field supports them. The selector also supports choosing multiple records for these filters, making it faster to build accurate hierarchical searches.
Original PR description
First commit introduces the allow_hierachy_operators description on relational fields while second commit allows to use the hierarchical operators (child_of/parent_of) on these fields inside the domain selector while also allowing multiselection with these operators. task-4492974
This update makes small visual refinements across Odoo Discuss, live chat, and messaging elements so key content is easier to focus on. It improves spacing, contrast, badge sizing, hover states, and dark-theme readability for a cleaner day-to-day communication experience.
Ecuadorian localization now supports creating purchase withholding documents when companies distribute dividends to shareholders from a closed fiscal period. This helps businesses meet local electronic reporting and tax withholding requirements for dividend payments more consistently.
Original PR description
Implement dividens in purchase withholdings. When a company pays its shareholders some profits from the closed fiscal period, there is also a Purchase WTH needs to be created. task: 865
Resolved issues and error corrections
Users can now download original PDF bills attached to newly created draft vendor bills without encountering an error. The fix ensures draft bill records are handled correctly when preparing the download, restoring a standard accounting workflow.
Original PR description
Users currently cannot retrieve original bills attached to newly created draft moves, because an error is blocking the action Steps to reproduce: - Go to Accounting > Vendor > Bills - Upload a pdf - Back in list view, select the created bill, Download > Original Bills Issue: Traceback will raise `AttributeError: 'bool' object has no attribute 'decode'` This occurs because, after https://github.com/odoo/odoo/commit/ce73ed61bcf293953bc0c821ceaef3ddb9a47e3c, draft moves are not named '/' anymore, the name field will be just `False`. However reportlab expects a string and it crashes opw-4502791
The web tour test suite has been re-enabled after being temporarily disabled to unblock an earlier release process. This helps improve confidence that guided tour behavior continues to work correctly, while avoiding an issue that interfered with the test engine.
Original PR description
In [1], we commented out the tour_automatic unit test file in the manifest to merge this PR as soon as possible. In this commit, we uncomment this file. The solution is to not patch browser.console because it can cause big problems in the Hoot unit test engine.
This fix prevents an internal error from occurring when Odoo tries to show a company-related warning. The warning can now be logged correctly, improving reliability in situations where company consistency checks are triggered.
Original PR description
Description of the issue/feature this PR addresses: In the company check warning message, self.model_name was used instead of self._name. Current behavior before PR: model_name is not an attribute of the class BaseModel, which causes an AttributeError when the warning message is triggered. Desired behavior after PR is merged: Warning message correctly logged without having an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a problem where pressing Escape while editing a form in a dialog could cause an error instead of closing cleanly. It improves reliability when users cancel edits, especially in areas like Studio and other popup form views.
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 fixes an issue where invoice identifiers could appear repeatedly in accounting report line names when the same sequence was used as both customer and payment reference. The report now avoids duplicate wording, making entries easier to read and reducing confusion for accounting users.
Original PR description
### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry" - On the Journal Entry,…
### Steps to reproduce:
- Go to Accounting > Reports > Aged Receivable
- Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry"
- On the Journal Entry, add the invoice sequence to Customer Reference and Payment Reference
- Go back to the report, you should see the invoice name is now shown 4 times
### Cause:
The bug appeared in this commit (https://github.com/odoo/odoo/commit/eb872c09897eb9edd5b6e5b9e8171fa6764be3dc). When computing the line `display_name`, if there is a name, a reference and `line_name`. The variable line_name already include the reference:
`name = f'{line.move_id.ref} - {line.move_id.payment_reference}'` (https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7)
So `line_name` is different from `move_name` and the result is:
`line.move_id.name (line.move_id.ref) line.move_id.ref - line.move_id.payment_reference`
### Solution:
Check if the move_ref and the payment ref are the same, in that case only put one of the two as line_name. Then when computing the display_name, line_name will equal to move_name so line_name will not be included.
opw-4492298This fixes an issue where the user switch option could disappear on the login page when debug mode was enabled. Users can now switch between recently used accounts reliably while troubleshooting or testing.
Original PR description
**Description of the issue/feature this PR addresses:** The user switch component fails in debug mode with the following error in the console log > Error message: > OwlError: Got duplicate key in t-foreach: [object Object] > at UserSwitch.template This error happens because we are using the user object as a key ([object Object]), instead we should use the user_index **Current behavior before PR:** 1. Open a runbot 2. Log in and log out with admin account 3. Log in and log out with demo account 4. The user switch component appears on the login page 5. Adding ?debug=1 to the URL causes: - User switch component disappears - Console shows duplicate key error **Desired behavior after PR is merged:** - Having possibility to use switch user component in debug mode --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The autocomplete dropdown now keeps the highlighted option visible when users move through long lists with the keyboard. It also closes consistently when tabbing backward, making form navigation more predictable and reducing user frustration.
Original PR description
When the list of sources is longer than the `<AutoComplete>` height, navigating with the arrow keys did not scroll the menu. This commit makes sure the active option is always in focus and visible. task-3758859
This fixes an issue where employees on flexible working schedules could have a one-day time off request counted as two days. The change ensures leave duration is calculated from the actual requested date range, helping keep balances and approvals accurate.
Original PR description
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an…
### Steps to reproduce: - Create a working schedule that is flexible - Assign this working schedule to an Employee - Create a time off type and set the request unit to be 'half day' - Create an allocation for the created time off type for the employee with the flexible working schedule - Create a leave for the mentioned employee with the created time off type for 1 day - Notice the duration of the leave is 2 days not 1 ### Cause: When creating a working schedule we compute the duration of the periods and since 'attendance.calendar_id.hours_per_day' won't have a value each period will be 1 day. https://github.com/odoo/odoo/blob/18.0/addons/resource/models/resource_calendar_attendance.py#L82 So, when getting the duration of the leave where its request_unit is not 'day' the duration will be the summation of the periods' duration of the working schedule for the employee which in this case will be 1 for each period -each day has 2 periods with the value of 1- ### Fix: Check if the employee if on flexible hours we calcualte the duration as the difference between the date_to and date_from rounded up in days opw-4309551
This fixes an issue in Point of Sale where product stock could be shown incorrectly when a cashier changed product options during configuration. The update reduces duplicate stock checks and ensures the displayed on-hand quantity matches the selected product variant, helping staff make more accurate sales decisions.
Original PR description
Before this commit, multiple requests were sent when the user changed options in the product configuration. Additionally, the on-hand quantity was displayed incorrectly when opening the product configuration. When opening the configuration popup, the product was initially set. However, once the configuration was mounted, the selected attributes could result in a different product variant. We call `computeProductProduct` to update the product. The issue occurred because, while the first request was still in progress, a second request was triggered to fetch the correct product information. Since the first request was not yet finished, the second request was ignored, causing the configuration to display an incorrect on-hand quantity for the selected product variant. opw-4385171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor no longer shows an unnecessary help tooltip beside the option to serve custom fonts from Google servers. This reduces confusion for internal users configuring website fonts, without changing any website behavior.
Original PR description
Steps to reproduce: 1. Open website app 2. Click edit 3. Click on "Font Family" 4. Click on "Add a Custom Font" 5. Click on the question mark tooltip showing next to "Serve font from Google servers" - Removed the tooltip since the form is only accessible internally and not relevant to all users. This was only added in v18+ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings Odoo's spreadsheet engine to a newer maintenance version with fixes for spreadsheet sessions, Excel import/export validation ranges, and chart trendlines. Business users should see more reliable spreadsheet behavior, especially when working with XLSX files and logarithmic chart trends.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/a881cffac [REL] 18.0.12 Task: 0 https://github.com/odoo/o-spreadsheet/commit/79731b80f [FIX] session: useless snapshot on leave Task: 4356913 https://github.com/odoo/o-spreadsheet/commit/e8ae60230 [FIX] xlsx: fix data validation range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/b52dbde23 [REF] range: rename useFixedReference Task: 4506120 https://github.com/odoo/o-spreadsheet/commit/179614731 [FIX] xlsx: export data validation with unbounded range Task: 4505771 https://github.com/odoo/o-spreadsheet/commit/74263151a [FIX] charts: fix logarithmic dataset trendline Task: 4385057 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update prevents a Point of Sale crash that could happen when missing information was processed. It makes checkout-related data handling more reliable and helps avoid interruptions for users.
Original PR description
The error was caused by calling .trim() on a variable that could be undefined. This commit adds a check to ensure the variable is defined before calling .trim()
This fix keeps XML files from being selected as the main attachment for vendor bills when Italian localization is installed. It prevents unreadable files from being produced when users print original bills, preserving the expected PDF output.
Original PR description
**Issue:** When "l10n_it" is installed, an override of "_message_set_main_attachment_id" method is changing the default value of "filter_xml" param from True to False, which is impacting the general behavior when the module is installed. As a consequence, xml files can be set as main attachment of a bill, which generates unreadable PDF files when using "Print > Original Bills" action on a bill. opw-4439034 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The product configuration screen now respects the same editor setting that hides or shows the quantity selector on product pages. This keeps the shopping experience consistent and prevents customers from seeing a quantity button that the business intended to hide.
Original PR description
version: 18.0 Issue : When the "Select Quantity" button is hidden on the product page via the editor, it remains visible on the product configuration page. Fix: Added a condition for showQuantity to ensure the visibility of the "Select Quantity" button is consistently managed on both the product page and the product configuration page. With this fix, the visibility of the "Select Quantity" button can now be properly controlled for the product configuration page as well, aligning with the editor's settings. opw-4316784
This fixes a problem where partner autocomplete could fail during company onboarding because a required identifier was missing from the relevant company form. It also avoids problems when the autocomplete feature is later uninstalled, keeping the setup more reliable for businesses using or removing this option.
Original PR description
`partner_gid` was missing from `res_company_form_view_onboarding` view which was creating a bug when applying the partner autocomplete. Rollback of odoo/195000 as it created issues if you uninstalled `partner_autocomplete`. The field will still be present in the view, but it wouldn't exist in the database. opw-4489441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now open IAP accounts even after the SMS module has been uninstalled. This prevents an unexpected error caused by SMS-specific account data remaining after the module is removed.
Original PR description
A traceback occurs when the user tries to open IAP accounts after uninstalling the SMS module. To reproduce: 1) Install hr 2) open IAP accounts from settings/technical/iap/iap accounts 3) Create a…
A traceback occurs when the user tries to open IAP accounts after uninstalling the SMS module. To reproduce: 1) Install hr 2) open IAP accounts from settings/technical/iap/iap accounts 3) Create a new iap account with service as `SMS` 4) Uninstall `SMS` module 5) Try to open the iap accounts again Error:- ``` ValueError: Invalid field 'sender_name' in 'iap.account' ``` This error occurs from the below line https://github.com/odoo/odoo/blob/1e7c2ca8c929d15c9015b960f7fcbe4560413e98/addons/iap/models/iap_account.py#L128 Because when the user creates an iap account with service_name as `SMS`, We include `sender_name` in the dict of updating fields. https://github.com/odoo/odoo/blob/1e7c2ca8c929d15c9015b960f7fcbe4560413e98/addons/iap/models/iap_account.py#L123-L126 But, the `sender_name` field is defined in the SMS module, So it will lead to the above traceback as the `SMS` module is uninstalled. https://github.com/odoo/odoo/blob/1e7c2ca8c929d15c9015b960f7fcbe4560413e98/addons/sms/models/iap_account.py#L9 sentry-6249864173
Brazilian electronic invoices now send the invoice line description instead of only the product name, letting businesses include the extra detail they entered for each line. The fix also prevents service transaction errors from being incorrectly cleared, improving reliability for Brazilian AvaTax electronic invoicing.
Original PR description
We always send the product name, but sometimes users want to add more information to the electronic invoice. It makes more sense to send the line description (account.move.line's name field) instead. That allows the user to specify what they want and also aligns better with what the API expects (their field is called "description", not "productName"). To avoid changing function signatures in stable we override _l10n_br_build_avatax_line and browse the account.move.line using line_id. In master we'll clean it up by providing "description" directly in _get_line_data_for_external_taxes() for both account.move and sale.order. This also fixes a mistake that cleared errors for service transactions (introduced in the merge of l10n_br_avatax_services [1]). [1] https://github.com/odoo/enterprise/pull/64714 task-4401787
Accountants can now edit Brazilian NCM codes used for service invoices so they match the format required by each city. This helps prevent invoice rejections in cities whose local tax systems expect different code formats, such as leading zeros or no periods.
Original PR description
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different…
Goods invoices go through a central, federal API. Service invoices however, go through an API maintained by the city the business is located in. Because of this, there are thousands of different APIs. Avatax sits between us and those city APIs, but certain differences are not handled by them. The most blocking is the format of the NCM code. We based our NCM codes on the official law [1], but unfortunately the required format differs between cities. Some cities require a leading zero in front of the code (e.g., 04.10 instead of 4.10), presumably because that's what non-service NCM codes look like. Other cities may not require periods. Cities reject invoices with "wrong" NCM codes, so at the moment our service invoice integration doesn't work there. This seems to affect around 25% of cities. Avalara states they cannot translate the codes for us due to the large number of cities involved. So, users will have to figure out the required format of the NCM code from their city hall and edit the NCM codes based on that. In order to do so we make the NCM codes editable for accountants and provide views and menu items. NCM codes are loaded from CSV and are non-updateable (noupdate=False) by default. To avoid changes being overwritten during module updates we turn them updateable in the model's init() (called during module update). In master this can be removed and done in post_init_hook instead, so that it only happens once during module installation. It's not needed to change the post_init_hook here. After module installation the records will be noupdate=False, but init() always runs before l10n_br.ncm.code.csv is reloaded so manual changes will persist. [1] https://www.planalto.gov.br/ccivil_03/leis/lcp/lcp116.htm task-4374334
The scheduled payment status check now runs only when there are payments that actually need checking. This reduces unnecessary background activity and helps keep online payment processing more efficient without changing the user experience.
Original PR description
The aim of this commit is making sure cron that runs every 6 hours and which checks all the payment status is only used when we do have payment that needs to be checked. no task id
This fixes a missing return in the Chilean electronic invoicing point-of-sale flow. It helps ensure POS order data is passed back correctly, reducing the risk of interrupted or incomplete processing for Chilean sales receipts.
Original PR description
The return was forgotten in a previous commit for an override of the `read_pos_data` method in the `pos_order` model.
The EU OSS reports now show the closing entry button again in version 18.0. This lets users complete closing entries directly from the report because the underlying closing process is expected to work correctly again.
Original PR description
From version 18.0, the closing should work fine and there's no need to hide the closing button anymore. This reverts commit cf86ce0e0c7c47336446da5b335cbc53b7602fcd.
Uploading large images to Documents no longer automatically shrinks them. This preserves the original file quality and avoids unexpected changes to images stored by users.
Original PR description
Bug === When uploading a big image in documents, it's resized. It has been fixed in 17.4 with `Task-3944609`, but we re-introduced the issue during the refactor of documents. Task-4505777
This update hides certain Shopee-related fields unless debug mode is enabled, reducing clutter and preventing accidental changes in normal use. It also lets users manually choose which products should have their inventory synced, improving control over stock updates.
Original PR description
Commit 6845ca19567577f70910ed269f91232453c93b20 let some fields visible in the view where they should only be available in debug mode. Also allows to manually change which product should have its inventory synced.
Miscellaneous changes
Issue: If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records. This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset. Fix: We fix this by forcing active_test=False before calling search a
Original PR description
Issue:
If we have a X2many that allows to have inactive records (with `context={'active_test': False}` on the field definition) and we specify a specific order for this X2many in this view, web_read won't respect the context of the field and will filter out inactive records.
This is because to apply a specific order in the web_read, we use search(), which will filter out inactive records from the `corecords` recordset.
Fix:
We fix this by forcing active_test=False before calling search and reapplying the previous context immediately after.
Closes #194311
Forward-Port-Of: odoo/odoo#195297
Forward-Port-Of: odoo/odoo#194379### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons - **Validity**: Today's date for example - Conditional rule with a **Minimum Purchase** of 0.00 - Start a new POS session. Add a product and click **Payment**. - **Validate** the order. - In the receipt shown, notice how the text show **_'Valid until: no expiration'_** althoug
Original PR description
### Steps to reproduce: - Install **pos_loyalty** module - Go to **Point of Sale** app > **Products** > **Discount & Loyalty** - Create a **New** program with: - **Program Type**: Next Order Coupons…
### Steps to reproduce:
- Install **pos_loyalty** module
- Go to **Point of Sale** app > **Products** > **Discount & Loyalty**
- Create a **New** program with:
- **Program Type**: Next Order Coupons
- **Validity**: Today's date for example
- Conditional rule with a **Minimum Purchase** of 0.00
- Start a new POS session. Add a product and click **Payment**.
- **Validate** the order.
- In the receipt shown, notice how the text show **_'Valid until: no expiration'_** although a Validity date is defined!
### Investigation:
- In `confirm_coupon_programs`, `coupon_create_vals` lacks `expiration_date` https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/models/pos_order.py#L72-L78
- To add the `expiration_date`, `date_to` has to be in `coupon_data` but it's not included.
- `coupon_data` comes from https://github.com/odoo/odoo/blob/03856863a644fbc588edb6e63168a6c4e15d5d92/addons/pos_loyalty/static/src/js/PaymentScreen.js#L78
opw-3838427
Forward-Port-Of: odoo/odoo#183036
Forward-Port-Of: odoo/odoo#160633Versions -------- - 17.0+ Steps ----- 1. Enable Wire Transfer as a payment provider; 2. in eCommerce, add an item to cart; 3. go to checkout; 4. pay via wire transfer. Issue ----- The order reference isn't shown below the "Thank you for your order" message because the payment transaction hasn't been approved yet. Solution -------- Show the order reference regardless of transaction status. opw-3844583 Forward-Port-Of: odoo/odoo#195228
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable Wire Transfer as a payment provider; 2. in eCommerce, add an item to cart; 3. go to checkout; 4. pay via wire transfer. Issue ----- The order reference isn't shown below the "Thank you for your order" message because the payment transaction hasn't been approved yet. Solution -------- Show the order reference regardless of transaction status. opw-3844583 Forward-Port-Of: odoo/odoo#195228
**Problem**: The cropper buttons are positioned at the end of the page instead of directly under the image being cropped. **Solution**: Remove `position: fixed` from the buttons container, allowing it to be positioned just below the image being cropped/edited. **Steps to Reproduce**: 1. Navigate to Email Marketing > Start from scratch. 2. Add "Blocks" > "Body" > "Columns". 3. Open the cropping tool on the first image. 4. Observe that the cropping buttons appear at the end of the page
Original PR description
**Problem**: The cropper buttons are positioned at the end of the page instead of directly under the image being cropped. **Solution**: Remove `position: fixed` from the buttons container, allowing it to be positioned just below the image being cropped/edited. **Steps to Reproduce**: 1. Navigate to Email Marketing > Start from scratch. 2. Add "Blocks" > "Body" > "Columns". 3. Open the cropping tool on the first image. 4. Observe that the cropping buttons appear at the end of the page, requiring scrolling to access them. opw-4461565 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193016
Fix the error displayed error. The current code causes a key error. task-no Forward-Port-Of: odoo/odoo#195388
Original PR description
Fix the error displayed error. The current code causes a key error. task-no Forward-Port-Of: odoo/odoo#195388
This commit add support for comprenhension expression on assign node Forward-Port-Of: odoo/odoo#194878
Original PR description
This commit add support for comprenhension expression on assign node Forward-Port-Of: odoo/odoo#194878
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug i
Original PR description
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug is the new version of the library which implements a verification method that corresponds to Moroccan ICE numbers and not VAT numbers. ### Solution: Create the method to check the Moroccan VAT numbers. The format is just a number with 8 digits. opw-4447478 Forward-Port-Of: odoo/odoo#194592
Since render.qweb was replaced by renderToElement, the spam input search crashes if more than one post meets the search. This commit renders a fragment instead of an element to bypass this limitation. Steps to reproduce: - Connect as Admin - Flag 2 posts on the forum ("..." at the bottom of a post > Flag) - Go to the flagged posts in the moderation tools (left bar) - Click on "Filter Tool" - Select the "Text" tab - Type "e" (to select both posts) => Traceback. (No linked task) Forwa
Original PR description
Since render.qweb was replaced by renderToElement, the spam input search crashes if more than one post meets the search. This commit renders a fragment instead of an element to bypass this limitation.
Steps to reproduce:
- Connect as Admin
- Flag 2 posts on the forum ("..." at the bottom of a post > Flag)
- Go to the flagged posts in the moderation tools (left bar)
- Click on "Filter Tool"
- Select the "Text" tab
- Type "e" (to select both posts) => Traceback.
(No linked task)
Forward-Port-Of: odoo/odoo#191389Description of the issue this PR addresses: Pressing enter in the `s_popup` snippet after making it visible via the right panel would hide the popup. This occurred because the mutation observer detected changes which shows the modal and rolled them back during the `insertLineBreak` operation. This commit ensures that those mutations are not observed. task-4255083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194696
Original PR description
Description of the issue this PR addresses: Pressing enter in the `s_popup` snippet after making it visible via the right panel would hide the popup. This occurred because the mutation observer detected changes which shows the modal and rolled them back during the `insertLineBreak` operation. This commit ensures that those mutations are not observed. task-4255083 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194696 Forward-Port-Of: odoo/odoo#191810
### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behav
Original PR description
### Description of the issue/feature this PR addresses: When a product is configured with both buy and manufacture routes, the manufacture route is always prioritized, regardless of the sequence defined in the routes. ### Current behavior before PR: The method extract_rule stops evaluating routes once it finds a valid rule, even if other rules with a lower sequence exist. This leads to the manufacture route being prioritized over buy, which is not the intended behavior. ### Desired behavior after PR is merged: The routes are now evaluated based on their sequence, ensuring that rules associated with routes of lower sequence are considered first. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr cc @ForgeFlow Forward-Port-Of: odoo/odoo#194922 Forward-Port-Of: odoo/odoo#188846
**Problem**: When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - A
Original PR description
**Problem**: When an image inside a `<p>` tag (e.g., `<p><img></p>`) is deleted using the toolbar delete button, the selection is not properly restored, leaving an empty `<p>` in the DOM and the selection in the editor root. **Solution**: Restore the selection to the correct position after deleting the image to avoid leaving an empty `<p>`. **Steps to Reproduce**: 1. Open an empty editor and add an image. 2. Delete the image using the toolbar delete button. 3. Inspect the DOM: - An empty `<p>` remains, and the selection is in the editor root. opw-4472173 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194882 Forward-Port-Of: odoo/odoo#193396
Steps ----- 1. Add an item to the cart (ensure the total price has decimals). 2. During checkout, apply a coupon (e.g., a 50% discount). 3. Attempt to validate the payment. Issue ----- The frontend user encounters the following error: "Cannot process payment: applied reward was changed or has expired." Cause ----- In some cases, the comparison between initial_amount and the new amount_total fails due to a small decimal difference (e.g., 0.00002). Solution -------- Use the f
Original PR description
Steps ----- 1. Add an item to the cart (ensure the total price has decimals). 2. During checkout, apply a coupon (e.g., a 50% discount). 3. Attempt to validate the payment. Issue ----- The frontend user encounters the following error: "Cannot process payment: applied reward was changed or has expired." Cause ----- In some cases, the comparison between initial_amount and the new amount_total fails due to a small decimal difference (e.g., 0.00002). Solution -------- Use the float_compare function to handle precise rounding. 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#195340 Forward-Port-Of: odoo/odoo#195266
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represe
Original PR description
## Versions: 17.0+ No fix needed in 16.0 as the discount was not displayed this way. ## Issue: Discount descriptions contain long string floats while it should be truncated for human reading. ## Steps to reproduce: - Activate `Discounts` through settings; - Create a new sale order for any client with at least 1 product; - Click the `Discount` button on the form; - Apply a 7% `Global Discount`; - Read the `Discount` product's description. ## Cause: Some numbers cannot be represented correctly in Python (including 7, 3.3 etc.). opw-4485316 Forward-Port-Of: odoo/odoo#195328
[FIX] web_editor: adapt `border-style` value based on border widths **Problem**: Outlook always displays the border of an element if `border-style` is set to `solid`, even when all border widths are 0. **Solution**: Change `border-style` to `none` if all border widths are 0. **Steps to Reproduce**: 1. Open the "Event: Registration Confirmation" email template in the web editor. 2. Add a character and save the template. 3. Check the saved `body_html`. -> All t
Original PR description
[FIX] web_editor: adapt `border-style` value based on border widths
**Problem**:
Outlook always displays the border of an element if `border-style` is set
to `solid`, even when all border widths are 0.
**Solution**:
Change `border-style` to `none` if all border widths are 0.
**Steps to Reproduce**:
1. Open the "Event: Registration Confirmation" email template in the web editor.
2. Add a character and save the template.
3. Check the saved `body_html`.
-> All table elements will have `border-style: solid;` added as inline styling,
causing borders to appear in Outlook.
opw-4211794
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195282
Forward-Port-Of: odoo/odoo#193973This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link, resolving the issue of an empty link being added. task-2819776 Forward-Port-Of: odoo/odoo#195270 Forward-Port-Of: odoo/odoo#162615
Original PR description
This PR addresses an issue where selecting a video and pressing Ctrl+K would introduce a link(anchor tag) on top of the video. The fix ensures that pressing Ctrl+K while a video is focused will no longer insert a link, resolving the issue of an empty link being added. task-2819776 Forward-Port-Of: odoo/odoo#195270 Forward-Port-Of: odoo/odoo#162615
Since the update of FullCalendar some styling was not properly applied. Which leads to the following issues: - Missing borders - Cropped text in month views - Double borders task-3833841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191056
Original PR description
Since the update of FullCalendar some styling was not properly applied. Which leads to the following issues: - Missing borders - Cropped text in month views - Double borders task-3833841 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191056
### Issue: - The negative values in Vendor Bills are not being reflected in the Analytic Account linked to a project. - the negative value does not reduce the project’s total cost in the Analytic Report cost calculations. ### Steps to reproduce: 1- Create a project and set an analytic account or use the "Renovations" project. 2- Create a vendor bill. 3- On the VB add two lines one with a positive Price and the other with a negative Price. 4- on `Analytic` of each line set the projec
Original PR description
### Issue: - The negative values in Vendor Bills are not being reflected in the Analytic Account linked to a project. - the negative value does not reduce the project’s total cost in the Analytic…
### Issue:
- The negative values in Vendor Bills are not being reflected in the Analytic Account linked to a project.
- the negative value does not reduce the project’s total cost in the Analytic Report cost calculations.
### Steps to reproduce:
1- Create a project and set an analytic account or use the "Renovations" project.
2- Create a vendor bill.
3- On the VB add two lines one with a positive Price and the other with a negative Price.
4- on `Analytic` of each line set the project to `Renovations` or the project you created.
5- Validate the vendor bill.
6- Go to the project app and click on the 3 dots of the project you choose and click on `Project Updates`.
7- Notice the total cost of the project is not reflecting the negative value of the vendor bill.
### Solution:
- The issue is caused by the condition ('price_subtotal', '>', 0) in the query for account.move.line.
- Removing this condition ensures both positive and negative price_subtotal values are included.
opw-[4416931](https://www.odoo.com/web#id=4416931&view_type=form&model=project.task)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194960
Forward-Port-Of: odoo/odoo#194300### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the is
Original PR description
### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for…
### Steps to reproduce: - Create a product tracked by LOT (not SN) - Create a BOM for that product and a BOM line with a tracked product - Put a an SN for your component in STOCK. - Create an MO for 1 unit of your product and confirm. > The SN should be set on your component line. - Set an LOT on the finished product with the create option but without clicking on the [+] #### > The quantity of the component line was updated to 0 and the SN of the comp was removed. ### Cause of the issue: Changing the lot on the MO form will trigger the `_onchange_producing` which will in turn `_set_qty_producing`: https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L797-L799 In case the product is tracked by SN this `_set_qty_producing` will set a qty_producing of 1 and the move raws will reserve a quantity accordingly but if the product is tracked by lot or not tracked at all the quantities of the move raw will just be adapted to match the `qty_producing` (that was at 0 from the start): https://github.com/odoo/odoo/blob/83445d91a588958417fef8a04d1187974d4b3d9a/addons/mrp/models/mrp_production.py#L1217-L1227 opw-4418809 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194847 Forward-Port-Of: odoo/odoo#192932
Issue ----- When selecting a variant for the bom, all of the component lines lose the "Apply on variants" info. This is intended behaviour but can lead to big data losses for larger boms. Discussed it with PO and we went with a simple user warning when this happens. Steps to reproduce ----- - Create product "A" with variant "A1" and product "B" - Create a bom for A - Create a bom line with "Apply on variants" set to A1 - Save the bom - Change the bom product from A to B - Save the
Original PR description
Issue ----- When selecting a variant for the bom, all of the component lines lose the "Apply on variants" info. This is intended behaviour but can lead to big data losses for larger boms. Discussed it with PO and we went with a simple user warning when this happens. Steps to reproduce ----- - Create product "A" with variant "A1" and product "B" - Create a bom for A - Create a bom line with "Apply on variants" set to A1 - Save the bom - Change the bom product from A to B - Save the bom / Leave the page Ticket: opw-4182384 Forward-Port-Of: odoo/odoo#191541
Due to the sync being broken the past 2 weeks, manually pull the Greek translations since translations have been added to it recently. 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
Original PR description
Due to the sync being broken the past 2 weeks, manually pull the Greek translations since translations have been added to it recently. 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
Description of the issue/feature this PR addresses: Task ID: 4342267 Current behavior before PR: -Error When printing draft invoice due to unset invoice_date. -Report spacing between header & body in second page overlaps due to paperformat spacing. Due to the long address format of saudi arabia, the default paperformat header spacing and margin top are not enough to show the full address without overlapping the second and onward pages. -English labels on the exchange rate table in l1
Original PR description
Description of the issue/feature this PR addresses: Task ID: 4342267 Current behavior before PR: -Error When printing draft invoice due to unset invoice_date. -Report spacing between header & body in…
Description of the issue/feature this PR addresses: Task ID: 4342267 Current behavior before PR: -Error When printing draft invoice due to unset invoice_date. -Report spacing between header & body in second page overlaps due to paperformat spacing. Due to the long address format of saudi arabia, the default paperformat header spacing and margin top are not enough to show the full address without overlapping the second and onward pages. -English labels on the exchange rate table in l10n_sa_edi are translated and not shown together with the arabic labels. -Remove unnecessary spans in xpaths Desired behavior after PR is merged: -Fix printing draft invoice with invoice_date as today's date -Fix report spacing header by adding a new A4 paperformat for l10n_sa which is set as the saudi arabia companies default paper format. -Fix exchange rate table to show both arabic and english labels and remove unnecessary translations (no longer used) -Remove unnecessary spans in xpath. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195034 Forward-Port-Of: odoo/odoo#190172
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have
Original PR description
Description of the issue/feature this PR addresses: The "Recycle" repair type wasn't integrated properly into the report template Current behavior before PR: Repair lines with "Recycle" type create empty lines on the repair order report   Desired behavior after PR is merged: Repair lines with "Recycle" type have their product description printed on the report --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193502
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the recor
Original PR description
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax Group (account.tax.group) Field: Name (name) ``` 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#193013
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce one unit of P1: - Confirm - A child MO with one unit of C1 is created - Update the qty producing of P1 to 2 - A new MO to produce one unit of C1 is created Problem: The MO of P1 is linked only to the last MO of C1. This occurs because the “created_productio
Original PR description
Steps to reproduce the bug: - Create a storable product “C1”: - MTO + Manufacture - BoM: - Component: 1 unit of C2 - Create a storable product “P1” - Component: 1 unit of C1 - Create a MO to produce…
Steps to reproduce the bug:
- Create a storable product “C1”:
- MTO + Manufacture
- BoM:
- Component: 1 unit of C2
- Create a storable product “P1”
- Component: 1 unit of C1
- Create a MO to produce one unit of P1:
- Confirm
- A child MO with one unit of C1 is created
- Update the qty producing of P1 to 2
- A new MO to produce one unit of C1 is created
Problem:
The MO of P1 is linked only to the last MO of C1.
This occurs because the “created_production_id” field in the stock move of C1 (associated with the MO of P1) is updated to reference the most recent MO of C1. Additionally, since the following fix:
https://github.com/odoo/odoo/commit/c5b3f41fbd442def9e97acb023a00862e7d03eb3#diff-6d86bc8c3e9aa22586656b702849c5bbbb00c9b97ffd08bc0842e0e68f8948f9R74
Each new MO has its own procurement group.
As a result, when using the _get_children method:
- The method retrieves stock moves linked to the current procurement group.
- It uses their created_production_id to fetch the associated procurement group and then retrieves the related production_id.
However, since the two child MOs of C1 belong to different procurement groups, only the latest MO is returned.
opw-4450210
Forward-Port-Of: odoo/odoo#194032
Forward-Port-Of: odoo/odoo#192952Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193969 Forward-Port-Of: odoo/odoo#193764
Original PR description
Fixes test broken by: be23ed0 https://runbot.odoo.com/odoo/runbot.build.error/109595 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193969 Forward-Port-Of: odoo/odoo#193764
Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: https://github.com/odoo/odoo/pull/171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 Forward-Port-Of: odoo/odoo#195202 Forward-Port-Of: odoo/odoo#194785
Original PR description
Steps: - Install sale app. - Enable Loyalty settings. - Try to create a card on a loyalty. Issue: - Giving validation error. Casue: - In [PR] forgot to check expiration_date set or not before raise an error. Fix: - Added condition to check if expiration_date set or not on card before raising an error. [PR]: https://github.com/odoo/odoo/pull/171453 opw-4492179 opw-4490587 opw-4504188 opw-4495530 Forward-Port-Of: odoo/odoo#195202 Forward-Port-Of: odoo/odoo#194785
Using a newly created payslip structure for Mexico it is not possible to generate payslips Steps to reproduce: - With an MX Company setup - Go to Payroll > Configuration > Salary > Structures - Create new structure with the following attributes: - Type: "Mexico: employee" - Country: "Mexico" - Go to Payroll > Payslips > Batches, create a new batch - Click "Generate Payslips" - Select the freshly created salary structure in the wizard, then click "Generate" Issue: An error is ra
Original PR description
Using a newly created payslip structure for Mexico it is not possible to generate payslips Steps to reproduce: - With an MX Company setup - Go to Payroll > Configuration > Salary > Structures - Create new structure with the following attributes: - Type: "Mexico: employee" - Country: "Mexico" - Go to Payroll > Payslips > Batches, create a new batch - Click "Generate Payslips" - Select the freshly created salary structure in the wizard, then click "Generate" Issue: An error is raised while creating the payslip Error: float() argument must be a string or a real number, not 'NoneType' This occurs because we don't have a fallback in `_get_paid_amount` opw-4328900 Forward-Port-Of: odoo/enterprise#77277
**Issue** When sending a subscription payment reminder, customers were incorrectly notified to pay the full amount (amount_total) instead of the amount corresponding to subscription orders (recurring_total) only. This issue also occurs in cases of payment failure. opw-4224746 Forward-Port-Of: odoo/enterprise#75319
Original PR description
**Issue** When sending a subscription payment reminder, customers were incorrectly notified to pay the full amount (amount_total) instead of the amount corresponding to subscription orders (recurring_total) only. This issue also occurs in cases of payment failure. opw-4224746 Forward-Port-Of: odoo/enterprise#75319
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Original PR description
When we have a report line that has a sequence lower than the sequence of its parent, the line is not shown in report builder interface. This prevents users to be able to fix the issue. Also, the report will show a traceback. This commit replaces the traceback with a UserError that states the issue. It also shows and highlights the line that is out of sequence so users can fix the issue. Forward-Port-Of: odoo/enterprise#77891 Forward-Port-Of: odoo/enterprise#76788
Migrated method to get the SAT status for EDI documents to zeep library. This because the old way have some errors when the VAT have some `Ñ`. The old way returns: Params: `<![CDATA[?id=E5E54D9B-8A18-4FD4-ACE4-135B6B7E7960&re=NSE111011M99&rr=LEÑ131002PN2&tt=552.99]]>` Response: ```<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><s:Fault><faultcode xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:DeserializationFaile
Original PR description
Migrated method to get the SAT status for EDI documents to zeep library. This because the old way have some errors when the VAT have some `Ñ`. The old way returns: Params:…
Migrated method to get the SAT status for EDI documents to zeep library. This because the old way have some errors when the VAT have some `Ñ`. The old way returns: Params: `<![CDATA[?id=E5E54D9B-8A18-4FD4-ACE4-135B6B7E7960&re=NSE111011M99&rr=LEÑ131002PN2&tt=552.99]]>` Response: ```<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body><s:Fault><faultcode xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:DeserializationFailed</faultcode><faultstring xml:lang="en-US">The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:expresionImpresa. The InnerException message was \'There was an error deserializing the object of type System.String. \'�131002PN2&tt=552.99\' contains invalid UTF8 bytes.\'. Please see InnerException for more details.</faultstring><detail><ExceptionDetail xmlns="http://schemas.datacontract.org/2004/07/System.ServiceModel" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><HelpLink i:nil="true"/><InnerException><HelpLink i:nil="true"/><InnerException><HelpLink i:nil="true"/><InnerException><HelpLink i:nil="true"/><InnerException i:nil="true"/><Message>Unable to translate bytes [D1] at index 0 from specified code page to Unicode.</Message><StackTrace> at System.Text.DecoderExceptionFallbackBuffer.Throw(Byte[] bytesUnknown, Int32 index)
\n at System.Text.DecoderExceptionFallbackBuffer.Fallback(Byte[] bytesUnknown, Int32 index)
\n at System.Text.DecoderFallbackBuffer.InternalFallback(Byte[] bytes, Byte* pBytes, Char*& chars)
\n at System.Text.UTF8Encoding.GetChars(Byte* bytes, Int32 byteCount, Char* chars, Int32 charCount, DecoderNLS baseDecoder)
\n at System.Text.UTF8Encoding.GetChars(Byte[] bytes, Int32 byteIndex, Int32 byteCount, Char[] chars, Int32 charIndex)
\n at System.Xml.XmlConverter.ToChars(Byte[] buffer, Int32 offset, Int32 count, Char[] chars, Int32 charOffset)</StackTrace><Type>System.Text.DecoderFallbackException</Type></InnerException><Message>\'�131002PN2&tt=552.99\' contains invalid UTF8 bytes.</Message><StackTrace> at System.Xml.XmlConverter.ToChars(Byte[] buffer, Int32 offset, Int32 count, Char[] chars, Int32 charOffset)
\n at System.Xml.XmlBufferReader.GetChars(Int32 offset, Int32 length, Char[] chars)
\n at System.Xml.XmlBufferReader.GetString(Int32 offset, Int32 length)
\n at System.Xml.ValueHandle.GetString()
\n at System.Xml.XmlBaseReader.get_Value()
\n at System.Xml.XmlDictionaryReader.ReadContentAsString(Int32 maxStringContentLength)
\n at System.Xml.XmlBaseReader.ReadElementContentAsString()
\n at System.Runtime.Serialization.StringDataContract.ReadXmlValue(XmlReaderDelegator reader, XmlObjectSerializerReadContext context)
\n at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)</StackTrace><Type>System.Xml.XmlException</Type></InnerException><Message>There was an error deserializing the object of type System.String. \'�131002PN2&tt=552.99\' contains invalid UTF8 bytes.</Message><StackTrace> at System.Runtime.Serialization.XmlObjectSerializer.ReadObjectHandleExceptions(XmlReaderDelegator reader, Boolean verifyObjectName, DataContractResolver dataContractResolver)
\n at System.Runtime.Serialization.DataContractSerializer.ReadObject(XmlDictionaryReader reader, Boolean verifyObjectName)
\n at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.PartInfo.ReadObject(XmlDictionaryReader reader, XmlObjectSerializer serializer)
\n at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeParameterPart(XmlDictionaryReader reader, PartInfo part, Boolean isRequest)</StackTrace><Type>System.Runtime.Serialization.SerializationException</Type></InnerException><Message>The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter http://tempuri.org/:expresionImpresa. The InnerException message was \'There was an error deserializing the object of type System.String. \'�131002PN2&tt=552.99\' contains invalid UTF8 bytes.\'. Please see InnerException for more details.</Message><StackTrace> at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeParameterPart(XmlDictionaryReader reader, PartInfo part, Boolean isRequest)
\n at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeParameters(XmlDictionaryReader reader, PartInfo[] parts, Object[] parameters, Boolean isRequest)
\n at System.ServiceModel.Dispatcher.DataContractSerializerOperationFormatter.DeserializeBody(XmlDictionaryReader reader, MessageVersion version, String action, MessageDescription messageDescription, Object[] parameters, Boolean isRequest)
\n at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeBodyContents(Message message, Object[] parameters, Boolean isRequest)
\n at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeRequest(Message message, Object[] parameters)
\n at System.ServiceModel.Dispatcher.DispatchOperationRuntime.DeserializeInputs(MessageRpc& rpc)
\n at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
\n at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
\n at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)</StackTrace><Type>System.ServiceModel.Dispatcher.NetDispatcherFaultException</Type></ExceptionDetail></detail></s:Fault></s:Body></s:Envelope>' ``` Forward-Port-Of: odoo/enterprise#77678 Forward-Port-Of: odoo/enterprise#77616
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by add
Original PR description
Currently an exception was generated when [1] found as multiple state. error: `ValueError: Expected singleton: res.country.state(1674, 18)` This is because [1] searches the state based on state name, but in many scenario the state name maybe repeated for different country eg. United States of America an Uruguay both has same state 'Florida'  This commit will fix the above issue by adding country id in searching state so we always get state based on country. [1] - https://github.com/odoo/enterprise/blob/f3957dc33d956f55b77520167fc9b8ce9dad8c43/account_invoice_extract/models/account_invoice.py#L574 Sentry-6130462157 Forward-Port-Of: odoo/enterprise#77166
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
Original PR description
This commit adds 2025 codes based on https://www.nbb.be/en/statistics/foreign-trade/nomenclature-and-codes Task: 4461223 Forward-Port-Of: odoo/enterprise#77666
This PR fixes an issue about the `$o-color-original` color map values sometimes not matching the light mode one. | //////// | saas-16.3 and above | This PR | |--------|--------|--------| | Light mode |  |  | | Dark mode |  |  |  | | Dark mode |  |  | When we introduced the redesign of the dark mode with Milk (`saas-16.3`), we fine-tuned the badges design in dark mode by slightly tweaking some colors from the `$o-color-original` map, which contains the colors that will be used on badges (as well as other UI elements). While most of the colors were normally tweaked, some colors received a new hue value, meaning the color would not match the light mode one. As this is inconsistent and unexpected, we review the colors to match the light mode ones. task-4522539 Forward-Port-Of: odoo/enterprise#77989
**Issue:** A error shows up when trying to insert a grouped and ordered list into spreadsheet. **Expected:** The displayed list, even if groups or orders are applied, should be insertable into spreadsheet. **Steps to reproduce:** - Activate Employees app (or any app using lists and allowing to group results) and enter in it; - Display employees as a list; - Add a `Group By` constraint (e.g. `Manager`) and order it by clicking the 2 arrows (appearing on hover);  - Open a toggled section; - Select several (or all) employees; - Using `Actions`, try `Insert in spreadsheet`. **Cause:** The list renderer doesn't manage the `Group By` constraints. **Fix:** Ignore grouped constraints. opw-4254376 Forward-Port-Of: odoo/enterprise#76283
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#7687
Original PR description
The `MRR Evolution` dashboard contained a relation filter that would wrongly refer to the model `sale.temporal.recurrence` even tough its field matching pointed towards `sale.subscription.plan`. From a setup POV, the filter was invalid but the only part we use is the field matching, which was correct in itself. The issue came when we wanted to edit the filter in a database which did not have the model `sale.temporal.recurrence`. task-4467133 opw-4432567 Forward-Port-Of: odoo/enterprise#76877
Steps to reproduce: - Create a new accounting report - Create a new line - Set a value in the groupby field -> A warning appears, stating that the line uses a custom user-defined "group by" value. This warning is only useful when modifying a groupby value for a line that has a xmlid. task-4286306 Forward-Port-Of: odoo/enterprise#74526
Original PR description
Steps to reproduce: - Create a new accounting report - Create a new line - Set a value in the groupby field -> A warning appears, stating that the line uses a custom user-defined "group by" value. This warning is only useful when modifying a groupby value for a line that has a xmlid. task-4286306 Forward-Port-Of: odoo/enterprise#74526
Change an f-string into an sql.identifier for injection prevention Forward-Port-Of: odoo/enterprise#77956
Original PR description
Change an f-string into an sql.identifier for injection prevention Forward-Port-Of: odoo/enterprise#77956
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product -
Original PR description
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule…
**Steps to reproduce:** - Install stock_barcode and Sales - In Inventory settings, enable "Multi-Step Routes" - Go to "Inventory / Configuration / Warehouse Management / Routes" - Configure the rule of "Deliver in 1 step (ship)": * Propagation of Procurement Group: Fixed * Fixed Procurement Group: [create a new one] - Create a product tracked by lot - Update the quantity (e.g. 100) of the created product and assign it to a lot - Create a SO for a customer with the created product - Confirm the SO - Create another SO for the same customer with the same product => A delivery order should be created with 2 operations with the same product - Open the delivery order in Barcode - Scan the source location - Select the 2nd line - Scan the lot **Issue:** The first line is incremented instead of the second one. Even when all the products for the first line will be scanned, it will not be possible to scan the lot to increment the second line. **Cause:** The selected line is not taken into account when searching the line on which the scanned lot should be applied. **Solution:** Unshift the selected line to the first position of the array of lines to prioritize it when searching for the adequate line for a scanned lot. opw-4208612 Forward-Port-Of: odoo/enterprise#77807 Forward-Port-Of: odoo/enterprise#76713
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_defaul
Original PR description
Issue: - When creating a SO with two service type products, configured to plan services. When auto planning, only one service gets planned. Steps to reproduce: 1- Create a SO with two service type products. 2- Configure the products to plan services. 3- Confirm the SO. 4- Click on the "To Plan" smart button. 5- Click on the "Auto plan" button. 6- Notice that only one service (the first one) gets planned. Solution: - in `action_view_planning` method, we rely on 'search_default_role_id' in the context to get our role_id. - however when we have an array of `role_id`, `search_default_` eventually calls `visitField` https://github.com/odoo/odoo/blob/a711818e93fb253d52a8925a9b12540e4d83d798/addons/web/static/src/search/search_arch_parser.js#L132 where we take only the first value of the array. - So I added a domain. opw-4350959 Forward-Port-Of: odoo/enterprise#77724
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug i
Original PR description
### Steps to reproduce: - Create a new Contact - Set the country to Morocco - Add "52258521" as a VAT number - Try to validate -> Error ### Cause: Only occurs after saas-17.4 because it is related to the library `stdnum`. The version of this library change when the Python version is >3.11. As the SaaS version use Python3.12 since saas-17.4 and Python3.10 before, the bug only appears in saas-17.4, but this change targets 17.0 because 17.0 supports Python > 3.10. The cause of the bug is the new version of the library which implements a verification method that corresponds to Moroccan ICE numbers and not VAT numbers. ### Solution: Create the method to check the Moroccan VAT numbers. The format is just a number with 8 digits. opw-4447478 Forward-Port-Of: odoo/enterprise#77877
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Original PR description
task-4497852 Forward-Port-Of: odoo/enterprise#77779
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long and quite thorough research what was discovered are the following: - this issue happens only once the `website` module has been installed - the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load. - the "blur" event triggered by the `text_
Original PR description
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name. After very long…
Since version Chrome 128, the "new" headless mode has been set as default but the `payroll_dashboard_ui_tour` failed on a step relying on the "blur" event to update the Todo's name.
After very long and quite thorough research what was discovered are the following:
- this issue happens only once the `website` module has been installed
- the tour is started from "/" (in Python) but actually run from "/web" (in JS), resulting in a useless first load.
- the "blur" event triggered by the `text_run ...` tour's command never reaches the `t-on-blur` OWL's handler, while no listener that may have "eaten" the event has been found...
- making the "blur" event bubble (which is not its normal behavior) does have some impact on the issue...
- running the tour directly from the backend (e.g. `start_tour("/web", ...)` doesn't present this issue.
While the exact root cause of this issue hasn't been identified so fare, this commit sets the tour to be run directly from the backend (which makes sense as it is a backend-only test tour anyway) as a workaround.
Note: while being an issue in automated test, the feature operated by an actual user looks to be working properly.
Forward-Port-Of: odoo/enterprise#77823Issue ----- The "Import FEC" button is only visible when in a company set in France, despite the localization being installed. Steps to reproduce ----- - Install Accounting & the French accounting localization - Settings > Accounting > Import Cause ----- The FEC import button is specified in the base import, and only visible when the company country code is set to France. If the localization isn't installed, it prompts the user to do so. As per the PO, we want the button to be prese
Original PR description
Issue ----- The "Import FEC" button is only visible when in a company set in France, despite the localization being installed. Steps to reproduce ----- - Install Accounting & the French accounting localization - Settings > Accounting > Import Cause ----- The FEC import button is specified in the base import, and only visible when the company country code is set to France. If the localization isn't installed, it prompts the user to do so. As per the PO, we want the button to be present when the localization is installed, regardless of the country of the company. ----- Ticket: opw-4356726 Forward-Port-Of: odoo/enterprise#76235
Steps to reproduce the bug: - Create a storable product "P1" with a BoM. - Go to ECO stage > In Progress > add two approvals: - approval 1: Mitchel admin + Marc Demo - approval 2: Mitchel admin + Marc Demo - Navigate to PLM > BoM Update and create a new ECO: - Create a new ECO: - Type: BoM Update - Apply On: BoM - Product P1 - Start the revision - Move the ECO to In Progress. Problem: A validation error occurs: “The operation cannot be completed: Error
Original PR description
Steps to reproduce the bug:
- Create a storable product "P1" with a BoM.
- Go to ECO stage > In Progress > add two approvals:
- approval 1: Mitchel admin + Marc Demo
- approval 2: Mitchel admin + Marc Demo
- Navigate to PLM > BoM Update and create a new ECO:
- Create a new ECO:
- Type: BoM Update
- Apply On: BoM
- Product P1
- Start the revision
- Move the ECO to In Progress.
Problem:
A validation error occurs:
“The operation cannot be completed: Error, a partner cannot follow twice the same object.”
opw-4421352
Forward-Port-Of: odoo/enterprise#77308
Forward-Port-Of: odoo/enterprise#76232Due to the sync being broken the past 2 weeks, manually pull the Greek translations since translations have been added to it recently.
Original PR description
Due to the sync being broken the past 2 weeks, manually pull the Greek translations since translations have been added to it recently.
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record
Original PR description
To reproduce: 1) install localization of any of the below modules. 2) Make branch companies in that localization. 3) install one of the modules below. we get this error:https://github.com/odoo/odoo/blob/17.0/addons/account/models/account_tax.py#L200, `Tax names must be unique`, so only load taxes for root companies. and for tax_group we get this error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Tax Group (account.tax.group) Field: Name (name) ``` Forward-Port-Of: odoo/enterprise#76792