Wednesday, March 20, 2024
33 changes · 17.0
Enhancements to existing features
This update refreshes the digest email design to match Odoo's new "Milk" visual style, replacing the previous purple color scheme with the updated design. All digest email images and styling across multiple modules have been updated to reflect this modern design refresh, improving the visual consistency and appearance of automated digest communications sent to users.
Original PR description
This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/enterprise#58780 Forward-Port-Of: odoo/enterprise#42790
This update improves invoice clarity by displaying the accounting date on posted invoices and credit notes when it differs from the invoice date. In certain situations, these two dates can be different, and showing both ensures users have complete visibility into when transactions were recorded in the accounting system versus when they were issued.
Original PR description
In some edge cases the invoice date will differ from the accounting date. This commit makes sure that when this is the case the accounting date is shown on a posted invoice or credit note. This way it stays clear that the accounting date differs from the invoice date. task: 3774329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The checkout process in the online store now provides a simpler way for developers to add custom steps without rewriting existing code. This improvement makes it easier for businesses to customize their checkout flow with additional steps like gift wrapping, loyalty programs, or custom verification steps.
Original PR description
`_get_checkout_steps` didn't provide a friendly way to add steps in the checkout flow. Developers had to reimplement part of the parent logic in their overrides. This commit introduces `get_checkout_step_list`. This method will allow an easier override of the checkout steps while keeping the logic to return a single step in the parent method.
The pivot table view has been improved to keep the horizontal scrollbar visible within the page viewport instead of appearing at the bottom of the page. Additionally, the scrollbar is now hidden when viewing sample data to prevent confusing navigation behavior. This makes the pivot table easier to use and more intuitive for users working with large datasets.
Original PR description
This commit simply removes the table-responsive class from the pivot view in desktop mode so that its eventual horizontal scrollbar will remain inside the viewport inside of being positioned at the very bottom of the page. Also hides the scrollbar in sample data mode so that the user cannot scroll horizontally in this case which introduces weird display.
The digest email template has been redesigned with the new "Milk" visual style, replacing the previous purple color scheme with the updated branding. All associated images and graphics throughout the digest system have been updated to match the new design aesthetic.
Original PR description
This PR contains a revamp of the digest email in the new "Milk" style replacing the old purple with the new one. This has been adapted in all digest data too. The images of the digest email's tips have been replaced by "milkified" versions of them, already available on odoo cdn by the way. Task-3338467 Forward-Port-Of: odoo/odoo#157896 Forward-Port-Of: odoo/odoo#125432
Resolved issues and error corrections
This fix corrects how withholding amounts are calculated and rounded in Peruvian electronic invoices (EDI documents). Previously, incorrect rounding rules caused the remaining amount after withholding to be miscalculated (showing 1052.20 instead of the correct 1051.38). The fix ensures currency amounts use proper decimal precision and withholding amounts are correctly rounded according to Peruvian tax requirements.
Original PR description
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company - In…
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- In Contacts, Configure a bank account (Banco de la nación - BANCPEPL) for PE Company
- In Accounting settings, run the automatic currency rates service ([PE] SUNAT)
- Create a product: (e.g. Product X)
* Sales Price: 990.00
* Withhold code: Arrendamiento de bienes muebles
* Withhold Percentage: 10.00
- Create an invoice:
* Customer: [a Peruvian contact] (e.g. Comercial Constructora los Patitos S.A.)
* Operation Type: [1001] Operation Subject to Detraction
* Payment terms: End of Following Month
* Journal in: USD
* Invoice Lines:
- Product: Product X
- Account: 7012100 Merchandise - Merchandise - Local sale - Third parties
- Price: 990.00
- Taxes: 18%
- EDI Affect. Reason: Taxed- Onerous Operation
- Confirm the invoice
- Process to EDI service
Issue:
The remaining amount after deducting the withholding is not correct in the generated EDI document.
The total is 990.00 + Taxes (18%) = 1168.20
The withholding is 1168.20 * 10% = 116.82
The remaining amount should be 1168.20 - 116.82 = 1051,38
However, the remaining amount set in the EDI document is 1052,20, which is not correct.
Cause:
The rounding used to compute the withholding amounts are not correct.
The amount in the selected currency should contain 2 decimal digits (precision_rounding should be 0.01, instead of 2).
Also, the Detraction amount should be declared in PEN currency in the EDI document and should not contain the decimal part (precision_rounding should be 1, instead of 2).
opw-3747620
Forward-Port-Of: odoo/enterprise#58473This update fixes how fields are displayed in the Kanban view editor's 'Add' tab. Previously, fields that were added before the main kanban card template were not showing up in the editor sidebar, making it difficult for users to see all available fields. The fix ensures all relevant fields are now properly displayed so users can easily add them to their kanban views.
Original PR description
This commit fixes the way we filter fields to show in the kanban editor sidebar, under the 'Add' tab. Since this view don't render what's included before the <templates> node from the xmlDoc. In other types of view, we can easily toggle the 'Show invisible' elements to display items that are considered being present in the view, but not in Kanban when they add items before the kanban card template. A test has been added too. task-3647045 Forward-Port-Of: odoo/enterprise#58578 Forward-Port-Of: odoo/enterprise#57322
This update fixes a problem that prevented customers from submitting support tickets through website forms in multi-company environments. The issue caused access errors when trying to create tickets, and has now been resolved to ensure ticket submissions work smoothly regardless of company configuration.
Original PR description
Steps to produce: - add new form from editor on website - add action create ticket on it - submit ticket on multi-company environment. Cause: access error while submit ticket with multi-company Solution: access ticket using sudo resolve this issue. task-3635784 Forward-Port-Of: odoo/enterprise#58882 Forward-Port-Of: odoo/enterprise#53389
Fixed a bug where changes made to automation records in Studio were not being saved when closing the editor. The issue was that Studio's internal service wasn't properly syncing unsaved changes with the main application. Now when users create or edit automation records in Studio and close the editor, their changes are properly saved.
Original PR description
In studio, click on the "Automation" menu item. Create, or edit, one base.automation record, and modify some fields. Hit the button "Close" to get out of Studio. Before this commit, the base automation record was not saved. This was because the studio's action service did not receive the clear uncommitted changes from the main one. After this commit, the record is saved when we leave studio. Note that the ViewEditor mode should not be affected as we operate under a clean owl environment in StudioView. Forward-Port-Of: odoo/enterprise#58926 Forward-Port-Of: odoo/enterprise#58862
The availability widget for rental order lines was displaying incorrect information because rental dates weren't being passed to it. This fix ensures rental dates are properly communicated to the widget, so customers and staff see accurate availability information specific to their rental periods.
Original PR description
Previously, the availability widget showed non-rental info, even for rental order lines. This was because the rental dates were never passed to the widget. This commit ensures the rental dates are passed. opw-3700809
This fix ensures that when creating new mass mailing campaigns, the system correctly uses the company's configured email domain settings instead of defaulting to the current user's email. Previously, the email address would only update if you manually changed the mail server setting. Now it properly applies the company's email configuration at the time of creation, ensuring consistent and correct sender addresses for all campaigns.
Original PR description
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose,…
# Context With 17.0 the `mail.alias.domain` was introduced, allowing the configuration of the bounce, catchall and default from email addresses at the company level (`res_company`). For this purpose, the `_compute_email_from` method was introduced to correctly compute the `email_from` in various email contexts. But, the `email_from` field in mass_mailing was using an obsolete combination of `default=` and a compute method. This meant that when one created a new `mailing.mailing` record, it was always defaulting to `self.env.user.email_formatted`. The compute was only triggered when the `mail_server_id` field manually updated. This is corrected with this fix and a unit test was added to test three different use cases. An invisible `create_uid` was added to the base mailing From view xml to have the compute method trigger correctly in some unit tests. ## How to reproduce bug: See related github issue https://github.com/odoo/odoo/issues/151310 ## Behavior after this fix: If `mail.alias.domain` is setup for the company and a default `ir.mail_server` is configured for Email Marketing, `_compute_email_from` will select the expected `email_from` at record creation for `mailing.mailing`. opw-3704715 Fixes #151310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix restores the ability to set receivable and payable accounts as default accounts on miscellaneous journals, which was broken by a previous change. This allows users managing credit card statements to set payable accounts as defaults, eliminating the need to manually select accounts for each transaction entry and improving data entry efficiency.
Original PR description
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account,…
This commit cleans the domain that defines the default account that can be set on a journal. It first removes the domain that excludes the receivable and payable accounts from the default account, and we restore the default accounts that could be set on sale, purchase, bank, and cash journals. The domain was broken since this commit: https://github.com/odoo/odoo/commit/3312657294947b1cc8670a0ed3557e12ee6969c8 The following journals must have the following possible default account types: - bank: asset_cash, - cash: asset_cash, - sale: income, income_other, - purchase: expense, expense_depreciation, expense_direct_cost, - general: all account types are possible, The object of the task was mainly to allow misc journals to allow receivable or payable default account type for the following use case: Suppose a user creates a Miscellaneous Journal to manage the details of the credit card statements. Most journal entries will consist of journal items impacting the Payable Account, as this will reclassify the debt towards various vendors and address this debit to the credit card company. It would in that case be necessary that the liquidity_payable accounts can be the default account on the miscellaneous journal. Otherwise, the user will have to fill in manually the account for each line of its credit card statement, and considering there can be a lot, this could become cumbersome. task-3393017
This fix resolves an issue where unlisted Vimeo videos could not be embedded in the website editor using the /video command. The system now properly preserves the access hash parameter when generating video URLs, allowing unlisted videos to load correctly instead of showing an error message.
Original PR description
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter…
When the user inserts a video with the `/video` command and provides a link of an unlisted vimeo video, the system generates a new url based on the options selected but omits the hash parameter granting access to the given video. As a result, the video can not be loaded and the vimeo `iframe` indicates that the video does not exist. To fix the issue, we will copy the hash parameter from the original link to the newly generated url. That way, the video will be loaded properly and the user will be able to embed unlisted vimeo videos. Steps to reproduce the issue: 1. Install the website app 2. Open the website builder 3. Drag and drop a text block 4. In the text block, type the `/video` command to insert a video 5. In the modal, paste the link of an unlisted video 6. The `iframe` indicates that the video does not exist => The system should extract the hash parameter from the provided url and set it on the generated url. The video should then be loaded properly. task-3697764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154329 Forward-Port-Of: odoo/odoo#150663
This fix resolves an issue where clicking on form field inputs would incorrectly display an empty "Column" editor in the side panel and cause errors when attempting to delete it. The problem occurred because form elements were being mistakenly recognized as columns due to a recent padding option update. This fix refines the selector to exclude form field parts from being treated as editable columns.
Original PR description
Since [1] when the "Padding (Y, X)" option was added, form elements are recognized as columns because they match the `.row > div` selector of that new option. This commit excludes those form elements from this option's selector. Steps to reproduce: - Drop a website form. - Click on field's input. => An empty "Column" editor appeared in the side panel, and an error occurred when trying to delete it. [1]: https://github.com/odoo/odoo/commit/11418cc6f0afcc8e14869f4f38ae0d6d462ac712 task-3748574
This fix corrects how the system identifies which user initiated document sending when the process runs automatically through scheduled tasks. Previously, automated sends would incorrectly show as coming from OdooBot instead of the actual user who requested the send. This ensures proper tracking and attribution of document sending actions.
Original PR description
Some methods were using the `self.env` to decide users/partners while those methods can also be called from Cron, thus the user would end up to be OdooBot instead of the partner that initiated the async sending.
This update allows search view filters to use user-provided values through the self variable, making filters more flexible and dynamic. Previously, the domain property couldn't reference user data, limiting filter customization. Now users can create more sophisticated search filters that adapt to their specific information.
Original PR description
The domain in the search view's field can contain user-provided values, which are accessible via the self variable. Description of the issue/feature this PR addresses: The current version of the domain property in the search view for a field cannot accept user-provided values as the domain value, which is unreasonable. Current behavior before PR: cannot use self variable as user-provided values Desired behavior after PR is merged: can use self variable as user-provided values --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where custom font size settings were not being applied to buttons in the website header navigation menu. When users changed the font size formatting in the header's navbar settings, some buttons were ignoring these changes. The fix ensures all buttons now properly respect the custom font size values set by users.
Original PR description
Steps to reproduce: - Enter in edit mode. - Select the 'Header' menu. - Switch the default template to 'Rounded box menu'. - Select again the 'Header' menu and on the 'Navbar' details, update the format value (i.e: 10px) and save. -> Problem: some buttons are not affected by the change of the format value. The problem is that since [1], those buttons have the `rounded-circle` class so their font size is not the custom one (but it is the value of `$font-size-base` instead). To solve the problem, the css rule has been adapted in order to force the font size of the buttons inside the header to the custom value if it exists. [1]: https://github.com/odoo/odoo/commit/e3e9c492e0d1e009a0c459a1dc591e122b4b65d3 opw-3810794
This fix corrects how down payment sales order line names are displayed when invoices are finalized. Previously, the system would show "Draft" status even after an invoice was posted (finalized). Now the system properly updates the down payment line name to reflect the actual invoice status, ensuring accurate and up-to-date information in sales orders.
Original PR description
Before this commit sol name was not reflacting invoice status when it moved to posted it only reflect draft and cancel state. This commit re-compute downpayment related sol name when invoice related to that sol get posted this way it'll update sol name to proper name instead of keeping always Draft string in it. opw-3768323 Forward-Port-Of: odoo/odoo#157824
Fixed an issue where the image cropping tool in the website editor wasn't responding to mouse clicks and keyboard input. Users can now properly close the crop tool by clicking elsewhere and save their cropped images by pressing Enter, making the image editing experience work as intended.
Original PR description
**Current behaviour before commit:** When trying to crop image in website, 'mousedown' and 'keydown' events are not getting caught. Due to this, - Crop is not getting closed when clicking on document - Cropped image is not getting saved when pressing enter **Desired behaviour after commit:** Now, events are added to the owner document of the crop widget. As result, - Crop gets closed when clicking anywhere in document - Image gets saved when pressing enter. task-3570524 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157763 Forward-Port-Of: odoo/odoo#140108
This fix resolves an issue where users with limited permissions (without full employee access) would encounter an error when creating timesheets for team members on tasks without a company assigned. The system now properly retrieves the employee's company information without attempting to access restricted employee fields, allowing the timesheet to be created successfully.
Original PR description
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only…
Before this commit, when the current user did not have `hr.group_hr_user` group and creates a timesheet for an employee in his team, he could get a traceback before one field defined only `hr.employee` model cannot be fetched in `hr.employee.public` by the ORM. The reason is because when the user creates a timesheet in a task without any company set, we will take the company of the employee set on the timesheet to set it in the new timesheet, by doing that, the ORM will prefetch the fields of `hr.employee` and returned the company from its cache. This commit makes sure we will not have any issue when we try to get the company of the employee to set in the new timesheet if one field defined in `hr.employee` is not defined in `hr.employee.public` and has to be prefetched by the ORM. Steps to reproduce (in 17+) ================== 0. install `hr_timesheet` and `pos_blackbox_be` modules. 1. create a user A with `hr_timesheet.group_hr_timesheet_approver`, without any access to Employee app 2. create a project and a task without any company set (default value) 3. log in as user A 4. go to the form view of task created in step 2 5. add a timesheet and save the form view Expected Behavior ================= The timesheet should be added in the task and the form view should be saved without any issue. Actual Behavior =============== A traceback is occured saying "The fields 'insz_or_bis_number' you try to read is not available on the public employee profile" opw-3769277 Forward-Port-Of: odoo/odoo#156506
The automatic invoice sending cron job was not properly processing invoices due to incorrect use of the job count parameter. This fix changes how invoices are retrieved to ensure all pending invoices are processed correctly, preventing timeouts and duplicate processing. The update also improves performance and adds proper lock handling to prevent concurrent execution issues.
This fix ensures that when generating electronic invoices (EDI documents), the system now correctly uses the specific invoice address assigned to a customer instead of always defaulting to the main partner address. This resolves issues where custom invoice addresses were being ignored during EDI document creation.
Original PR description
* = facturx, ubl, ubl_cii, ubl_bis3 Problem --------- Currently, the EDI use the commercial partner to craft the XML document. However, this causes issues when users add, for example, an invoice address to a partner. Indeed, the address of the main partner will be used and not the invoice address. This caused issue; see the relevant OPW-3624205. Objective --------- Make sure that the correct address is used when generating the XML. Solution --------- Make sure the commercial partner // partner value is used at the correct spot. - `partner` should be used for addresses - `commercial_partner` for everything else. OPW-3624205 task-3636315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157856 Forward-Port-Of: odoo/odoo#155896
This fix resolves an issue where search result messages were invisible in dropdown menus when using certain theme colors. When users searched for content that returned no results, the "No results found" message was displayed in white text on a white background, making it unreadable. The fix ensures that text colors in dropdowns automatically adjust based on the background color for better visibility.
Original PR description
Steps to reproduce the bug: - Install the "Blogs" app and go to the "/blog" page. - Click on "Edit" to enter edit mode. - Go to the "Theme" tab. - Select the 4th color from the theme colors and…
Steps to reproduce the bug: - Install the "Blogs" app and go to the "/blog" page. - Click on "Edit" to enter edit mode. - Go to the "Theme" tab. - Select the 4th color from the theme colors and choose "black". - Save the page to exit edit mode. - Perform a search in the search bar input that yields no results, for example: "zzz". - Bug: The message "No results found. Please try another search." is not visible because it is displayed in white on the white background of the dropdown. A previous commit [1] had already addressed the issue for the "Search" snippet that can be dropped into a page, but this fix wasn't sufficient to solve the problem everywhere. Indeed, the text-muted in a dropdown should be adjusted in all cases and not just for snippets; it's a Bootstrap issue. The text-muted color should be adapted to the background color of the dropdown. [1]: https://github.com/odoo/odoo/commit/f9bf40cb53cf487c8736c1f565c2f0d3834acd5e task-3662985 Forward-Port-Of: odoo/odoo#157731 Forward-Port-Of: odoo/odoo#156029
This update fixes a layout issue in the Mass Mailing email editor where the snippet menu was appearing misaligned at the top of the form. The fix ensures the mail body displays properly formatted, improving the user experience when creating and editing mass mailing campaigns.
Original PR description
Before this PR: The snippet menu in the Mail Body appeared on the top of the form, causing misalignment. Technical details: - This problem was observed in the `view_mail_mass_mailing_form` form and all other views inheriting from it. - The fix involves adding the `o_mass_mailing_iframe `class using the `iframeHtmlClass` attribute on the body_arch field. After this PR: The layout is now aligned. This PR targets up to 17.0, for further versions the issue has already been resolved. task-3603623 Forward-Port-Of: odoo/odoo#157864 Forward-Port-Of: odoo/odoo#152996
This fix corrects the employee count shown on partner records to accurately reflect the number of employees associated with each partner based on selected companies. When viewing partner details, the employee count button now displays the correct number and opens a proper employee list view for easy access to employee information.
Original PR description
This will fix the number of employees in the partner view and redirect to a kanban view of the employees. The smart button on the partner view for the number of employees related to this partner now gives the correct number depending on the companies selected. If multiple employees are related, the action shows a kanban view of those employees. Task: 3693173 Forward-Port-Of: odoo/odoo#157537 Forward-Port-Of: odoo/odoo#154162
This fix resolves an issue where the system was incorrectly checking access rules when creating new records. The system is now designed to skip access rule validation for new records, allowing automated actions (like onchange events) to work properly without being blocked by security restrictions. This ensures a smoother user experience when creating new items in the system.
Original PR description
This fixes an issue where access rules are checked on a new record: the rule domains are evaluated with method `filtered_domain()`, and one rule uses the operator `'child_of'`, which is implemented with a call to `search()`. When used with a new record, `filtered_domain()` returns an empty recordset instead of the record itself. By design, the ORM doesn't check security on new records. A base automation of type `'onchange'` will run some server action on a new record. The server action may still check access rights on the model, but should not check access rules.
This fix ensures that when creating an alternative purchase order from a request for quotation, the vendor taxes are properly calculated on all line items. Previously, taxes were not being computed when using the alternative creation feature, even though they would be calculated correctly if the purchase order was created manually. This update makes the behavior consistent across both methods.
Original PR description
Steps to reproduce: - - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: - The purchase…
Steps to reproduce: - - Create a request for quotation for a product with set vendor Taxes - Create an alternative purchase order from that RFQ with Copy Product Current Behavior: - The purchase order line of the PO associated with the created alternative does not compute the taxes. Expected behavior: - The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives. Cause of the issue: - When creating a PO manually, the taxes of each purchase order line are computed when the product is set during the call of the `onchange_product_id` onchange method: https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221 https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061 By contrast, PO created from the `action_create_alternative` generate each `purchase.order.line` using `Command.create`. Therefore these lines will not trigger the onchange method and their taxes will not be computed. Fix: - To KISS, we compute the taxes of each line just after the creation of the record using the `_compute_tax_id` method. opw-3750719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155060
This fix resolves an issue where activity feedback was appearing twice in the activity log when marking a calendar event as done. The problem occurred because the system was syncing the event description with activities, causing feedback to be logged twice. The fix ensures the activity is logged first before updating the event description, eliminating the duplication.
Original PR description
How to reproduce: - install crm - open a lead - create an activity call or meeting (and schedule it in the calendar) - mark it as done with a feedback The activity log in the chatter contains the feedback twice and shouldn't. The problem was caused by the synchronization of the event description with the related activities. When marking an activity as done, the event description is updated with the feedback which in turn update the activity note with the feedback. When logging the activity done in the chatter, the note and the feedback are logged leading to a duplicate feedback. We solve this by first logging the activity done in the chatter before updating the event description. Task-3653088 Forward-Port-Of: odoo/odoo#157930 Forward-Port-Of: odoo/odoo#147898
This update fixes an issue where barcode scanning wasn't working properly on mobile Chrome browsers. The fix adds a missing jQuery library dependency that the barcode service requires to function correctly on mobile devices.
Original PR description
The barcode service using jquery for chrome on mobile is not working properly without jquery included, we include it here task-3817495
This fix resolves an issue where TikTok icons inserted into email marketing templates were not displaying correctly when the campaign was sent. The problem occurred because the system wasn't properly converting the icon's CSS class into an image format for email delivery. Users can now successfully add and send TikTok icons in their mass mailing campaigns.
Original PR description
Since commit [1], the new tiktok icon is added to odoo but the conversion of the css class into an image is not supported. This commit ensures that the conversion is correctly handled. Steps to reproduce: - Open the mail marketing app - Create a new mass mailing - Insert an icon in the template, for instance type /image in the text and select the "Pictogram" tab - Search for tiktok icon and insert it - Send the mass mailing - The icon will not be found in the mail [1]: https://github.com/odoo/odoo/commit/515915b9 Forward-Port-Of: odoo/odoo#157937 Forward-Port-Of: odoo/odoo#157919
This fix resolves a database query error that occurred when both the HR Holidays and Auth Signup modules were installed together. The error prevented the system from correctly identifying which employees are currently on leave. The fix clarifies which data field to use in the query, ensuring the leave tracking feature works reliably regardless of which modules are enabled.
Original PR description
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This…
Issue addressed by this commit: An ambiguous column error occurs in the hr_holidays model when the auth_signup module is installed alongside it, due to both modules having a state field. This ambiguity arises within the _get_on_leave_ids method, affecting the execution of a SQL query designed to identify users on leave. How to reproduce the issue: Install both hr_holidays and auth_signup modules. Attempt to execute the _get_on_leave_ids method to identify users on leave. Behaviour before this commit: An "ambiguous column error" is raised due to the SQL query not specifying which state field to use, leading to confusion between the state fields in the hr_leave and res_users tables. Expected behaviour: The SQL query should clearly reference the state field from the hr_leave table, avoiding ambiguity and accurately identifying users on leave without errors. Solution: The SQL query within the _get_on_leave_ids method has been updated to use hr_leave.state = 'validate' for clear distinction, resolving the ambiguous column error. opw-3770758 Forward-Port-Of: odoo/odoo#156663
This fix resolves a timing issue where the push-to-talk extension feature was not being properly detected during video calls. The system was ignoring responses from the extension if they arrived before the call service fully started, causing the feature to appear unavailable. This update ensures the extension is correctly recognized regardless of timing.
Original PR description
The push-to-talk extension service sends a message to the extension when starting to check if it is enabled. If the response is received before the RTC service is started, the answer is ignored, and the service acts as if the extension were not available. This PR fixes this issue.
PayPal was rejecting the access token parameter name, causing users to see an incorrect "log in again" error message. This fix renames the parameter to properly handle transaction cancellations, ensuring users can successfully cancel PayPal payments without authentication issues.
Original PR description
PayPal refuses to take access_token name parameter and throws an error to user that they need to log again. Since the Access Token is neeeded to cancel transaction, it is renamed to return_access_token. opw-3810686 Forward-Port-Of: odoo/odoo#157974