Daily updates from Odoo
Thursday, January 25, 2024
40 changes · 17.0
Enhancements to existing features
The partner selection screen in the Chilean EDI POS module has been redesigned with a cleaner, more user-friendly interface. This improvement enhances the visual layout and usability of the partner editor component, making it easier for POS operators to select and manage customer information during transactions.
Original PR description
Before  After 
Database indexes have been added to the subscription plan and subscription state fields to improve system performance. This optimization makes searching and filtering subscriptions faster, resulting in better user experience when managing subscription data.
Original PR description
taskid: 3682434
This update enables custom website snippets to maintain their translations when saved and reused. Previously, when users translated snippet content and saved it as a custom snippet, those translations were lost. Now translations are properly preserved and applied when the custom snippet is used on other pages, improving the experience for multilingual websites.
Original PR description
This commit adds translation capability to custom snippets. Before this commit, the custom snippet was not translate friendly: 1. Neither when saving a block as custom snippet 2. Neither when dropping a custom snippet into a page. This was a known limitation for years. But now it's time to make it work. Step to reproduce (part 1): - Enable french - Drag & drop Title snippet in a page - Translate the Title - Save the block as custom snippet -> Go in the backend view of this custom snippet, in debug, there is no translation that followed the title. Step to reproduce (part 2): - Following previous steps, now add the translation manually on the custom snippet view - Back in a page in edit mode, drag & drop this custom snippet in the page - Switch to french -> The title is not translated, the drag & drop copy code but no translations task-3375518 opw-3242100 Forward-Port-Of: odoo/odoo#150561 Forward-Port-Of: odoo/odoo#125444
Resolved issues and error corrections
This update fixes multiple issues in the barcode scanning system for manufacturing orders, including improved product handling, better user interface for scrap operations, and corrected filtering of manufacturing orders. The changes streamline the manufacturing workflow by ensuring products are correctly categorized, preventing duplicate entries, and providing clearer user feedback during barcode scanning operations.
Original PR description
1. Scrap page is replaced by the 'Add Scrap' Dialog. 2. When the user scan a product from the byProduct registration page, add it as a by product, not a component. 3. Add 'To Close' to the default active filters when opening MOs in the barcode app. 4. When I produce a serial, and I specify a serial number manually, the components are consumed. 5. Remove Traceback when cancel transfer action is discarded. 6. Renamed the 'Cancel Transfer' into 'Cancel Manufacturing Order' and its notification to 'The manufacturing order has been cancelled.' 7. Do not allow to add a component/byProduct that is the same as the final product. 8. Allow production of product without BoM 9. Scanning a Manufacturing Operation Type triggers the creation of a MO rather than the creation of a Picking 10. Scan SCRAP should open scrap view Task 3612790
This fix improves the speed of Chilean POS checkout by eliminating unnecessary PDF generation for 'boleta' invoices, which was causing 4-5 second delays per transaction. Users can still generate and print invoices from the backend when needed. The change only affects the Chilean localization module and does not impact other regions.
Original PR description
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf…
## Issue For the Chilean localisation of POS, all orders generates the pdf of the invoices, sadly this is a slow process (generating the pdf for 1 invoice takes around 4-5secs) ## Cause A wkhtmltopdf bottleneck, since odoo/odoo@19916059c519c65083a05b270026420f8e41a062 we "Send and Print" the newly created invoices, which generates the pdf. Some localizations have this as a requirement, but Chili apparently is not one of them. ## Fix There are 2 types of invoices (boleta/factura), but the POS button "to_invoice" at order checkout was used as a toggle between the types of invoices, instead of a choice to invoice or not. And since the generation of the invoice is strongly coupled with the generation of the pdf, I've added a context key to skip the pdf generation during POS checkout. The user can still "Send & Print" the invoice from the backend. The key is present when we *don't* select the invoice option at checkout (so for boleta invoices), for factura the invoice's pdf is created in sync. ## Affected versions 17.0 up to master ## Reference opw-3610333 Community PR: https://github.com/odoo/odoo/pull/148159
This fix enables proper translation of appointment-related text on your website. Previously, translated content like "Select a time" was not displaying in the selected language even though translations were available. The issue has been resolved by ensuring the appointment module is properly loaded when the website translation system is accessed.
Original PR description
Currently some terms we not being translated besides having the term in the .pot file and the translation in the .po files. Steps to reproduce: ------------------- * Go to **Setting** * Add a language (french for example here) * Enable to translate to your website * Go to **website** * Select apointment * Select any appointment * Change the language of the website You can observe that the line *Select a time* is not being translated. When selecting **Translate**, you can observe that the line is not highlight in yellow or green. Why the fix: ------------ When the route `/website/translations` is called, the modules loaded do not include appointment. opw-3671043
Fixed an issue where copying template content would paste HTML code as literal text instead of clean text. When users clicked the copy button and pasted the content into text fields, they would see raw HTML tags instead of just the text. This update ensures that copied content pastes as plain text without HTML formatting, providing a better user experience.
Original PR description
This commit modifies the text/plain blob used for the template behavior (now called the Clipboard) because it was using the innerHTML instead of text. This enabled the user to copy a string containing HTML tags instead of just text that was pasted inside of the small chatter. When the user click on the copy button we write inside of the user's clipboard a blob that contains a ClipboardItem. This Object enables us to choose which data should be pasted depending on a MIME Type. Here the `text/plain` and `text/html` were storing the same HTML. The issue is that when pasting inside an input that uses the `text/plain` type the user outputs the HTML as litteral string tags and all. Which is not ideal for the user as it would prefer to have the text content instead of the HTML. Now this blob will contain the innerText of the template reverting it to its default behavior. task-3691185
This fix prevents optional Belgian financial reports (Balance Sheet and Profit & Loss variants) from automatically disabling themselves when the system is updated. Previously, when users manually enabled these reports, they would be turned off again during module updates. Now these settings are preserved during updates, respecting user preferences.
Original PR description
The assignation of the "active" field to False should be done in a noupdate block. Otherwise, a report manually enabled by a user will disable itself at module update (hence, also at upgrade).
Subscription products with multiple pricing periods (monthly, 6-month, yearly) were incorrectly displaying only "per month" on the website regardless of which variant was selected. This fix corrects how the system updates the pricing period information when customers change product variants, ensuring the correct billing cycle is shown for each option.
Original PR description
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month…
**Issue Description**: When creating a subscription product that has time-based pricing and options. The product on the website simply displays a recurring monthly period, rather than the six-month and annual periods as configured. This only happens in 17.0 and higher. The problem was happening because this patch wasn't calling. https://github.com/odoo/enterprise/blob/4c577804b4f6fadb1d606896a3c124909b85ab6b/website_sale_subscription/static/src/js/variant_mixin.js#L14-L28 That's because of the fact that there's https://github.com/odoo/odoo/blob/851eb198433d4fd6f72100568be3bf57a4803064/addons/website_sale/static/src/js/sale_variant_mixin.js#L82 https://github.com/odoo/odoo/blob/851eb198433d4fd6f72100568be3bf57a4803064/addons/website_sale/static/src/js/sale_variant_mixin.js#L101 the `this` function is not patched, because of some new changes in the patch function in 17.0 **Steps to Reproduce**: 1. Create a new subscription product in the `Subscriptions` app. 2. In the `Attributes & Variants` tab, add a new attribute `periods` with values such as `Monthly`, `6 Months`, `Yearly`. 3. In the `Recurring Prices` tab, add each variant of the product (`Monthly`, `6 Months`, `Yearly`) along with their corresponding `Recurring Plan` and `Recurring Price`, then save. 4. Click the `Go to Website` smart button and try to change the product variants. 5. Observe that the product is always labeled as "per month" regardless of the selected variant. **Proposed Solution**: Instead of `this` function we will manually call `VariantMixin._onChangeCombination`. opw-3654134
This update fixes the mobile display of the Documents & Analytics section in project settings. Users on mobile devices will now see properly aligned form fields and labels, with the documents feature description no longer overflowing. This improves the user experience when managing project documents on phones and tablets.
Original PR description
Steps: - In mobile install project - Project.project form view - Go to the project settings - Documents & Analytics - The fields are not correctly aligned with their labels in mobile view Issue: - The description of the 'documents' feature overflows and the inputs of the 'workspace' and 'default tags' fields are not correctly aligned with their labels in mobile view Cause: - Missing some of the bootstrap classes , So that's why the problem will be raised in mobile view Fix: - By Adding some of the bootstrap classes ,the problem will be solved task-3550702 Forward-Port-Of: odoo/enterprise#54800 Forward-Port-Of: odoo/enterprise#50125
The image cropping tool in the Report Editor now displays in a cleaner overlay window instead of appearing inside the editing frame. This fix improves the user experience by making the cropping tool easier to see and use when editing report images.
Original PR description
Before this commit, spawning the cropping tool from the Wysiwyg's toolbar made it appear within the iframe, without any coherence whatsoever regarding the display or usability. After this commit, we manually spawn the image crop tool in an overlay of the main window. IT is much clearer UX wise and cleaner technically. Forward-Port-Of: odoo/enterprise#54813
This fix resolves an issue where the EC Sale List code filter was not visible in sales reports that don't have variants. The problem was caused by the filter's location in the interface being tied to a page element that doesn't always exist. By updating how the system finds this filter, it now displays correctly for all report types.
Original PR description
Before this commit, the filter for EC Sale List codes was invisible if the report doesn't have a variant. It was caused by the xpath based on a div which can be not present in the DOM. When this div is not present, the filter doesn't appear. no task id
This fix resolves an issue where accounting PDF reports were displaying incorrectly when using right-to-left languages like Arabic. Columns were appearing out of bounds because the PDF generation tool wasn't properly handling text direction. By adding text direction settings to the PDF report template, the layout now displays correctly for all language types.
Original PR description
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting…
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatically reduce the font size of text in order to fit content within the specified page width. We use this option to help prevent content from overflowing the designated page boundaries. However, it seems that "smart shrink" doesn't take into account the text direction unless it is set on the `body` or `html` tag specifically. opw-3472357 opw-3567655 opw-3520084 opw-3683210 opw-3684178 Community PR: odoo/odoo#146470 Forward-Port-Of: odoo/enterprise#55085 Forward-Port-Of: odoo/enterprise#50530
Fixed a crash that occurred when activating the rainbow celebration effect on buttons in Web Studio and then customizing the image. The system now properly handles the effect settings as objects instead of simple true/false values, allowing users to successfully customize button effects without errors.
Original PR description
On a CRM lead in studio, activate the rainbow man on the "Won" button. Change the image.
Before this commit, there was a crash, because activating the rainbow man put the effect attribute on the button to "true".
Adding an image on top of that crashed because the code expected an object.
Given the empirical specs at action_service.js:doActionButton and in effect_service.js, the "effect" attribute doesn't have the expected effect if it is "true". We choose then to set the "effect" attribute on a node
- to "False" when it is supposed to be deactivated,
- a empty object "{}" if it is to be truthy, but displaying defaults. This object is enriched when customizing details in studio.
After this commit, there is no crash anymore and one can customize the image in the rainbow man.
opw-3692982
Forward-Port-Of: odoo/enterprise#55045This fix corrects the order of parameters used when generating QR codes for Mexican invoices. The parameters were being sent in the wrong sequence, causing QR codes to be invalid when scanned. The fix reorders the parameters to match the official Mexican tax authority (SAT) documentation requirements, ensuring customers can properly scan and verify invoice QR codes.
Original PR description
Current behaviour: --- When generating the QR code url or the xml document of an invoice, the arguments are, in order: re supplier_rfc rr customer_rfc tt amount_total id uuid Expected behaviour: --- Should be id, re, rr, tt Source: http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Documentacion_tecnica.pdf (Pages 67-68) Steps to reproduce: --- 1. Set up l10n_mx 2. Head to Invoicing 3. Sign an invoice 4. Print the invoice 5. Scan the QR code 6. URL is wrong Task link: http://www.odoo.com/web#id=3650556&model=project.task opw-3650556 Forward-Port-Of: odoo/enterprise#54671 Forward-Port-Of: odoo/enterprise#53613
This update improves how Odoo handles caching when importing industry-specific modules from the apps server. The fix reorganizes the code to properly cache data in JSON format, ensuring the module import process works correctly with industry information without requiring workarounds.
Original PR description
Instead of makchanging the type of lists to make an ormcache that works, we'v extracted the function that call the server apps.odoo.com to pass it the payload in json (as it will be sent to the server), and use the payload value as ormcache
This fix resolves an issue where sale order references would disappear when a user settled a sale order in POS restaurant, navigated away from the table, and then returned to it. The problem was that the sale order origin information was not being properly loaded, and this fix ensures it persists correctly throughout the transaction flow.
Original PR description
Before this commit, if the user tried to settle a sale order in PoS restaurant, then went back to floor and then returned to the table, the sale order reference will disappear. The problem is that the `sale_order_origin_id` is not loaded. opw-3550351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145428
This fix resolves a system error that occurred when employees had no working hours defined. The system now automatically uses the company's default calendar when an employee's working hours field is empty, ensuring the Time Off app and leave calculations work properly. This also improves handling of employees with multiple contracts using different calendars.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Employees app as admin; 2. clear the "Working Hours" field & save; 3. go to Time Off app. Issue ----- Odoo Server Error. Cause ----- Commit 8f87e102a95412aa7dd1b0ce07365d9d3bbdba6a added the `_get_consumed_leaves` method to `hr.employee` and the `get_allocation_data` to `hr.leave.type`, both call on `resource.calendar` methods with `ensure_one()` enabled. The `resource_calendar_id` field is not required for employees, so an error occurs when these methods are used on an employee with undefined working hours. Solution -------- Default to `company_id.resource_calendar_id` where a calendar is expected. Also fixes a potential issue in `hr_contract` when getting attendances between a time interval that includes multiple contracts using different calendars. opw-3665412
This fix resolves an issue where attachment previews were not displaying correctly in expense reports and required unnecessary system requests. The system now properly tracks and displays the main attachment from individual expenses at the report level, ensuring previews appear immediately and persist after page refresh.
Original PR description
## Issue Main attachments on expense sheets was never correctly set, leading to missing attachment previews in the hr.expense.sheet form view, and unnecessary RPC requests to…
## Issue Main attachments on expense sheets was never correctly set, leading to missing attachment previews in the hr.expense.sheet form view, and unnecessary RPC requests to `register_main_attachment`, because the attachment was never set. ## Steps to reproduce - Install Expenses - Create 2 different expenses with different attachments - Create a report from those 2 expenses, save it - Notice there is nothing in the preview for the attachments, but if you zoom in or zoom out the page, then you can see it. Also swiping on the list of attachments isn't persistent, once you refresh the page, the main attachment we selected lastly is lost. ## Cause There are 2 main issues: - `hr.expense.sheet` has `message_main_attachment_id`, but it's never set. - When writing an attachment via `register_main_attachment`, we pass only the id of the attachment. Then in the backend, the related record is based on the model of the attachment, but the attachment is linked to `hr.expense`, not `hr.expense.sheet`. Therefor we re-write the same attachment on the record we read the attachment from. And then the frontend will continue to call `register_main_attachment` everytime it tries to find the attachments linked to the sheet, but it's never done. ## Fix - Add a compute to initially set the value of the `message_main_attachment_id` based on the spec "we take the first line that has a main attachment (attachment if no main attachment) and we set it on the sheet" - The `hr.expense.sheet` now maintains a copies of the attachments linked to it's expenses, for proper ACL and functionality of `register_main_attachment`. ## Affected versions 16.0 up to master = saas-17.1 ## Reference task-3572440 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150430 Forward-Port-Of: odoo/odoo#142029
Fixed an issue where users couldn't create tasks by clicking on dates in the mobile calendar's monthly view. The fix removes a technical restriction that was preventing the create action from working in this specific view mode. Users can now successfully create calendar tasks directly from the monthly view on mobile devices.
Original PR description
issue: - calendar mobile view (month) > pressing on a day or timeframe to create a task doesn't do anything if the view does not have the "day" calendar scale set up Fix: - We are removing the condition preventing the renderer to use the createRecord callback when the view is Mobile and in monthly scale So now a record will be directly created when a user clicks on a timeframe in monthly view even if he's in mobile view Task-3677216 15.0 PR: https://github.com/odoo/enterprise/pull/54386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150493 Forward-Port-Of: odoo/odoo#148754
The clear format button was missing from the snippet editor toolbar in recent versions. This fix restores the button by properly managing its reference in the toolbar, ensuring users can clear text formatting when editing content snippets.
Original PR description
**Current behaviour before commit:** In v16.0 and above clear format button was missing from snippet toolbar. This happens because when `_addToolbar` method is called second time `removeFormat` button can't be found in toolbar as it was appended to `$title`. **Desired behaviour after commit:** Now clear format button is getting appeared in snippet toolbar by using `this._$removeFormatButton` property. task-3638147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150182 Forward-Port-Of: odoo/odoo#147045
This fix resolves an issue where newly created projects in the timesheet configuration were not automatically assigned to the current company. The solution adds a default company attribute to the project field, ensuring that when users create a new project through the timesheet settings, it will automatically be associated with their current company.
Original PR description
Steps to reproduce: - install timesheets module - install all related timesheets bridge modules - open timesheets module - click on configuration - click on settings - under the timeoff, create a new project and click on create and edit Issue: - the current company is not set by default on the newly created record Cause: - the project id did not have any default company id attribute Solution: - if we gave a default attribute to the project id field then the issue will be solved task-3607053 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#144479
Gift card reports were incorrectly displaying a test expiration date (2023-12-31) even when no expiration date was set for the gift card. This fix ensures the expiration date only appears on reports when it's actually configured, making the reports consistent with other loyalty program displays and email templates.
Original PR description
Problem: The test value for the expiration date was being shown on gift card reports that don't have expiration dates. Purpose: The expiration date should only be shown if it's set for the gift card code. It will be consistent with loyalty_report and the email template mail_template_gift_card in which both conditionally displays the expiration date. Steps to Reproduce on Runbot: 1. Install Sales 2. Settings > Sales > Enable Discounts & loyalty programs 3. Navigate to Sales > Gift cards and create/generate a gift card code with no expiration date 4. Print the gift card report and the report will show the expiration date of 2023-12-31 opw-3686110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where editing a sale order to reduce product quantities to zero would create an unwanted extra move in the warehouse picking. The problem occurred because package-level reservations weren't being properly cleaned up when the associated inventory moves were removed. Now, package reservations are automatically removed when their last related move is deleted, preventing duplicate moves from being created.
Original PR description
Steps to Reproduce: - Activate packaging - Create a storable product update on hand qty 1 package: "PACK6" - Create a sale order with the product qty 1 - Confirm the order, picking will have a package already assigned - Edit the sale order and set the product quantity to 0 Bug: a new move will be created with negtaive quantity and merged with original (correct behaviour) but when the picking is confirmed an extra move will be created due to the picking still having a package level set Fix: unlink the package level when its last linked SML is unlinked opw-3597188 Forward-Port-Of: odoo/odoo#147458
This fix corrects how product costs are calculated when selling nested kits (products made of other kits) through the Point of Sale system. Previously, the system was incorrectly counting some kit components twice, resulting in wrong expense amounts in accounting records. The fix ensures accurate cost tracking for complex product structures.
Original PR description
Steps to reproduce:
- Create the following subkits boms
F-> SK1 -> A
-> B
SK2 -> C
-> D
- Set all these products to be available in pos and have AVCO automated valuation with A,B,C and D having a cost of 5$
- Sell F in pos creating an invoice
- In accounting check the expense account (cost of goods) wrong cost
Bug:
´comp[1]['product']´ refers to the kit product of the last children boms (SK1 and SK2 in this case) which would then each be counted twice instead use ´comp[0].product_id´ (the components of the child boms)
also fixed total_cost computation for pos lines which would filter out all the subkits moves
opw-3676642
Forward-Port-Of: odoo/odoo#144268This fix ensures that SMS messages sent through the notification system now properly respect scheduled delivery dates, just like email notifications do. Previously, SMS messages were being sent immediately regardless of any scheduled date specified. This update makes SMS behavior consistent with the rest of the notification system and improves the reliability of scheduled communications.
Original PR description
When a 'scheduled_date' is given to posting API notifications are delayed. They are send using a cron running on a schedule model. However SMS are not respecting this parameter. This is now fixed.
This update fixes three issues with the image cropping feature in the web editor used for reports. The fixes ensure that already-loaded images can be cropped properly, images load correctly in iframes with special attributes, and the cropping tool works reliably when editing content in embedded frames. These improvements make the image editing experience more stable and user-friendly.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150384
Users were unable to submit their account information when the country field was locked from editing due to VAT restrictions. The system was incorrectly reporting that the country field was empty even though a value was selected. This fix ensures the country value is properly included when the form is submitted, allowing users to complete their account updates.
Original PR description
Since 1be6866b15ebf76e197d9135a7b737640cdf14f6, when VAT can't be edited, the country_id select field is disabled. Disabled fields aren't submitted in the POST query, which causes an error `Some required fields are empty`, with the Country field being highlighted even if a value is selected. With this commit, when the user cannot edit their country, the value is forced into the POST data so that it is found.
PDF reports in right-to-left languages like Arabic were displaying with missing columns and content out of bounds. This fix adds proper text direction settings to PDF report templates so that the automatic text sizing feature works correctly for all languages, ensuring all content displays properly on the page.
Original PR description
### Summary wkhtmltopdf's "smart shrink" option does not work properly with rtl languages, unless the direction is specifically set on the body/html tag. ### Steps to reproduce * install Accounting and the Saudi Arabia localization * switch the Saudi Company * language to Arabic * print the General Ledger You should see that a few columns do not appear on the PDF. They are out of bounds. ### Cause The "smart shrink" option in `wkhtmltopdf` is a feature designed to automatically reduce the font size of text in order to fit content within the specified page width. We use this option to help prevent content from overflowing the designated page boundaries. However, it seems that "smart shrink" doesn't take into account the text direction unless it is set on the `body` or `html` tag specifically. opw-3472357 opw-3567655 opw-3520084 opw-3683210 opw-3684178 Enterprise PR: odoo/enterprise#50530 Forward-Port-Of: odoo/odoo#150987 Forward-Port-Of: odoo/odoo#146470
This fix ensures that marketing campaign information (utm parameters like source, campaign, and medium) is properly captured when customers register for events through tracked links, even when no sale order is generated. Previously, this tracking data was only saved if a purchase was made, resulting in incomplete marketing analytics for event registrations.
Original PR description
The utm parameters i-e utm_source, utm_campaign, utm_medium, are only set when a sale order is generated against an event and not set if there is no sale against an event registration that is done…
The utm parameters i-e utm_source, utm_campaign, utm_medium, are only set when a sale order is generated against an event and not set if there is no sale against an event registration that is done through a tracked linked. This functionality was missing for the event registration part. Steps to reproduce: 1. Create an event and copy its website link. 2. Go to link tracker and create a tracked link with utm values filled. 3. Use this tracked link in incognito preferably to register for the event. 4. Check the attendees of the event and check the marketing utm values. Current Behavior: The marketing values are not filled, because they are not set. The utm values are computed using sale order and if there is no flow to set these values. Expected Behavior: The utm marketing values should be set. OPW-3222179 task-3458877 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150977 Forward-Port-Of: odoo/odoo#141660
This update fixes a bug in the text editor where the emoji picker would remain open when clicking on the same paragraph, causing multiple emoji pickers to appear simultaneously. After this fix, the emoji picker now properly closes when you click away from it, providing a better user experience.
Original PR description
Current behavior before PR: On clicking the same paragraph while emoji-picker is open, it doesn't close, resulting in multiple emoji-picker being opened at the same time. Desired behavior after PR is merged: Now on-click away from emoji-picker on the same paragraph emoji-picker closes. task-3555717 Forward-Port-Of: odoo/odoo#138827
This update corrects the names of VAT accounts in the Slovak localization package. Previously, the same names were used for both sales and purchase VAT accounts, which could cause confusion and accounting errors. This fix ensures each account has a distinct, appropriate name for its purpose.
Original PR description
This fixes names of VAT accounts in Slovak localization package as it uses the same names for sale and purchase accounts. The same fix needs to be applied to master branch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix addresses two issues with parallax background elements in website editing. First, it prevents scroll-position-dependent CSS properties from being incorrectly saved to the database, which would cause the parallax to display incorrectly when the page is reloaded. Second, it stops the editor from falsely marking pages as having unsaved changes when parallax elements are present. These fixes improve the reliability of website editing and reduce unnecessary save prompts.
Original PR description
This commit does 2 things: - It prevents saving the parallax bg css properties which does not makes sense as those properties are related to the current screen scroll position. Each scroll position…
This commit does 2 things:
- It prevents saving the parallax bg css properties which does not makes sense as those properties are related to the current screen scroll position. Each scroll position has its own css properties. Saving those did no harm tho, as on start those were recomputed.
- It prevents flagging that parallax bg css properties change as a dirty change by stopping the observer while changing those properties. This is not really helping much apart from being right, since when discarding, to know if something is dirty, it's not considering the `o_dirty` class but doing some DOM comparison before/after, so:
- In this case, the css options are most likely still not the same.
- There is still some stuff that will get in the way and make the before/after DOM not the same:
- Scrolling a few px will hide the navbar and reveal the other one, flagging it as a dom diff
- When having a few menu end entering edit mode, some will end up in the "extra menu area" (grouped inside the "+" menu entry), which will also be considered as dom diff
Step to reproduce:
- Enter edit mode and drag & drop a parallax snippet
- Update its "Parallax" sub-option from "Fixed" to "Bottom to Top"
- This option change adds some css properties to the `s_parallax_bg`: top, bottom and transform. Each time you scroll, those are updated.
- Save and then inspect the source code of the page (CTRL-U)
- BUG 1: The `s_parallax_bg` was saved with those css properties set to the values related to where the scroll was when saved.
- BUG 2: Now enter edit mode again and check that the `#wrap` is automatically and directly set as `o_dirty`.
Related PR about mitigating dirty issues: https://github.com/odoo/odoo/pull/144121
opw-3672851
Forward-Port-Of: odoo/odoo#150474
Forward-Port-Of: odoo/odoo#148690Multi-day employee leave requests were not appearing in certain calendar views after a recent update. This fix adds proper support for displaying multi-day leave events by introducing an all-day slot in the HR holidays calendar view, ensuring employees and managers can see all leave requests regardless of calendar configuration.
Original PR description
After https://github.com/odoo/odoo/pull/109736, we started rendering all day events in the all day slot. However, some calendar views don't have an all day slot, so these events weren't being shown. Therefore, this commit adds an all day slot to the hr_holidays module to show multiple day events. Therefore, we add a new last_several_days computed field in hr leave. task-3566710 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#140359
This fix corrects an issue where editing event booth selections in a sales order quotation would not update the booth count displayed on the order. When users modified their booth selections and saved the order, the system was showing incorrect totals. The fix ensures that booth selection changes are properly saved and reflected in the booth count display.
Original PR description
**How to reproduce:** - Create a new quotation. - Add a product 'Event Booth'. - Select an Event, and select any available booth category. - From the available booths, select some of them. - Click 'Ok' and manually save the quotation. - Now, edit the same SO line, and select 'Event Booth' again(similar or different). - Confirm the SO. **Current behavior before PR:** Users can now see the incorrect total event booth count as 'Booths' on the stat-button. **Issue:** While editing the booths in the configurator, the new selection does not get updated in the 'event_booth_registration' table. **Desired behavior after PR is merged:** The records in the 'event_booth_registration' table are updated with the user selection of event booths. Users can now see the correct event booth count in the stat-button. **Task**-3309218 Forward-Port-Of: odoo/odoo#150747 Forward-Port-Of: odoo/odoo#127379
This fix resolves a problem where the live chat chatbot would fail to restart properly when users had slow network connections. The issue occurred because messages were being added twice, causing the restart function to fail. The fix ensures messages are only added once, allowing the chatbot to restart reliably regardless of network speed.
Original PR description
Before this PR, a race condition could occur when restarting the chatbot: if the rpc returned before the restart message reception on the bus, the chat would not restart. This was due to the message being inserted twice. Since the id is used as an unique `t-key` in the thread template, any duplicate would lead to an error. This PR fixes the issue by checking that the message is not already present before adding it to the thread messages. Steps to reproduce the issue: - Go to the contact us page - Start a chat with the bot and proceed until the end - Put your network in slow 3g mode - Click on the restart button - The chatbot is not restarting as expected Forward-Port-Of: odoo/odoo#150811
This update corrects a calculation issue in the accounting system for Indian businesses using multiple price-included taxes with identical percentages. Previously, these taxes could produce inconsistent amounts; now they correctly generate matching tax amounts, ensuring accurate invoicing and compliance with Indian tax requirements.
Original PR description
For the indian case, when facing two percent price-included taxes having the same percentage, both need to produce the same tax amounts. task_id: 3410529 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#150466 Forward-Port-Of: odoo/odoo#149399
This fix corrects an issue where manually adjusted tax amounts on invoices were not being reflected in electronic invoice formats (EDI/XML files), even though they appeared correctly on PDF documents. The change ensures that when users modify tax amounts through quick-edit mode or journal items, those changes are now properly included in all exported electronic invoice documents.
Original PR description
*: account, l10n_account_edi_ubl_cii_tests There is the following problem when editing the tax amounts on an invoice (in quick-edit mode or via the journal item): The changed amounts are displayed…
*: account, l10n_account_edi_ubl_cii_tests There is the following problem when editing the tax amounts on an invoice (in quick-edit mode or via the journal item): The changed amounts are displayed correctly on the PDF but not in the EDI XMLs (e.g. the embedded factur-x). This commit corrects this. Reproduce 1. Create a new invoice 2. In tab "Invoice Lines" add 2 lines with taxes from different tax group 3. Go to tab "Journal Items" and change the tax amounts (or use quick-edit mode; needs to be enabled in the settings) 4. Go back to tab "Invoice Lines" and notice the tax amounts of the groups were changed. 5. Generate a PDF: Here the tax amounts are correct (the changed amounts) 6. Look at the embedded XML: Here the tax amounts are wrong (initial / unchanged amounts). The same issue applies to multiple other EDI exports. To activate the EDIs go to: Accounting -> Configuration -> Journals -> Customer Invoices -> Advanced Settings tab -> Electronic Data Interchange The EDIs can then be found as attachment in the chatter after confirming and/or printing an invoice. Technically the change was adapted from (a part of) _prepare_tax_totals (from account.tax). That function handles the same problem (and i.e. makes the amounts correct on the move / PDF). task-3535411 Forward-Port-Of: odoo/odoo#150953 Forward-Port-Of: odoo/odoo#142144
This update fixes a bug that prevented the autovacuum feature from working properly in the base module. The autovacuum feature automatically cleans up and optimizes database records, and this fix ensures it operates as intended. This is important for maintaining system performance and database health.
Original PR description
This bug was introduced from this commit 21ca976 This PR fixes it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151003 Forward-Port-Of: odoo/odoo#150855
Report tables were displaying with vertically centered text in PDF documents after a recent design system update, which didn't work properly with the PDF generation tool. This fix adjusts the table formatting to align text at the top of cells by default, restoring the expected appearance of reports.
Original PR description
Since the Bootstrap5 migration (odoo/odoo#95450), the reports' table cell were centered vertically. This was due to the fact that the property "vertical-align" which was set on the table itself by BS5 doesn't play nice in wkhtmltopdf, namely, it seems to not get inherited by the table's children. This commit adapts the css by reproducing what was done in BS4 for tables. After this commit, the table cells have their text aligned at the top by default. opw-3670533 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#151011