Daily updates from Odoo
Tuesday, February 27, 2024
34 changes
1 change
Resolved issues and error corrections
This update resolves an issue where users couldn't access product catalogs correctly when viewing them through sale orders. The fix ensures the catalog requests are made within the context of the sale order's company, preventing access errors and ensuring accurate product display. This improves the user experience for multi-company operations.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a new company; 2. switch to it via the selector; 3. create a new product specific to the company; 4. create a sale order; 5. open the catalog via a sale order line. Issue ----- Access error Cause ----- The catalog controller loses track of the current company, so `env.company` defaults to the primary `company_id` of the user. Solution -------- Use `with_company` to update `env.company` to the order's company. opw-3690226 Forward-Port-Of: odoo/odoo#153915
1 change
Resolved issues and error corrections
Overtime calculations now exclude lunch break periods from worked time, helping prevent employees from being credited overtime when regular breaks account for the extra time. Related payroll attendance tests were updated to reflect lunch periods, improving accuracy in payslip calculations.
Original PR description
Remove lunch hours from work intervals so that overtime is not calculated when it's not due tests adapted to take into account lunch period task 3217799 see odoo/odoo#116953
32 changes
Resolved issues and error corrections
This fix ensures that optional products added to recurring subscription orders have their prices automatically updated when the subscription plan is changed. Previously, only the main order products would update their prices while optional products remained at their original price, creating inconsistencies in the order total.
Original PR description
**Current behavior:** Given a portal preview of a recurring sale order with an order line (for a recurring product) and a distinct optional product which is also recurring, if the optional product is…
**Current behavior:**
Given a portal preview of a recurring sale order with an order
line (for a recurring product) and a distinct optional product
which is also recurring, if the optional product is added to
the cart and then the order is brought back into the editor
view, should the recurring plan for the order be changed, the
optional product (which is now added to the order) will not
have its price adjusted accordingly.
**Expected behavior:**
The optional product that has been added to the order will have
its price adjusted to match the recurring plan selected for the
sale order.
**Steps to reproduce:**
1. Create two distinct recurring products and assign them
subscription prices for the same recurring plan timetable
2. Create a new sale order, adding one product to the order and
the other to the optional products tab
3. Preview the sale order and add the optional product to the
cart, then return to the editor view
4. Select a new recurring plan for the sale order where each
product has a different set price than the one which is
currently displayed on the order lines
5. The product which was initially added in an order line will
have its price adjusted accordingly, while the product
which was added from the optional products section will
remain static.
**Cause of the issue:**
In sale_management, the _compute_price_unit() method is
extended such that it filters SOLs which have order options
associated with them.
**Fix:**
Override the filter method from sale_management so that lines
which are associated with recurring products will end up having
their prices updated.
opw-3698798This fix prevents the HR documents module from crashing when a required signature tag is missing after upgrading from earlier versions. The system now gracefully handles cases where the signature request tag wasn't created during the upgrade process, ensuring document signing functionality continues to work smoothly.
Original PR description
The tag `document_tag_signature_request` is used by the `sign` endpoint, but it could be missing after an upgrade from <17 due to the `forcecreate=0` in the data file.
Fixed an issue where bank statement lines were not being automatically matched to invoices when reconciliation rules had text and partner matching disabled. The system now correctly checks for exact amount matches, restoring functionality from the previous version. This ensures invoices are properly suggested during bank reconciliation even when other matching criteria are not used.
Original PR description
…fails Create a reconciliation model as follows: - Type: Rule to match invoices/bills - Match Invoice/bill with Label: False - Match Invoice/bill with Note: False - Match Invoice/bill with Reference: False - Partner is set: False Create an invoice for $900 and confirm it. Create a bank statement line for $900, with no partner set. Go to reconcile the bank statement line. Issue: The invoice is not automatically suggested This occurs because there is no check for the exact amount as in previous version opw-3648260 X-original-commit: 2de5df7 Forward-Port-Of: odoo/enterprise#57143
A styling change intended for the manufacturing work order module was accidentally affecting all modal windows across the entire system. This fix removes the unintended global impact by applying the styling only to the specific module where it's needed, ensuring other parts of the system are not affected.
Original PR description
This PR fixes an issue about an overflow property being applied to all the modal across Odoo, while it should only affect a single module. During the design and UX improvements of `mrp_workorder`, Commit[1] introduced an overflow property on the `modal-body` in order to fix a layout on modal that have hidden content that is meant to be displayed when clicking on a button. While this line provided a fix for the issue, it was not scoped to the module and would then affects the whole back-end. To fix this issue, we add the property as a utility class on the specific modal. Commit[1]: [6f9b089](https://github.com/odoo/enterprise/pull/45032/commits/6f9b08984949d7c2bd0d7ee2c8d493cd05a1289e) ticket-3671725 Forward-Port-Of: odoo/enterprise#57420
This fix resolves a bug in the Intrastat report where lines with different warnings were not being grouped correctly, resulting in duplicate entries and JavaScript errors. The update modifies how warnings are handled during the grouping process to ensure that related transactions are properly consolidated into single report lines.
Original PR description
This commit(https://github.com/odoo/enterprise/commit/26fc172004d880f5e941c78cbdc18a29d2db5134) introduced a bug. This bug is caused when several lines that should be grouped in one line have different warnings. Before this fix, it generates several grouped lines instead of one. This is causing a javascript issue where the generic unique line id is duplicated (and it shouln't be the case). To fix it, this commit removes the group by in the `_build_query_group` function and accepts null value in the `ARRAY_AGG`. When the code is checking if we have warnings, we remove the null values to only keep ids. opw-3751773 Forward-Port-Of: odoo/enterprise#57527
Fixed an issue in the Helpdesk app where removing the "Open" filter in the kanban view would not properly display resolved and canceled tickets. Previously, the view would not update to show folded stages when filters were removed, making it difficult for support teams to see the complete ticket status.
Original PR description
**Steps** to reproduce: - Go to to the Helpdesk app - Under the "Customer Care" team, click on the number of open tickets (should be 6 if the runbot instance isn't modified) - While in the kanban view, remove the "Open" filter; notice how the view doesn't update to reflect the new query ### Investigation: - the domain associated with the action `'stage_id.fold', '=', True` filters out the tickets within folded stages (Solved, Canceled) opw-3719664 Forward-Port-Of: odoo/enterprise#57315 Forward-Port-Of: odoo/enterprise#56453
This fix resolves a crash that occurred when users modified timesheet grid views (such as changing date ranges or removing filters) after viewing sample data. The system now properly loads validation date information when users transition from sample data to actual timesheet data, preventing errors and ensuring the timesheet grid functions correctly.
Original PR description
Before this commit, since 8df2e440 to avoid fetching the last validated timesheet date when the sample data is displayed, when the user changes the range of the grid view or remove a default filter and get some data. A traceback is occured because `lastValidationDatePerEmployee` is undefined. That attribute in timesheet grid renderer is indeed undefined since we did not fetch the data to populate that attribute. This commit makes sure to fetch the last validated timesheet data once the user leaves the sample data. X-original-commit: 8df2e440
This fix ensures that the source location is consistently displayed in the barcode scanning interface during picking operations. Previously, the source location information could be missing in certain scenarios, which could cause confusion for warehouse staff. This update improves the clarity and accuracy of barcode scanning workflows.
Original PR description
Backport of: https://github.com/odoo/enterprise/pull/53382/commits/60bd7a3a24aa9abd9fcf97b65c7cfd25812c3b73 opw-3764778
This fix resolves an issue where dropdown menus in embedded views (like lists and kanban boards) would not close when users clicked outside the dropdown menu. The fix simplifies the dropdown closing logic to ensure menus properly close when users interact with the embedded view content.
Original PR description
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown did't close **Issue:** Dropdown did't close when clicking within the embedded view. **Technical Reason:** There is a function called onWindowClick in the dropdown.js file, inside which we get different values in 'this.ui.activeElement' and 'this.nyActiveEl', so the dropdown doesn't close. **Before this commit:** When we insert an embedded view, and the user opens any dropdown and after that, if the user clicks within the embedded view that dropdown is not closing. **After this commit:** Removing the condition related to 'this.ui.activeElement' and 'this.myActiveEl' means that now, In the embedded view, when opening the dropdown menu, clicking within that view close the dropdown. task-3717014 Forward-Port-Of: odoo/enterprise#56366
This fix resolves an issue where VoIP calls would get stuck displaying the invitation view if a page was refreshed or closed during an incoming call. The update adds a check to ensure an active session exists before showing the invitation screen, allowing calls to display properly when reopened.
Original PR description
Task-3770997 ## Description: If the execution of the code is abruptly interrupted during an incoming call invitation (e.g. by closing the page), when the call is reopened in the softphone, the correspondence details of the call get stuck in the invitation view. This commit prevents this from happening by also checking for the presence of an actual session as a condition to display the call invitation view. ## How to reproduce: 1. Configure a database with VoIP in production mode 2. Receive an incoming call invitation and refresh the page without accepting/rejecting it 3. Re-open the call and notice that it's stuck on the invitation view :((
This update fixes a translation issue in the Belgian payroll module where individual account lines were not being translated correctly. The fix ensures that payroll documents and reports display in the correct language for Belgian users, improving the user experience and compliance with local requirements.
This fix resolves an issue where approval notifications were not being sent to the correct person in complex multi-step approval workflows. When multiple approval rules needed to be validated in sequence, the final approval step was not receiving its notification activity. The fix ensures that all previous validations are properly recognized when processing subsequent approval steps, allowing the complete workflow to function as intended.
Original PR description
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3:…
Have an approval flow rather complex in four steps: - rule 0: notification order 1, exclusive - rule 1: notification order 2, exclusive - rule 2: notification order 2, exclusive - rule 3: notification order 3, exclusive, has a responsible Obviously, each validation should be done by a different user (and not an admin), because all rules are exclusive. Also, each rule has a responsible in the example below, but really only rule 3's is part of the real use case and is the object of the fix. Validate 0: 1 and 2 receives an activity Validate 1: activity of 1 is removed validate 2: activity of 2 is removed, 3 receives an activity (<=====) Before this commit, 3 did not receive an activity. This was because, in this flow the rule 3 is evaluated for validation because every rule before it had been validated. However, in that part of the code, we ensure that no rule below it in notification order is not validated, but we do it in the context of the current user. So, when validating rule 3, we couldn't see the validations for at least of previous rule that another part of the code had seen before. After this commit, the rule 3 receives an activity, and the whole flow works as expected. opw-3752133
Fixed a display issue where the validate button was missing from the timesheet pivot view. The fix involved updating the code structure to properly extend the necessary components, ensuring the validate button now appears correctly for users reviewing timesheets in pivot format.
Original PR description
**Before:** In the modified code, parts of the PivotController have been moved to PivotRenderer. However, the 'button template' is not extended in the pivot view, leading to issues rendering the validate button. **After:** By extending the correct class (PivotRenderer instead of PivotController) in the `TimesheetValidationPivotController`, we now have access to methods that were previously unavailable. Additionally, extending the `buttonTemplate` allows us to access the validate button, resolving the rendering issue. This modification ensures that the TimesheetValidationPivotController now extends PivotRenderer, allowing it to access the necessary methods and resolve the rendering issue for the validate button. **Task**-3623493 Forward-Port-Of: odoo/enterprise#53165
This fix resolves a display problem in the Knowledge app's Calendar feature where items without titles would overlap and prevent proper editing. The solution ensures that calendar items always have a placeholder title space, allowing users to add or modify titles without visual conflicts or spacing issues.
Original PR description
Issue: When adding a new Calendar Item without a title, the item does not allocate the required space, causing it to appear slightly under the calendar item. Additionally, if any item is moved to the top of the calendar, it overlaps the title placeholder, preventing title modification. Steps to Reproduce: 1. Install Knowledge. 2. Create a new article and select 'Build an Item Calendar'. 3. Proceed without entering a title. 4. Type anything below the created Calendar and move it to the top of it. Solution: Modify the 'onBuildItemCalendarBtnClick' function to utilize a "computed" title rather than directly using the name. This ensures that a placeholder title is always present, allowing for later deletion or modification. opw-3725805 Forward-Port-Of: odoo/enterprise#56423
This fix resolves an issue in the Belgian payroll system where line names and worked day names were being incorrectly mixed together. The correction ensures that payroll records properly distinguish between different types of payroll lines and worked days, improving the accuracy of payroll calculations and reporting for Belgian employees.
This fix prevents the "Force Source Location scan" setting in delivery operations from being automatically reset to its default value whenever the barcode scanning module is updated. Now, when users customize this setting, their preference will be preserved across system updates, eliminating the need to reconfigure it repeatedly.
Original PR description
Before this commit, the "Force Source Location scan" setting of the delivery picking type was always reset on "Mandatory Scan" every time the `stock_barcode` module was updated. This behavior is not wanted, if the user changes the setting, we don't want to update it again. Forward-Port-Of: odoo/enterprise#57499
This fix resolves an issue that prevented users from successfully unsubscribing phone numbers from SMS communications. Users can now properly blacklist numbers and opt out of receiving SMS notifications. The fix corrects a technical parameter issue in the phone number formatting process.
Original PR description
**Description of the issue/feature this PR addresses:** Before this PR: Users encountered errors when attempting to unsubscribe a phone number from receiving SMS. After this PR: Now, issue has been fixed, allowing users to successfully blacklist numbers and opt out of receiving SMS notifications. issue raised from - (https://github.com/odoo/odoo/commit/adfdf5ab33e719a55f65e2d9ff34ff265fe1b579) task-3651401
This fix corrects an issue where the wrong analytic account information was displayed when users navigated between different assets using navigation arrows. The system was showing the previous asset's analytic data instead of the current one. This ensures users see the correct financial allocation information for each asset they view.
Original PR description
Steps to reproduce: - activate analytic - Create two assets with different analytic distribution - Open the first asset - Navigate to the second asset via the arrow Issue: The analytic account will not be displayed correctly Cause: In `jsonToData` the record used is the previous one. Solution: Use the record that will efectively be displayed opw-3698383
This fix removes a restriction that prevented granting badges to users who don't have an associated employee record. Previously, the badge system required users to have employee profiles, which limited who could receive recognition. Now any user in the system can be awarded badges, making the gamification feature more flexible and inclusive.
Original PR description
When hr_gamification is installed, it's not possible to grant badges to users that don't have associated employees. Expected behavior: we should be able to grant badges to any users. This is because user_id was related field with employee_id. We remove that dependency. task - 3593382
Salespeople can now successfully confirm sales orders that include products with expense policies without encountering permission errors. The fix allows the system to automatically generate required analytic accounts for expense products while bypassing unnecessary access checks that were preventing confirmation.
Original PR description
Before this commit, when a salesman user without any access in other apps (just has the `sales_team.group_sale_salesman` group) creates an SO and adds a SOL for a product with…
Before this commit, when a salesman user without any access in other apps (just has the `sales_team.group_sale_salesman` group) creates an SO and adds a SOL for a product with `expense_policy='sales_price'` and then confirm the SO, he will got a traceback because he does not have access to `analytic.account.line` model. The reason is because an analytic account has to be generated for the SO since there is an expense product in its SOLs and so during the generated of analytic account a check is triggered to be sure the company set on that analytic account is correct. This commit adds a sudo before calling the search method in `analytic.account.line` model to do the check without checking the access right since the user does not really want to read the analytic account line. Steps to reproduce ================== 1. Log in as Salesman user (without other access) 2. Create a product and the expense policy to Sales price. 3. Create a SO and add a SOL with that product 4. Confirm the SO Expected Behavior ================= The SO should be confirmed without any issue (and an analytic account should set on that SO) Actual Behavior =============== Traceback is occured because the user cannot access to `analytic.account.line` model. Follow-up task-3256865
This fix corrects how the web editor handles formatting attributes when changing HTML tags in lists. Previously, attributes were being incorrectly removed from list items. Now, attributes are properly preserved for all tags except list items, ensuring that formatting and styling information is maintained when users edit content in the editor.
Original PR description
Commit [1](https://github.com/odoo/odoo/commit/fcb3846226007c31f60aecad3a92fe643540780e) changed the behavior of `setTagName` to only carry the attributes of paragraph related elements. Ideally, this should not carry the attributes of `<li>` element only. [1]: fcb3846 task-3764154 Forward-Port-Of: odoo/odoo#155151
This update fixes two text deletion problems in the Odoo content editor. First, deleting forward on emojis now works correctly instead of only removing half the emoji. Second, invisible spaces at the beginning of lines are no longer deleted one character at a time when using forward delete. These fixes improve the editing experience when working with special characters and formatted content.
Original PR description
Issue 1 : ======= Delete forward on emoji dosn't work ### Steps to reproduce the issue: - Go to knowledge - Add an emoji and put the cursor on the left of the emoji and delete forward - only half of…
Issue 1 : ======= Delete forward on emoji dosn't work ### Steps to reproduce the issue: - Go to knowledge - Add an emoji and put the cursor on the left of the emoji and delete forward - only half of the emoji gets deleted ### Solution: We need to get the correct offset and correct charsize because not all of the items of the sliced string had char size equal to `1`. So we slice the string and get the offset corrosponding to the target offset and of course we need to handle the directions differently Issue 2: ====== Invisible whitespaces at the start gets deleted by one by one with delete forward. ### Steps to reproduce the issue: - Go to knowledge - Add any text - Make sure you have an empty line before it - Change the html of the added text and add some spaces at the start (this is the easiest way to reproduce it) - Go to the line before and keep deleting forward - The invisible spaces will be deleted one by one. ### Solution: When the selection is at the start of the node and it contains whitespaces, `parentState` whill have undefined node when deleting forward since we are at the first leaf. We need to keep deleting forward with the text node instead of parentElement because calling delete forward with the parent will do a 1 delete backward call from the specified offset and it will not propagate forward anymore. task-3629743 Forward-Port-Of: odoo/odoo#155378 Forward-Port-Of: odoo/odoo#150224
This fix prevents sales order line prices from being unexpectedly recalculated when saving changes to other fields like scheduled dates. The issue was caused by minor floating-point precision differences in quantity values that the system incorrectly interpreted as user changes, triggering unnecessary price recalculations. This ensures that manually set prices remain stable when making other updates to the order.
Original PR description
Steps to reproduce * Create a new SO * Add a new line with a storable product and 15.12 as quantity * change the price to X * Save and confirm * Set a scheduled date (Other info tab) * Save -> The price of the SOL is recomputed. Cause Because of floating point issues, the value returned by the onchange for the product_uom_qty field is 15.1200000....1, therefore being considered in the client-side as having been changed by the onchange. The value is then sent to the server on save, triggering a recomputation of the SOL prices. Until there is a clear solution in the framework, this commit drops 'unmodified values' for the product_uom_qty field, using an existing check, and only if there is only one updated line in the write call. opw-3670318 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155271
This update fixes how channel mentions work in Odoo's messaging system. Users can now mention channels, chats, and groups reliably, even when group restrictions are in place. The fix also improves performance by removing unnecessary data requests in live chat conversations where channel mentions aren't applicable.
Original PR description
1. channel mention should work for channels, chats, and groups, even if there is a group restriction for the channel. 2. channel mention in livechat is disabled because the visitor can't get access to the channel. 3. remove the fetch and search for channel mentions in livechat so that there is no extra rpc call for unuseful data. 4. add a test for the channel mention in thread. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where contact images in the kanban view were being cropped too aggressively, causing faces to be cut off or images to appear pixelated. The change constrains images to a maximum height and centers them, allowing more space for contact information tags while maintaining image quality and readability.
Original PR description
On the contact kanban view, add as much tags as possible. The point is to make the right hand part of the kanban card as tall as possible. Before this commit, the image (on the left hand side) of the individual partner was taking all the space in the y-axis, which was on purpose, but the cropping of the image made it so that the image lost is sense: a face was too much cropped, or, if the image did not have sufficient pixel density, it was pixelized. What is specific to 17 that is barely applicable in earlier versions, is the changes in the display of many2many tags in the kanban record: they now take more space and at a faster pace. After this commit, we constrain that image to a maximum height and centering it. opw-3748585 opw-3751016 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
The validate button was not appearing when users opened the Pivot View in Timesheets. This fix restores the missing button by improving how the Pivot component handles button templates, making it more flexible for different use cases. Users will now see the validate button as expected when working with pivot views.
Original PR description
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes…
**Steps:** - Open Timesheets - Go to To Validate > All Timesheets - Pivot View is rendered **Issue:** The validate button is not rendered when the pivot view is loaded **Solution:** The changes introduced in these files are aimed at enhancing the customization and flexibility of the Pivot component in the web application. By adding the buttonTemplate prop to the PivotController and utilizing it in the PivotRenderer template, developers can dynamically choose the template for rendering buttons within the pivot view. This change is particularly beneficial for scenarios where different button layouts or styles are required based on specific use cases or user preferences. Additionally, the introduction of a default value for buttonTemplate in the PivotView configuration ensures a smooth fallback mechanism if a custom template is not explicitly provided. Overall, these adjustments contribute to a more adaptable and extensible Pivot component, catering to diverse application requirements. **Task**-3623493 Forward-Port-Of: odoo/odoo#147054
When verifying EU VAT numbers, the system now displays error messages from the VIES service instead of silently failing. Previously, users would incorrectly think a VAT number was invalid when the service simply couldn't process it. This fix ensures users are properly informed when VAT verification encounters technical issues like service unavailability or timeouts.
Original PR description
Steps to reproduce: - Activate "Verify VAT Numbers" option in the Settings - Go to Contacts and create a new one - Enter a valid EU VAT Number Issue: It happens that VIES service could not process…
Steps to reproduce: - Activate "Verify VAT Numbers" option in the Settings - Go to Contacts and create a new one - Enter a valid EU VAT Number Issue: It happens that VIES service could not process the VAT number for some reason and returns an error. That error is silently caught without notification to user and "Intra-Community Valid" field is set to False. The user will wrongly think that the VAT number is not valid, but it hasn't been processed at all. Here's the list of the potential errors returned by VIES service: - INVALID_INPUT - INVALID_REQUESTER_INFO - SERVICE_UNAVAILABLE - MS_UNAVAILABLE - TIMEOUT - VAT_BLOCKED - IP_BLOCKED - GLOBAL_MAX_CONCURRENT_REQ - GLOBAL_MAX_CONCURRENT_REQ_TIME - MS_MAX_CONCURRENT_REQ - MS_MAX_CONCURRENT_REQ_TIME Solution: Log a note with the error (as it is done for some other error) to warn the user that the VAT number hasn't been processed. opw-3687968 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153196
Fixed an issue where customer names were missing from reprinted receipts in the loyalty program feature. Now customers will consistently see their name on all reprinted receipts, matching standard receipt expectations regardless of loyalty program participation.
Original PR description
Before this commit, due to a recent change, the customer name was not being printed on reprinted receipts. This was inconsistent with user expectations, as they expected to see the customer name on the receipt, regardless of whether a loyalty program was in place or not. With this commit, we ensure that the customer name is always printed on reprinted receipts, aligning the system behavior with user expectations. opw-3760165 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects an issue where the return wizard was showing the wrong quantity to return. When a delivery was partially fulfilled (e.g., delivering 6 units instead of the original 10), the return process was incorrectly showing the original quantity rather than the actual delivered amount. This ensures customers and warehouse staff see the correct quantity that needs to be returned.
Original PR description
**Steps to reproduce the bug:**
- Create a delivery picking:
- product: P1
- Qty: 10
- Mark as todo
- Set “Quantity” to = 6
- Validate the picking without creating a backorder
- return the picking
**Problem**:
The qty to return is 10 instead of 6
opw-3726157This fix prevents a translation bug where removed terms could have their translations incorrectly reused by different terms during the typo fixing process. The system now only applies typo corrections when the matched term existed before the change, ensuring translations stay accurate and meaningful.
Original PR description
for model_terms translated fields, for sake of typo fixing feature if a term is removed after write its translations might be reused by another close term which has totally different meaning this fix removes the typo fixing if the matched closest term exists before write 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#154868
Background videos in website cover snippets were not displaying correctly when viewing the site in right-to-left languages like Arabic or Persian. This fix updates the video positioning code to work properly regardless of language direction, ensuring videos display correctly on mobile devices in all supported languages.
Original PR description
Background videos' dimensions are adapted according to the screen size. This could lead to the video not showing in RTL languages, because the computed position was coded for LTR languages. This commit replaces the `left` and `top` CSS properties with logical properties to account for language directions. Steps to reproduce: 1. Add a Cover snippet 2. Add a video to it (use any sample videos from the selector) 3. Save > Check mobile view, video shows fine. 4. Add a Right to Left language to the website (Persian, Arabic...) 5. Switch to the RTL language > Check mobile view => video doesn't display properly. opw-3688660 Forward-Port-Of: odoo/odoo#154247
This fix ensures that website sitemaps always display in the default website language, regardless of which language version of the site a visitor is viewing. Previously, sitemaps could appear in translated languages (like French) when accessed from non-default language pages, which could cause confusion for search engines and users. This is now corrected to maintain consistency.
Original PR description
This commit prevents the sitemap from being translated when a website is available in multiple languages. The sitemap should always be in the default language of the website. Steps to reproduce the bug: - Set up a website in English and French - Navigate to the French version of the website (/fr) - Access the sitemap (/sitemap.xml) => The sitemap appears in French but should be in English. Note: There is a cache for the sitemap. It is not regenerated if it has been generated within the last 12 hours (see `SITEMAP_CACHE_TIME`). task-3743970 Forward-Port-Of: odoo/odoo#154993