Daily updates from Odoo
Wednesday, March 20, 2024
118 changes
Enhancements to existing features
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
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 update fixes an intermittent test failure in the stock accounting module by making the search criteria more specific. The test was sometimes failing because it wasn't properly isolating the account record it needed to verify, which has now been corrected to ensure reliable and consistent test results.
Original PR description
The account move search was not enough specific to retrieve only one account move. The following `assert` sometimes failed because of this. This commit reinforces to search to get only one account move opw: runbot error 60338 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#158050
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