Wednesday, October 16, 2024
8 changes · saas-17.4
Resolved issues and error corrections
This fix prevents Point of Sale users from seeing an error when another browser closes the same POS session. Unfinished orders are now moved to a rescue session, allowing staff to continue processing orders without interruption.
Original PR description
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error…
When we try to add any product for order in the first browser with ``Mitchell Admin`` as the user and simultaneously close the session in the second browser with ``Marc Demo`` as the user, the error will occur in the first browser when we click on order. Steps to reproduce: --- - Install the ``pos_online_payment_self_order`` module - Open the Bar, copy the URL, and Open a POS session on 2 different browsers with different user on both browser - Now go to the second browser and then close the session there - Now come to the first browser and add any product - Click on Order Traceback: --- ``ValueError: Expected singleton: pos.config()`` Previous Behaviour: --- This error occurred after this commit https://github.com/odoo/odoo/pull/179382/commits/a351107ade64a0ef67b28283a38b7add0cef689e because when a session is open in two different browsers and one browser is closed, at point [1], we delete the session, and after the deleted session, the orders are not linked to any session. After FIX Behaviour: --- After the deletion of the session from one browser if the orders are not completed then those orders are transferred to the rescue session(recuse session will be created). [1]- https://github.com/odoo/odoo/blob/462acc6853dfdc1418b790e99a0611c5ef5e17e2/addons/point_of_sale/static/src/app/store/pos_store.js#L1048-L1053 sentry-5699019259 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The mail conversation banner that prompts users to mark messages as read now disappears once users reach the bottom of a conversation or open a conversation with nothing to scroll. This reduces unnecessary reminders while still helping users keep track of unread messages.
Original PR description
The "mark as read" banner helps users keep track of where they last left off in a conversation. Currently, the banner is removed in the following situations: - When returning to the thread twice. - When posting a message. - When clicking on the "mark as read" button on the banner. However, this approach is insufficient, as the banner appears too frequently. This pull request streamlines the conditions under which the banner disappears. The banner will now be removed wheni on top of the other conditions: - The user scrolls to the bottom of the thread. - The user opens a thread that does not have a scrollbar. Both circumstances are sufficient to indicate that the user has actually read the messages. task-4102924
Users who work with multiple companies can now open linked records from another company without losing the target page during the automatic company switch. This avoids confusion in Discuss history and ensures the intended business record appears after access is adjusted.
Original PR description
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; -…
- Have access to multiple companies (A and B for instance); - Be connected to only one company (company A); - In the profile, have notifications handled in Odoo; - Open Discuss; - Got to History; - Click on the origin of a thread, it should be a record from the second company (company B in this case); Before this commit, we will connect to the second company (as expected), but the record will not be open. This issue happens because we open the record through a doAction. Before the form view is mounted, an AccessError is raised and the correct company is added to the cookies (see [1]). As the form view is not already mounted, the action service didn't push the new state into the URL. When reloading (after adding the company into the cookies), the state loaded will not contain the action to open the record. Now, we will connect to the second company, and the record will be open. opw-4240778 [1]: https://github.com/odoo/odoo/commit/6213c40932236101b529b82f0ea9fce1829c8c24
The Point of Sale product screen now avoids showing the same product twice when it belongs to both a parent category and its child category. This prevents a crash when staff browse restricted POS categories, improving reliability during sales operations.
Original PR description
Steps to reproduce: 1. Assign a product to category A and category B. 2. Make category A the parent of category B. 3. Put category A as restricted category of the pos.config. 4. Open the pos.config. 5. [ISSUE] click category A. The app crashes because of duplicate key. This is because we are rendering 2 product cards with the same product coming from category A (the parent) and category B (the child). To rectify, this commit proposes to remove the duplicates in the return value of `getProductsByCategory`.
This fixes an issue where time off allocations entered in hours could change after saving for employees with non-standard work schedules. The day and hour calculations are now aligned, so the saved allocation matches what the user entered.
Original PR description
Steps to reproduce: Make a regular allocation for a time off type that can be taken in hours for an employee that has a working schedule other than standard 40h/week, and click save. The number of hours is updated to an amount different to what was entered. The issue is that https://github.com/odoo/odoo/pull/163711 changes the computation of number of hours to only work with the standard `HOURS_PER_DAY` without considering the employee's schedule, meanwhile `_compute_number_of_days` still takes the employee's schedule into account, causing an inconsistency leading to the bug. This commit, makes the computation of days and hours consistent, so at least the amount entered is kept. opw-4190998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Email template buttons now keep their intended styling when messages are sent. This prevents buttons from appearing incorrectly in outgoing emails, improving the consistency and professionalism of customer communications.
Original PR description
Issue: ====== Sent emails buttons arent correctly styled. Steps to reproduce the issue: ============================= - Go to email templates - Add primary button - Send a message with the created template - The button isn't correctly rendered Origin of the issue: ==================== The grouped styles like `border`. `padding` and `border-radius` doesn't propagate their values to their substyles when there are variables used in the value. Solution: ========= We handle those cases alone, by reapplying the group style again by using the computed values since they may have some values using var from a parent style opw-4199180
Fixes attachment actions in Fleet so users can upload or create attachments from a vehicle's driver history, including on mobile screens. This removes confusing inactive controls and ensures the standard attachment form opens when needed.
Original PR description
Steps to reproduce: - Fleet app > Any vehicle > Drivers History > Attachments - In mobile view > Primary button 'Upload' is not accessible - Primary button 'New' does not do anything This happens because the controller cannot find a form view for ir.attachment in fleet, which is the default view type for record creation (barring quickcreate stuff). Also d-none class hides the display of the 'Upload' button but the dropdown menu arrow is still there which is rather confusing. Backport of 5c7cc1d04d7bd4febc9fc0e17e5c1b2f43d71b9d This commit changes the behavior of the selectRecord and createRecord view props so that these will open the default form view when called without any form view found in the action. opw-4229756 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Printing a Knowledge article directly from the browser now loads the required print styling, preventing blank print previews or pages. This improves reliability for users who print or export article content without first using the in-app export action.
Original PR description
When the user presses `Ctrl` + `p` to print an article, the page appears blank because the assets for print media queries are only loaded after the user clicks the "Export" button. To ensure that the print-specific styles are loaded, we will move the `knowledge_print.scss` file to the `web.assets_web_print` asset bundle. The generated stylesheet will then be linked to the page using a `link` tag with the `media="print"` attribute. The browser will then be able to load the stylesheet when the user is printing the page or previewing it for print. Steps to reproduce the issue: 1. Go to the Knowledge app. 2. Open an article 3. Press `Ctrl` + `p` to print the article. => The print rules are not loaded and the page appears blank. TO BE: The print rules should be loaded. task-4194236