Daily updates from Odoo
Tuesday, November 5, 2024
49 changes · 18.0
Enhancements to existing features
The IoT Box now updates only the logging settings it needs, avoiding unwanted changes in its configuration file. It also automatically returns detailed logging to the normal warning level after a week, reducing unnecessary log volume sent to the database.
Original PR description
Logging levels updating methods used `odoo.tools` config methods. It was not adapted to the IoT Box as it was polluting the `odoo.conf` file with unwanted parameters.
We now use the `helpers.{update_,get_}conf` methods to only update the required parameters.
This commit also adds a scheduled event everyday at 00:00 to switch back to `:WARNING` log level if it was set more
than a week before, to reduce the amount of logs sent to the database.
Task: 4173458Signing email templates now adapt better to mobile screens. This improves readability and usability for people reviewing or signing documents from phones or tablets.
Original PR description
Before this commit, email templates in sign are not responsive in mobile which can cause inconvenience to user. After this commit, make sign email templates responsive for mobile so users will have a better experience with email templates on their mobile devices task-4034697
Resolved issues and error corrections
This fixes an automated test for the Maintenance calendar by ensuring it is in the correct monthly view before moving a recurring event. The change helps prevent false test failures and supports smoother ongoing quality checks without changing user-facing functionality.
Original PR description
In this commit, we add a check step to ensure the view is Month view before to drag and drop the item or drag and drop will be directly executed ... and tour fails. 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
Users can now create link tracking records without being asked to enter a tracked URL immediately. This removes an unnecessary step during setup while still allowing the URL to be adjusted later if needed.
Original PR description
#### Purpose We should not ask users to provide a tracked URL, it's supposed to be something you change afterwards if you want an extension that looks good. #### After this PR Removed required attribute, so it will not asked user a Tracked URL on record creation. Task-4279725
Website editors can once again adjust the layout and content width of standard carousel sections. This restores useful design controls that were accidentally removed during a prior carousel redesign, helping teams fine-tune page presentation without workarounds.
Original PR description
In commit [1], the carousels have been redesigned. However, with it, the "Layout" and the "Content Width" options have been removed from some of them. They can therefore not be toggled to grid mode anymore and their container width cannot be changed, which could have been useful now that the arrows can be hidden. This commit restores these options for the `s_carousel` snippet. Note that the `s_carousel_intro` one redefined these options, which is why it has them. The other ones (i.e. `s_image_gallery`, `s_quotes_carousel` and `s_quotes_carousel_minimal`) do not need them. [1]: https://github.com/odoo/odoo/commit/3deb8050831c69ca1e32039622b322ffa38cc497#diff-934f432382bbc5c89d776f677d71ef50392d8652b2e9fa7bba3ff39475b842ae task-4263725
Brazilian webshop orders now correctly trigger Avatax tax calculation during checkout. This prevents payment-blocking errors caused by missing goods operation details, helping customers complete online purchases successfully.
Original PR description
With a BR Company Setup: Settings > Website, assign 'My Website' to BR Company Configure Avatax Brazil in General Settings > Taxes > Avatax Publish the Product "Regular Consumable Product" to be available in the website. Open the web shop as Public User Add "Regular Consumable Product" to cart Go to checkout Fill valid Brazilian customer info Pay Issue: Error will popup ``` odoo.http: Odoo could not fetch the taxes related to S00040. It is not possible identify the CFOP ``` This occurs because the sales order is missing the "Goods Operation Type" and the call to Avatax is not done opw-4239483
Users who run into an Amazon onboarding issue now see a clear error page instead of a generic internal server error. This helps them understand what went wrong and reduces confusion during setup.
Original PR description
When an onboarding error occurred, the error page failed to render and the user would see "Internal Server Error" instead of a more helpful error message. The server error had two causes: - The original onboarding error not being properly cast to a string. - The onboarding return route not passing the lang code to the QWeb context.
The label for a document project validation action was corrected so it accurately says “Remove Tag Draft” instead of implying the draft tag is added. This helps administrators identify the right action more easily and avoids confusion when reviewing server actions.
Original PR description
The issue: The child of the server action "Ask for Validation, Add Tag Draft" should be named "Remove Tag Draft." How to reproduce the issue: - Go to Server Actions: Search for “Ask for validation”. - Open “Add tag draft” child action opw-4281732
Folders in Trash no longer open or redirect when double-clicked. Users are instead informed why the action is unavailable, reducing confusion and unnecessary navigation.
Original PR description
Disable double-click action for folders in Trash to prevent unnecessary redirection and inform the user with a valid reason. Task-4231365
The spreadsheet navigation bar now uses the correct translated label for “Spreadsheet.” This improves the experience for users working in languages other than English by making the interface consistent with their selected language.
Original PR description
The term "Spreadsheet" isn't translated in the spreadsheet nav bar Task: 4300455
This fixes failing automated tests in the Hong Kong payroll accounting area after recent changes to leave allocation rules and payslip validation behavior. The change helps keep payroll accounting checks reliable without affecting normal business workflows.
Original PR description
In-use leave type allocation cannot be changed recently. Cause the unit test failed here. Also validate payslip common method is refactor into hr_payroll_account. However it is slightly different behavior than the original util method, which caused the unit test failed as well. runbot-101710
Shared appointment pages without a website now display formatted introduction text as intended. This prevents customers from seeing raw HTML code when switching appointment types, improving the booking experience.
Original PR description
Steps to reproduce: 1. Install only appointments without having a website. 2. Create or use already existing appointments and share them. 3. Go to the share URL 4. Here we will see a dropdown and the description text of the appointment, try to change the value on the dropdown and see the text. The issue arises because `replaceChildren` treats strings as plain text, so HTML in `message_intro` is displayed as text rather than rendered as HTML. To resolve this, we use DOMParser to convert the `message_intro` string into HTML elements. This allows `replaceChildren` to insert actual HTML nodes instead of plain text, preserving the intended formatting. This issue was introduce in this commit https://github.com/odoo/enterprise/commit/9e38975d3f1e9dc87a3061c06ce9df7cf562949c. opw-4250366
Code cleanup and technical improvements
This update reorganizes how automated guided tours report success or failure, making the underlying code easier to maintain and reason about. It also removes an obsolete cleanup step, reducing the chance of minor technical errors during tour execution.
Original PR description
In this commit, we move the tour_automatic callback in the tour_service to the tour_automatic class. This allows for clearer handling of tour error or success messages. We take advantage of this commit to remove a small error (clearTimeout(this._timeout)) in the tour_step_automatic where this._timeout no longer exists. 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
Miscellaneous changes
Versions -------- - saas-17.4+ Steps ----- 1. Set localization to UK English (or any using ISO week numbering); 2. use Europe/Brussels timezone; 3. set a task's deadline to 2024-01-01 00:00:00; 4. go to task list view; 5. group by Deadline > Week. Issue ----- Task is grouped under W52 2023. The correct ISO week number for this date is 1.[^1] Cause ----- Commit 75c63315169c added a custom `weeknumber` function to `date_utils` to circumvent the issues with Babel's week number
Original PR description
Versions -------- - saas-17.4+ Steps ----- 1. Set localization to UK English (or any using ISO week numbering); 2. use Europe/Brussels timezone; 3. set a task's deadline to 2024-01-01 00:00:00; 4. go…
Versions -------- - saas-17.4+ Steps ----- 1. Set localization to UK English (or any using ISO week numbering); 2. use Europe/Brussels timezone; 3. set a task's deadline to 2024-01-01 00:00:00; 4. go to task list view; 5. group by Deadline > Week. Issue ----- Task is grouped under W52 2023. The correct ISO week number for this date is 1.[^1] Cause ----- Commit 75c63315169c added a custom `weeknumber` function to `date_utils` to circumvent the issues with Babel's week numbering. If given a `datetime` object, it should be localized with the appropriate timezone instead of being passed as UTC. Solution -------- The value provided to the `_read_group_format_result` is already in the localized timezone. This gets assigned to `range_start`, which gets converted to UTC. Instead of passing `range_start` to `weeknumber`, we can provide it the unmodified `value` variable. opw-4188099 [^1]: https://www.calendar-365.co.uk/calendar/2024/January.html Forward-Port-Of: odoo/odoo#184351
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185989 Forward-Port-Of: odoo/odoo#185817
Original PR description
*l10n_fr,l10n_fr_facturx_chorus_pro,l10n_fr_fec,l10n_fr_invoice_addr, l10n_fr_pos_cert Related to https://github.com/odoo/enterprise/pull/73048 Forward-Port-Of: odoo/odoo#185989 Forward-Port-Of: odoo/odoo#185817
Before this commit, performing a cash move would cause an error due to a missing order when calling `getReceiptHeaderData`. opw-4309610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186221
Original PR description
Before this commit, performing a cash move would cause an error due to a missing order when calling `getReceiptHeaderData`. opw-4309610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186221
Steps ----- - Install l10n_fr_hr_holidays - Use french company and be in a timezone different than UTC - Set your user's employee to use a different working hours schedule than the french company - Take a day of paid time off -> Two days of paid time off appear on the Dashboard (if not in an UTC timezone). Cause ----- For full days leaves, the hours are set to min and max to avoid calculation issues https://github.com/odoo/odoo/blob/24e100a5acf7531787a646ff1473c4b027d1ad12/addons/l
Original PR description
Steps ----- - Install l10n_fr_hr_holidays - Use french company and be in a timezone different than UTC - Set your user's employee to use a different working hours schedule than the french company - Take a day of paid time off -> Two days of paid time off appear on the Dashboard (if not in an UTC timezone). Cause ----- For full days leaves, the hours are set to min and max to avoid calculation issues https://github.com/odoo/odoo/blob/24e100a5acf7531787a646ff1473c4b027d1ad12/addons/l10n_fr_hr_holidays/models/hr_leave.py#L39-L40 But is not converted to UTC time, leading to the leave being displayed over several days if not created by a user in UTC time. Change ----- For full days leaves, adjust the start and end time of the leave in the same way that is currently done for half days. This also makes the leave's hours closer to reality. opw-4203972 Forward-Port-Of: odoo/odoo#182816
### Steps to reproduce the issue: 1. Activate Italian Localization 2. Create a contact in any country but Italy 3. Assign VAT number starting with 'IT' (Tax ID or Identification Number) 4. Save and receive error: > Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses. ### Explanation: When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.part
Original PR description
### Steps to reproduce the issue: 1. Activate Italian Localization 2. Create a contact in any country but Italy 3. Assign VAT number starting with 'IT' (Tax ID or Identification Number) 4. Save and…
### Steps to reproduce the issue: 1. Activate Italian Localization 2. Create a contact in any country but Italy 3. Assign VAT number starting with 'IT' (Tax ID or Identification Number) 4. Save and receive error: > Invalid Codice Fiscale '[VAT number]': should be like 'MRTMTT91D08F205J' for physical person and '12345670546' for businesses. ### Explanation: When `country_id` or `vat` is changing, `_l10n_it_onchange_vat` will try to create a `l10n_it_codice_fiscale` if `res.partner` respects some conditions. Those conditions are flawed because if `country_id` is not Italy but `vat` starts with "IT", it will enter the condition. (Kind of a hack: if `country_id` is set after a `l10n_it_codice_fiscale` has been added to `res.partner`, the first condition will not be met but the second will, and `l10n_codice_fiscale` will turn back to False.) ### Fix reasoning: We will only check conditions related to `vat` and `country_id` and always perform changes to avoid inconsistencies where `vat` is no longer correct but `l10n_it_codice_fiscale` did not change and is still valid. opw-4261959 Forward-Port-Of: odoo/odoo#185604 Forward-Port-Of: odoo/odoo#184406
Before this commit, sometimes the test failed because the step to cancelled a sub-task is not yet done in the UI (the record has not yet been reloaded) before the next step is executed. This commit changes some trigger in some steps to be more precise but also add an additional step to make sure the dropdown showing the task states is correctly closed before checking if the sub-task is correctly marked as done. runbot-73414 Forward-Port-Of: odoo/odoo#184566
Original PR description
Before this commit, sometimes the test failed because the step to cancelled a sub-task is not yet done in the UI (the record has not yet been reloaded) before the next step is executed. This commit changes some trigger in some steps to be more precise but also add an additional step to make sure the dropdown showing the task states is correctly closed before checking if the sub-task is correctly marked as done. runbot-73414 Forward-Port-Of: odoo/odoo#184566
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
Original PR description
The test was failing in winter because of the offset is -005 and not -004. The test is mainly there to check that a non migrated tz will behave as the replacement tz. Making the expected offset dynamic solve the issue. Runbot error: 105674 Forward-Port-Of: odoo/odoo#186108
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than e
Original PR description
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when…
#### Commit 1 [FIX] sms, tools: prevent adding link references in sms This fix prevents the conversion of urls into reference footnotes in sent sms (adding characters and imparing readability) when coming from raw text (in opposition to html source). #### Commit 2 [FIX] mass_mailing_sms: fix characters count with (opt-out) links Also impacted: sms When adding opt-out link or any link in the text, the characters count was incorrect which made SMS campaigns more expensive than expected when added characters meant more SMS to send for the message. Also includes FW port of follow-ups * [FIX] mass_mailing_sms: fix sms link placeholders tests with original hash 0e1d2f155a44c5ff55d586a8d44bb9436c46b53e * [FIX] mass_mailing_sms: fix field sms widget translation with original hash 34a1ddc04856f3e3554ae9092afef08cc23f2dc7 #### ~~Commit 3~~ [FIX] sms: fix disappearing sms counts Not necessary since OWL #### Commit 3 A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. We also clean obsolete test parts and documentation. FW-port of: odoo/odoo#185923 FW-port of: odoo/odoo#176074 Task-3502174 Forward-Port-Of: odoo/odoo#174439 Forward-Port-Of: odoo/odoo#140102
Description of the issue/feature this PR addresses: - allow inheriting modules to define own logic about how sale lines should create projects/tasks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185934
Original PR description
Description of the issue/feature this PR addresses: - allow inheriting modules to define own logic about how sale lines should create projects/tasks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185934
Apart from the wrong domain, the performance issues are also huge. Description of the issue/feature this PR addresses: Wrong code. Wrong domain, affecting also performance 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#179683
Original PR description
Apart from the wrong domain, the performance issues are also huge. Description of the issue/feature this PR addresses: Wrong code. Wrong domain, affecting also performance 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#179683
Description of the issue/feature this PR addresses: TestAPIKeys.test_delete creates an user, which might trigger an automated action. However that action would fail [here](https://github.com/odoo/odoo/blob/17.0/addons/base_automation/models/base_automation.py#L67), since the mockup request that is set up in the test does not include a function request.get_json_data() nor request.httprequest.args Current behavior before PR: The test fails on databases that have an automated action triggered
Original PR description
Description of the issue/feature this PR addresses: TestAPIKeys.test_delete creates an user, which might trigger an automated action. However that action would fail [here](https://github.com/odoo/odoo/blob/17.0/addons/base_automation/models/base_automation.py#L67), since the mockup request that is set up in the test does not include a function request.get_json_data() nor request.httprequest.args Current behavior before PR: The test fails on databases that have an automated action triggered on user creation Desired behavior after PR is merged: This test should not fail on such databases This issue has been discussed [here](https://discord.com/channels/678381219515465750/687339689522364423/1300410221482479636) Forward-Port-Of: odoo/odoo#185493
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/odoo#185282 Forward-Port-Of: odoo/odoo#183165
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/odoo#185282 Forward-Port-Of: odoo/odoo#183165
Issue ----- GPS coordinates are missing when an employee checks in/out in Kiosk mode. Steps ----- - Install Attendances - Check in or check out from kiosk mode - Go to Attendances > click on the corresponding attendance > the GPS coordinates are 0, 0 for any check in/out in "kiosk" mode. opw-4239596 Forward-Port-Of: odoo/odoo#183741
Original PR description
Issue ----- GPS coordinates are missing when an employee checks in/out in Kiosk mode. Steps ----- - Install Attendances - Check in or check out from kiosk mode - Go to Attendances > click on the corresponding attendance > the GPS coordinates are 0, 0 for any check in/out in "kiosk" mode. opw-4239596 Forward-Port-Of: odoo/odoo#183741
HTML user menu items were escaped on the mobile client Fixes #145693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185600 Forward-Port-Of: odoo/odoo#152809
Original PR description
HTML user menu items were escaped on the mobile client Fixes #145693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185600 Forward-Port-Of: odoo/odoo#152809
Specification: This PR aims to resolve the issue occured while discarding the upload process the `this.fileInput.el` becomes undefined as image is discarded which resulted in traceback. task-4255826 Forward-Port-Of: odoo/odoo#185852 Forward-Port-Of: odoo/odoo#183547
Original PR description
Specification: This PR aims to resolve the issue occured while discarding the upload process the `this.fileInput.el` becomes undefined as image is discarded which resulted in traceback. task-4255826 Forward-Port-Of: odoo/odoo#185852 Forward-Port-Of: odoo/odoo#183547
Before this commit, if you opened a table on one device without adding any items, and then opened the same table on another device, added items, and pressed order, an error would occur due to searching with a string for the ID of an order. opw-4299785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186148
Original PR description
Before this commit, if you opened a table on one device without adding any items, and then opened the same table on another device, added items, and pressed order, an error would occur due to searching with a string for the ID of an order. opw-4299785 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186148
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were making the view looking different from the other one, resulting in consistencies issues. This PR tweaks some CSS in order to handle most of these issues. task-3713647 | /// | 17.0 | This PR | |--------|--------|--------| | LM | <img alt="image" src="https://github.com/user-attachments/
Original PR description
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were…
This PR aims to solve an old issue that was not fixed with the Milk redesign. Prior to this PR, there were different layout issues including colors, sizes, or dark mode adaptations. These issues were making the view looking different from the other one, resulting in consistencies issues. This PR tweaks some CSS in order to handle most of these issues. task-3713647 | /// | 17.0 | This PR | |--------|--------|--------| | LM | <img alt="image" src="https://github.com/user-attachments/assets/09eba47a-8d9e-4a4b-af73-f8f83321a454"> | <img alt="image" src="https://github.com/user-attachments/assets/bea7c02c-2118-4262-9433-52cddd99e7e7"> | | DM | <img alt="image" src="https://github.com/user-attachments/assets/416bd1a5-9c7f-44d7-a78d-f479074f5f42"> | <img width="1530" alt="image" src="https://github.com/user-attachments/assets/9fb77db6-7752-403a-82de-9d03b9fe46e6"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186156
In 865baf9ef154e2a36817e40a50e09d5e98cf95f9, makeAsyncHandler has been incorrectly modified so that the promise rejection is consumed by the catch, instead of letting it bubble up through a finally. Indeed, contrarily to makeButtonHandler, makeAsyncHandler doesn't create a new Promise object. This means that the finally is applied on the result itself. In makeButtonHandler, the then handler returns a new Promise that is different from result, but that will be rejected if result is rejected.
Original PR description
In 865baf9ef154e2a36817e40a50e09d5e98cf95f9, makeAsyncHandler has been incorrectly modified so that the promise rejection is consumed by the catch, instead of letting it bubble up through a finally. Indeed, contrarily to makeButtonHandler, makeAsyncHandler doesn't create a new Promise object. This means that the finally is applied on the result itself. In makeButtonHandler, the then handler returns a new Promise that is different from result, but that will be rejected if result is rejected. This is why in this case we need to hide that extra rejection by swallowing it in the onRejected argument, instead of using a finally. Task-Id: None Forward-Port-Of: odoo/odoo#185034 Forward-Port-Of: odoo/odoo#183894
When an iFrame and its parent document are from different origins, contentDocument is null. See: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentDocument This will cause an error when interacting with an iFrame that contains a Google Slide, which is from a different origin. Due to this, we need to check that there's a contentDocument before trying to use its content. opw-4240622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com
Original PR description
When an iFrame and its parent document are from different origins, contentDocument is null. See: https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement/contentDocument This will cause an error when interacting with an iFrame that contains a Google Slide, which is from a different origin. Due to this, we need to check that there's a contentDocument before trying to use its content. opw-4240622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185107
Currently, When the user adds a wrong ``div(eg: </div>)`` in a view's architecture and tries to save the view, then an error occurs. Steps to reproduce: - Go to Settings > Technical > Views > open a view - In View Architecture add ``closing div(eg: </div>)`` after any ``div`` - Then save manually, the error will occur. Traceback: `` ParserError: Multiple elements found (div, div)`` To solve this issue, the error has been handled using a try-except block in the ``parse_html`` method
Original PR description
Currently, When the user adds a wrong ``div(eg: </div>)`` in a view's architecture and tries to save the view, then an error occurs. Steps to reproduce: - Go to Settings > Technical > Views > open a view - In View Architecture add ``closing div(eg: </div>)`` after any ``div`` - Then save manually, the error will occur. Traceback: `` ParserError: Multiple elements found (div, div)`` To solve this issue, the error has been handled using a try-except block in the ``parse_html`` method. sentry-4147547360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168422
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#185923 Forward-Port-Of: odoo/odoo#176074
Original PR description
A problem was left to be fixed in the previous PR: What was to be considered the url and label was sometimes incorrectly computed with html_keep_url. As it is used in other places, we simply don't use it anymore, but extract the needed part from it: how a link is safely rendered. Task-3502174 Forward-Port-Of: odoo/odoo#185923 Forward-Port-Of: odoo/odoo#176074
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: gram - Create a component “C1” - UoM: gram - Create a BoM for P1: - quantity: 1kg - Component: 1g of C1 - Create a Mo to produce 1kg of P1 - Confirm the MO - Create a landed cost: - Apply on manufacturing order - Select the created MO - Add a landed product with a unit price of 25 - Validate the landed cost - Go to the linked valuation layer Problem: A value of (25 * 1000) is
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: gram
- Create a component “C1”
- UoM: gram
- Create a BoM for P1:
- quantity: 1kg
- Component: 1g of C1
- Create a Mo to produce 1kg of P1
- Confirm the MO
- Create a landed cost:
- Apply on manufacturing order
- Select the created MO
- Add a landed product with a unit price of 25
- Validate the landed cost
- Go to the linked valuation layer
Problem:
A value of (25 * 1000) is added instead of only $25
opw-4252901
Forward-Port-Of: odoo/odoo#185907
Forward-Port-Of: odoo/odoo#185725In the Inventory Overview, when 'group by' or custom filter is applied, the back orders field and its label overlap on the kanban card. Steps to reproduce: 1. Open Inventory --> Overview. 2. use 'group by' or apply a filter. 3. Observe the back order field on the kanban card for overlapping issues. OPW-4188426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181251
Original PR description
In the Inventory Overview, when 'group by' or custom filter is applied, the back orders field and its label overlap on the kanban card. Steps to reproduce: 1. Open Inventory --> Overview. 2. use 'group by' or apply a filter. 3. Observe the back order field on the kanban card for overlapping issues. OPW-4188426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#181251
*l10n_fr_fec_import,l10n_fr_reports Related to https://github.com/odoo/odoo/pull/185817 Forward-Port-Of: odoo/enterprise#73131 Forward-Port-Of: odoo/enterprise#73048
Original PR description
*l10n_fr_fec_import,l10n_fr_reports Related to https://github.com/odoo/odoo/pull/185817 Forward-Port-Of: odoo/enterprise#73131 Forward-Port-Of: odoo/enterprise#73048
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs. Forward-Port-Of: odoo/enterprise#73268
Original PR description
Before this PR: - POS order lines were matched without sorting `tax_ids`, which could cause mismatches when the tax IDs were in a different order between `details_pos_line` and `account_move_line`. After this PR: - POS order lines are matched by comparing `tax_ids` in sorted order, ensuring consistent matching regardless of the order of tax IDs. Forward-Port-Of: odoo/enterprise#73268
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten
Original PR description
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two…
Norway will soon (beginning of 2025) only accept their 1.30 version of the SAF-T. This commit adapts the current behaviour to be in line with the change to that new version. This also correct two errors that were used in the generic SAF-T module: - The accounts codes should be used for AccountID instead of the account database ids - The ValueDate should be the accounting date and not the invoice date. Based on the info from: - Previous version SAF-T description: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-desember-2020/norwegian-saf-t-financial-data---technical-description.pdf - New version: https://www.skatteetaten.no/globalassets/bedrift-og-organisasjon/starte-og-drive/rutiner-regnskap-og-kassasystem/saf-t-regnskap/oppdateringer-mars-2024/norwegian-saf-t-financial-data---technical-description.pdf task-3975794 Forward-Port-Of: odoo/enterprise#73022 Forward-Port-Of: odoo/enterprise#65221
after this [FIX](https://github.com/odoo/enterprise/commit/ffcc8c425b53df94d79ace17fb444504df8acd52), the access to answers of feedbacks is restricted to the manager of appraisals, but the officer should have access too. this commit fixes this issue. opw-4128638 Forward-Port-Of: odoo/enterprise#72357
Original PR description
after this [FIX](https://github.com/odoo/enterprise/commit/ffcc8c425b53df94d79ace17fb444504df8acd52), the access to answers of feedbacks is restricted to the manager of appraisals, but the officer should have access too. this commit fixes this issue. opw-4128638 Forward-Port-Of: odoo/enterprise#72357
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/enterprise#72781 Forward-Port-Of: odoo/enterprise#71676
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian. Forward-Port-Of: odoo/enterprise#72781 Forward-Port-Of: odoo/enterprise#71676
The error Avalara returns for this is too generic to be useful: Rejeição: Evento não atende o Schema XML específico We found out by contacting Avalara support that the error in this case was a reason that was too short. Let's prevent this from re-occuring. opw-4298175 Forward-Port-Of: odoo/enterprise#73258 Forward-Port-Of: odoo/enterprise#73209
Original PR description
The error Avalara returns for this is too generic to be useful: Rejeição: Evento não atende o Schema XML específico We found out by contacting Avalara support that the error in this case was a reason that was too short. Let's prevent this from re-occuring. opw-4298175 Forward-Port-Of: odoo/enterprise#73258 Forward-Port-Of: odoo/enterprise#73209
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`. Forward-Port-Of: odoo/enterprise#70862
Original PR description
- Added 'post_install' and '-at_install' tags to ensure the test is executed after all modules are installed, necessary for `test_skill_search_on_ocr_results` to run fully. - Fixed the test to detect when no skills were being added to the applicant, even though some should have been. - Updated the skills search regex: replaced `\s` tags with `\b` tags to correctly detect the first and last words in `ocr_tokens`. Forward-Port-Of: odoo/enterprise#70862
This commit adds a new error modal when you clicking on deleted tweets and posts. It was decided to do so in stable as properly handling deleted posts requires a more consistent approach for each social network. This work should instead be done in later versions as such work will require a lot of changes. Which is against our stable version policy. task-3999571 Forward-Port-Of: odoo/enterprise#72934 Forward-Port-Of: odoo/enterprise#69168
Original PR description
This commit adds a new error modal when you clicking on deleted tweets and posts. It was decided to do so in stable as properly handling deleted posts requires a more consistent approach for each social network. This work should instead be done in later versions as such work will require a lot of changes. Which is against our stable version policy. task-3999571 Forward-Port-Of: odoo/enterprise#72934 Forward-Port-Of: odoo/enterprise#69168
"Title Suggested features for your new model" pop-up is not well aligned. After the upgrade to bootstrap 5.3, the variable is declared in the .model ( https://github.com/odoo/odoo/blame/63e09a452d7724b6e844c5b0229c95e36f39ea61/addons/web/static/lib/bootstrap/scss/_modal.scss#L25-L27 ) while in web_studio we're only using 'model-header' Task-4072763 Forward-Port-Of: odoo/enterprise#72196
Original PR description
"Title Suggested features for your new model" pop-up is not well aligned. After the upgrade to bootstrap 5.3, the variable is declared in the .model ( https://github.com/odoo/odoo/blame/63e09a452d7724b6e844c5b0229c95e36f39ea61/addons/web/static/lib/bootstrap/scss/_modal.scss#L25-L27 ) while in web_studio we're only using 'model-header' Task-4072763 Forward-Port-Of: odoo/enterprise#72196
It's not always required to send a full customer address for service invoices [1] and users don't want to add unnecessary friction in their sales process. Although service invoice legislation happens on the level of the city, all cities we know of operate this way. If they don't it's ok, Avatax will then return the error instead of us. opw-4281020 [1] For Sao Paulo: Artigo 84 e do parágrafo 3º do Decreto 53.151/2012: https://legislacao.prefeitura.sp.gov.br/leis/decreto-53151-de-17-de-ma
Original PR description
It's not always required to send a full customer address for service invoices [1] and users don't want to add unnecessary friction in their sales process. Although service invoice legislation happens on the level of the city, all cities we know of operate this way. If they don't it's ok, Avatax will then return the error instead of us. opw-4281020 [1] For Sao Paulo: Artigo 84 e do parágrafo 3º do Decreto 53.151/2012: https://legislacao.prefeitura.sp.gov.br/leis/decreto-53151-de-17-de-maio-de-2012 Forward-Port-Of: odoo/enterprise#73208
…anys Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many). Before this commit there was a crash because "false" is not a valid id for the staticlist. After this commit, there is no crash, and the virtual record doesn't appear. opw-4289233 Forward-Port-Of: odoo/enterprise#73220
Original PR description
…anys Have a ir.default that sets one line into a one2many on some models. In studio, edit the form view of the main model, then navigate to edit the one2many, with the ir.default having been triggered (there is one virual line in the one2many). Before this commit there was a crash because "false" is not a valid id for the staticlist. After this commit, there is no crash, and the virtual record doesn't appear. opw-4289233 Forward-Port-Of: odoo/enterprise#73220
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice 4. The Already invoiced and Amount to invoice values are incorrect ### Explanation: When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`
Original PR description
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice…
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice 4. The Already invoiced and Amount to invoice values are incorrect ### Explanation: When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`. Down Payment lines do not have `price_total`. ### Fix reasoning: In `odoo/addons/sale`, the calculation of `amount_to_invoice` uses `account.move._get_sale_order_invoiced_amount`. https://github.com/odoo/odoo/blob/6a5a94b1cc5556371ea94a17624c534086a2a6e1/addons/sale/models/sale_order.py#L643-L647 https://github.com/odoo/odoo/blob/b5d02cc72543b36c7e5e620a3a579f15c88baed6/addons/sale/models/account_move.py#L157-L166 Modifying this code in order to only calculate using non-recurring `order_line` and adapting already existing test to include down payment possibility. opw-4052417 Forward-Port-Of: odoo/enterprise#73130 Forward-Port-Of: odoo/enterprise#72562
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header propose to scan a product - Do not scan the product by click on `+ ADD PRODUCT` - Add 1 unit of your favorite product > The header propose to scan a product or a destination location - Scan the location you had set #### > The location scan is ignored ### Cause of the issue: During the
Original PR description
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header…
### Steps to reproduce: - Enable "Multi-Steps Routes" in the settings - Add a barcode to a different location that WH/Stock - Go to the barcode > Operations > Internal Transfers > New > The header propose to scan a product - Do not scan the product by click on `+ ADD PRODUCT` - Add 1 unit of your favorite product > The header propose to scan a product or a destination location - Scan the location you had set #### > The location scan is ignored ### Cause of the issue: During the `_parseBracode` called to determine what was scanned by the barcode, a location corresponding to the barcode scanned will be found. To use this barcode, if it makes sense, the `_setLocationFromBcode` will be called in turn. However, during internal transfers, this location will only be used as a destination location under very specific conditions: https://github.com/odoo/enterprise/blob/8035abddf9991f6bfb71bb7889b703e5ed31a179/stock_barcode/static/src/models/barcode_picking_model.js#L1603-L1619 And, since we did add the product manually rather than using a scan, in our case, `this.previousScannedLines.lengt` will be null rather than positive so that the location will not be used to set the destination. opw-4201489 Forward-Port-Of: odoo/enterprise#72943 Forward-Port-Of: odoo/enterprise#72283