Wednesday, January 29, 2025
24 changes · saas-17.4
Enhancements to existing features
The base module now gives clearer test feedback when hidden fields in views need attention. Instead of only listing affected views, the message identifies the specific fields to remove or comment, making cleanup faster and reducing developer investigation time.
Original PR description
### Description of the issue/feature this PR addresses:
Since this PR #162009, all uncommented invisible fields raise an error.
This commit improves the error message from the method `test_uncommented_invisible_field` by showing which line of the view should be removed/commented.
The error message before this commit :
```
Addons: 'module_name' Views: ['view_name1', 'view_name2']
```
After:
```
Addon: 'module_name'
View: view_name1
Fields:
<field name="field1" invisible="1">
<field name="field2" invisible="1">
View: view_name2
Fields:
<field name="field1" invisible="1">
```
The main benefit of this change is to display in a single test all uncommented fields that need to be fixed.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prDeferred audit screens now show only the columns that are useful for reviewing deferred entries. This reduces clutter and helps accounting teams focus faster on the information needed during audits.
Original PR description
task-4497852
Miscellaneous changes
This change updates an internal Point of Sale data model file. The PR details are minimal, so the expected business impact appears limited and primarily supports smoother POS behavior behind the scenes.
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
- 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, disp
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-4354129
Forward-Port-Of: odoo/odoo#195393Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "cha
Original PR description
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before…
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "change" event. However, at that point, the form controller is already destroyed, hence the error. In that flow, we don't want to perform the onchange as we're discarding the form. Actually, we don't want the field to listen to the "change" event anymore. We delay for a micro-tick the activation of the previously active element, to wait for owl to have called destroy on the whole component hierarchy, and thus for the "change" handler to be removed (in input_field_hook). The issue could be reproduced in Studio: - click on Edit menu - open a menu to edit it - change its name but to not blur/click out - press Esc This is a backport of odoo/odoo#195238, where we add a test (hoot). The faulty scenario could not be reproduced in the QUnit suite because we do not precisely enough mock events that occur when focusing/bluring elements. opw-4490577 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#195343 Forward-Port-Of: odoo/odoo#195242
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
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
### 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
**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
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in ot
Original PR description
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all…
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in other companies/warehouses. This commit and an option to allow the cancel propagate upstream. It's hidden under the `stock.cancel_moves_origin` system parameter in order to avoid a huge behavior modification for other users. opw-3274939 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#193849 Forward-Port-Of: odoo/odoo#186730
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
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#191389When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195323 Forward-Port-Of: odoo/odoo#194500
Original PR description
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195323 Forward-Port-Of: odoo/odoo#194500
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
Original PR description
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
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
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 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#77876
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#77823Steps 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
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
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 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
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