Thursday, December 12, 2024
6 changes · 17.0
Resolved issues and error corrections
This fix prevents repair order information from being accidentally applied when the system creates related stock movements. As a result, replenishment moves triggered by repair parts are properly linked to their warehouse transfer, improving inventory traceability.
Original PR description
Steps to reproduce the bug: - Create “route 1”: - applicable on: product - Rule: - Pull from - Operation type: internal transfer - Source Location: WH/Stock/Shelf 1 - Destination Location:…
Steps to reproduce the bug:
- Create “route 1”:
- applicable on: product
- Rule:
- Pull from
- Operation type: internal transfer
- Source Location: WH/Stock/Shelf 1
- Destination Location: WH/Stock/Shelf 2
- Supply Method: Take from stock
- Create a storable product “P1”:
- Orderpoint:
- Location: WH/Stock/Shelf 2
- Min qty: 0
- route: “route 1”
- create a repair order:
- product to repair: select any one
- Part: Add one unit of P1
- Go to miscellaneous:
- source location: WH/Stock/Shelf 2
- Confirm the MO
Problem:
The order point will be triggered, and a stock move will be created
but not linked to a picking. This occurs because the product to be
repaired is storable and out of stock. As a result, the wizard
indicating insufficient quantity for the product is launched, and
default_repair_id is added to the context. Consequently, the move will
be created with the repair order field set and does not need to be
assigned.
https://github.com/odoo/odoo/blob/17.0/addons/repair/models/stock_move.py#L179-L182
opw-4224710Restaurant point-of-sale orders now keep their applied promotional rewards when staff leave a table and return later. This prevents discounts from disappearing during normal service, helping ensure bills remain accurate and promotions are honored.
Original PR description
When adding a reward to an order on a table, if you leave the table and come back to it the reward would be gone Steps to reproduce: ------------------- * Setup a promotion program that give 10% discount * Open a PoS restaurant open a table and add some products * The 10% discount should be applied * Leave the table and come back to it > Observation: The reward is gone Why the fix: ------------ We make sure to update the rewards when selecting the table, because when opening the table we use the one saved on the server. opw-4161408 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product lists and kanban boards now apply priority sorting only where it is needed in the user interface, instead of as a default rule everywhere. This should improve performance when working with products while preserving the expected ordering in relevant views.
Original PR description
For performance reasons, the priority field is moved from the model's _order to the related tree & kanban views --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product listings now avoid using the priority value as a default sorting rule, which can slow down larger databases. The same priority-based ordering is kept only where users see product lists or kanban boards, improving performance without changing day-to-day workflows.
Original PR description
For performance reasons, the priority field is moved from the model's _order to the related tree & kanban views
This update fixes an issue where users were seeing work orders assigned to other employees, even when using the 'My Work Orders' filter. The problem stemmed from incorrect cache handling after a PIN code was entered. Now, users will only see work orders assigned to their own account, ensuring accurate shop floor visibility.
Original PR description
### Steps to Reproduce * Navigate to the Employees app and set a PIN code for Mark Demo * In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin * Open the Shop Floor…
### Steps to Reproduce * Navigate to the Employees app and set a PIN code for Mark Demo * In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin * Open the Shop Floor interface, adding Michael Admin and Mark Demo as active employees * Click on the My WO filter and select Michael * Switch to Mark Demo and enter his PIN code ### Current Behavior * The work orders assigned to Michael are displayed for Mark, even with the My WO filter enabled. ### Expected Behavior Only the work orders assigned to Mark should be displayed ### Reason This issue occurs when a PIN is activated for an employee. When the PIN validation pop-up is displayed, the cache cleanup is performed for the previously logged-in user rather than the newly connected user. Consequently, the old user's workorders remain visible because the cache is not refreshed correctly. ### Fix Ensure that the cache is cleared only after the PIN is successfully validated and the user is connected. Additionally, verify that the My WO filter corresponds to the newly connected user before updating the cache. This will ensure that only the relevant work orders are displayed. opw-4256568
This update fixes an issue where the kitchen display incorrectly prioritized display lines when reducing product quantities in POS orders. Now, the system correctly sorts display lines based on their stage (e.g., 'To Cook', 'Ready'), ensuring the most relevant line is updated first. This improves the efficiency of order preparation.
Original PR description
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line…
In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed. Steps to reproduce: 1. In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order. 2. Add another order with the same product and internal note but with a quantity of 5. 3. In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready." 4. In the POS, reduce the quantity of the second order line (quantity 5) to 4. Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage). Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines. Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. opw-4354093