Tuesday, May 21, 2024
18 changes · 17.0
Enhancements to existing features
This improvement adds the ability to view Odoo's system logs directly from the IoT Box through a web browser by visiting the `/odoo-logs` URL, even when the main Odoo server is temporarily unavailable. This makes troubleshooting and system monitoring easier for Point of Sale operations by providing quick access to diagnostic information without needing direct server access.
Original PR description
[IMP] point_of_sale: display odoo's logs' folder from an url Allow to access odoo logs from the IoT Box even if Odoo's server is down via nginx by displaying /var/log/odoo How : from the IoT Box, go to the url `/odoo-logs` will display all the logs files from Odoo opw-3887623
This update adds a database index to the SMS tracking system to speed up message lookups. By indexing the SMS UUID field, the system can find and retrieve SMS records much faster, especially when handling large volumes of messages. This improvement enhances overall application performance without changing any user-facing features.
Original PR description
-We might performing search a lot so adding index would be very nice 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
Resolved issues and error corrections
This update fixes a test in the tax cloud integration for online sales to ensure customers properly select a shipping carrier for physical products before completing their purchase. This prevents checkout errors and improves the reliability of the payment process for orders containing storable or consumable items.
Original PR description
Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/odoo/pull/161476 Forward-Port-Of: odoo/enterprise#60550
This fix resolves an issue where recorded timesheet hours were not being reflected in the project planning view. The system now properly tracks when timesheets are added to a project, ensuring that the displayed hours in planning slots are always up-to-date with actual work recorded.
Original PR description
Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute, one of its dependencies must change. `project_id.analytic_account_id.line_ids` is different from `project_id.timesheet_ids`. As a result, the method which computes `effective_hours` is not triggered. Solution: --------- Add `project_id.timesheet_ids` in dependencies. opw-3891624
This fix resolves a bug where the timer in the timesheet grid could display negative values when users quickly stopped and restarted it. The issue occurred due to a timing conflict where the timer would be added to a component that was already being destroyed. The fix ensures the timer is only added to active components, preventing the negative value display.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestroy` is called; 5. timer isn't canceled because it hasn't started yet; 6. `onWillStart` continues; 7. a timer is added for a destroyed component. Solution -------- Use Owl's `status` function to ensure the component hasn't been destroyed before adding a timer. opw-3815398
Fixed an issue where filter options (like currency settings and draft entry inclusion) were not being properly applied when navigating to the General Ledger report from the Bank Reconciliation warning message. This ensures users see consistent filtered data regardless of how they access the General Ledger report.
Original PR description
This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Ledger - Go back - Create, confirm & reconcile an invoice - Reset invoice to draft - In "Accounting", go to "Dashboard" - Click on the 3 vertical dots to the right of the "Bank" card - Click on "Reconciliation Report" - In "Options: Posted Entries Only", select "Include Draft Entries" - Click on "General Ledger" in the first yellow warning - Draft entries won't be included task-3928454
This fix resolves an issue where restaurant table bookings were incorrectly appearing on multiple tables when moved. Previously, when an appointment was transferred to a different table through the appointments app, the booking would still show on the original table. Now, bookings correctly display only on the current assigned table, ensuring accurate table availability in the POS system.
Original PR description
Steps: - Schedule an appointment for one table at a specific time. - Open the POS and verify the appointment. - In a separate tab, open the appointments application and transfer the appointment to a different table. - Return to the POS tab and confirm that the appointment is displayed on both tables. Issue: Both tables display scheduled appointments. Cause: Booking is not removed from the previous table. FIX: When updating an appointment to a new table, the booking is only visible on current booking table. task-3893909 Forward-Port-Of: odoo/enterprise#62020
Fixed a bug in the Partner Ledger report where the "Open" and "Journal Items" buttons were not properly linked to specific partners when using the Prefix Groups Threshold feature. Previously, clicking these buttons on grouped lines would either create a new partner or cause an error. Now the buttons are correctly disabled or hidden for group summary lines.
Original PR description
# Issue:
In a Partner Ledger using the "Prefix Groups Threshold" option, there are the "Open" and "Journal Items" buttons that are available as any other line in partner ledger report but they aren't bind to a specific Partner so the Open button, redirect to a "New partner" page and the Journal Items raise a traceback.
# Reproduce:
- Go in debug mode
- Accounting > Configuration > Accounting Report > Partner Ledger > Options
- Set Prefix Groups Threshold to 2
- Go in Accounting > Reports > Partner Ledger
- Try to open a journal items on a "Grouping Line"
# Task:
opw-3916555
Forward-Port-Of: odoo/enterprise#62360Fixed an issue where public users clicking embedded links in published knowledge articles would see no action. Now when a public user clicks an embedded link, they are redirected to log in, and after authentication, they are taken to the requested view if they have permission to access it. This improves the user experience by enabling seamless access to linked content.
Original PR description
**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-Of: odoo/enterprise#57346
Fixed a broken link in the Luxembourg Balance Sheet (abridged) report that prevented users from navigating to the Profit & Loss (abridged) report. The issue was caused by incorrect data formatting in the link's configuration, which has now been corrected to allow seamless navigation between these financial reports.
Original PR description
The link from 'Balance Sheet (abridged)' to 'Profit & Loss (abridged)' raises an error. ### Steps to reproduce : - Install the l10n_lu_reports module - Change the company to a Luxembourgian company - Go to Accounting > Reporting > Statement Reports > Balance Sheet - Change the report to 'Balance Sheet (abridged) (LU)' - In the report, click on the link 'VI. Profit or loss for the financial year' ### Cause: The action triggered by this link has not the right formatted context. It should have the value 'report_id' but has 'model' and 'id' instead. This raises an error in execute_action when trying to read 'report_id' on this action. ### Solution: Remove 'model' in the context and rename 'id' to 'report_id'. opw-3912348 Forward-Port-Of: odoo/enterprise#62715
This fix ensures customers must select a shipping carrier for physical products (storable and consumable items) before they can proceed to payment. Previously, customers could attempt checkout without choosing a delivery method, which could cause issues. This improves the checkout experience by catching this requirement earlier in the process.
Original PR description
Check if the user selected the carrier for storable/consumable products before proceeding to payment. opw-3810367 See also: - https://github.com/odoo/enterprise/pull/60550 Forward-Port-Of: odoo/odoo#161476
Users were unable to edit badge snippets in Website edit mode because the overlay handles were blocking interactions with the snippet content. This fix adjusts the handle positioning so users can now properly edit snippet text and properties without obstruction.
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Badge" snippet into the footer. - Bug: it is not possible to edit the text of the badge or change its icon. The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles. Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this bug. Their height was changed with this commit [1]. [1]: https://github.com/odoo/odoo/commit/70f723a9f78c406746f5409f6a89cbe93ad21580 task-3927962
Fixed an issue where event time and duration information was not visible when opening a calendar event popover. The fix ensures that time details are now displayed consistently across all calendar views, including mobile view, making it easier for users to see complete event information at a glance.
Original PR description
## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDateTimeAndDuration` function of the calendar popover. opw-3829004 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160907
This fix resolves an issue where adding components to a manufacturing order with multi-step warehouse routes caused inventory quantities to be updated multiple times, resulting in incorrect stock levels. The problem occurred because the system was processing inventory updates twice during the component confirmation process. This fix ensures inventory is updated only once, maintaining accurate stock counts.
Original PR description
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing…
### Steps to reproduce: - Enable Multi-step Routes in the settings - Inventory > Configuration > Warehouse Management > Warehouses - Enable manufacturing in 2 steps (pbm) - Create a manufacturing order for a product P1 with a demand of 1 x P2 - Confirm the MO (a transfer for 1 x P2 should be created). - Add a line to the MO with a demand of 1 X P2 and save. #### > the related stock picking was updated twice leading to a demand of 3 Cause of the issue: Since pbm is enabled the components are required to be in pre-Production for the manufacturing to start with. As such, our MO is associated with two stock moves. One for the local transport of components: - move_inter_1: 1 x P2 from Stock to pre-Production - move_raw_1: 1 x P2 from pre-Production to Production Saving the additional component requirement on the mo will create and confirm a second raw move: - move_raw_2: 1 x P2 from pre-Production to Production During its "_action_confirm", the procurements of this move will create and confirm a second internal move: - move_inter_2: 1 x P2 from Stock to pre-Production During the "_action_confirm" of this internal move a merging process will start since the already existing move_inter_1 is a good candidate: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1369-L1370 https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L994-L998 The quantity of move_inter_1 will then be updated: https://github.com/odoo/odoo/blob/f07c1a6b60ac1d07d9a2b098cca6ba8413ffbe0d/addons/stock/models/stock_move.py#L1035 Then, the merging process of move_raw_2 will start since the already existing move_raw_1 is found as a good candidate and the quantity of this move will be updated by a "write" call. However, procurements are also run in the call of the write method unless 'no_procurement' is specified in the context: https://github.com/odoo/odoo/blob/e8f8c9b4286f60733153220511fd0e2bf33370b3/addons/mrp/models/stock_move.py#L344-L348 Since this is not the case, this will create and confirm a new internal move: - move_inter_3: 1 x P2 from Stock to pre-Production This move will also be merged to move_inter_1 (this is the second update). ### Fix: Since procurements will always be run by the "_action_confirm" of the related stock moves, we can safely skip the procurements run by the write method during this flow. opw-3880686 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163808
This fix ensures that shipping costs are recalculated correctly when you change the quantity of items in an order. Previously, the system would not update the package weight after a shipping method was applied, even if you modified the order quantities. Now, the weight is automatically recalculated each time you update the shipping cost, ensuring accurate shipping fees based on the current order contents.
Original PR description
**Steps to reproduce:** - Install Delivery, Sales and Stock modules - Create a based on rules Shipping method for a product using weight as a variable - Create a quotation for this product - Add shipping to the quotation - Change the quantity of the order line - Click on 'Update shipping cost' **Current behavior before PR:** The weight of the order does not get updated once we set a shipping cost to the order. This is happening because of this condition https://github.com/odoo/odoo/blob/17.0/addons/delivery/models/sale_order.py#L139 since we can edit the quantity of the order lines then there is not point of not calculating the estimated weight each time. **Desired behavior after PR is merged:** With removing this condition the weight will get updated each time we open the shipping cost wizard. opw-3908453 Forward-Port-Of: odoo/odoo#165838 Forward-Port-Of: odoo/odoo#164928
This fix corrects an issue where PayuLatam payment redirects were going to incorrect websites when using databases with different domains. The system now properly uses the correct root URL when communicating with PayuLatam, ensuring customers are redirected to the right location after payment processing.
Original PR description
Before this commit, the root URL of the request was not sent to PayuLatam, leading to redirection to an incorrect website when databases with a different domain were set. To use the url_root, get_base_url must be called from the payment.acquirer instance. opw-3348291 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165252 Forward-Port-Of: odoo/odoo#165092
This fix allows credit notes to be confirmed and submitted to ZATCA (Saudi Arabia's tax authority) even when they are not linked to an existing invoice, as long as they have a valid Customer Reference. Previously, credit notes could only be processed if they were created from existing invoices, which limited flexibility for users who needed to issue standalone credit notes.
Original PR description
Previously, only credit notes created from existing Invoices were allowed to be posted & sent to ZATCA. Now, as long as a credit/debit note has a Customer Reference (ref), the system will allow it to be confirmed and submitted Description of the issue/feature this PR addresses: Users are not allowed to confirm/submit Credit Notes if they are not linked to an existing Invoice Current behavior before PR: Upon confirmation/posting of a Credit Note, if it is not linked to an existing Invoice or does not have a Customer Reference, the system blocks the confirmation Desired behavior after PR is merged: As long as a credit note is linked to an existing Invoice or has a valid Custoemr Reference (ref) the system allows it to be confirmed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166102
This fix resolves a bug in the web editor where text selection would incorrectly jump back to the start of a paragraph after clicking on text in a new line created with Shift+Enter. The issue was caused by a previous change that didn't account for this specific scenario. The fix properly positions the cursor relative to its parent element, ensuring selections remain where users expect them to be.
Original PR description
commit that introduced the issue: [1] Steps to reproduce the issue: ============================= - Go to to-do - Add some text - Click shift+enter at the end of the first line - Add some text in the second line - Select a prefix of the second line - Click any character - The selection is back at the start of the paragraph Origin of the issue: ==================== This was done intentionally by the mentioned commit which didn't take into consideration this case. Solution: ========= We set the curosr at the element index relative to its parent. opw-3829462 [1]: https://github.com/odoo/odoo/commit/06658ff13abfbdaeb7c562b8fd33fc9cf4f56f95 Forward-Port-Of: odoo/odoo#164509