Wednesday, January 17, 2024
5 changes · 17.0
Resolved issues and error corrections
The report editor in Web Studio had a critical issue where it couldn't properly save custom changes to inherited reports without breaking the inheritance structure. This fix changes how the editor saves modifications by creating a complete copy of the report layout as an inherited view, ensuring all customizations are preserved correctly and the editor works reliably for users making report changes.
Original PR description
Forward-Port-Of: odoo/enterprise#53791
Fixed critical issues when multiple point-of-sale systems use the same Worldline payment terminal simultaneously. The update prevents system crashes caused by conflicting requests and ensures each payment terminal correctly routes responses to the right checkout location. This improves reliability for businesses operating multiple checkout lanes or locations sharing the same payment hardware.
Original PR description
Mirror of the following PR for WorldlineDriver_W: https://github.com/odoo/enterprise/pull/53951 Apart from the changes same as in the mentionned PR desribed below this PR also improves the…
Mirror of the following PR for WorldlineDriver_W: https://github.com/odoo/enterprise/pull/53951 Apart from the changes same as in the mentionned PR desribed below this PR also improves the WorldlineDriver_W. It adds some very much needed logging and smart sleep mechanics already present in the WorldlineDriver_L. It also adds a unique buffer size for all the variables used by C++ code (also already on WorldlineDriver_W). Finally it adds some comments to the C++ variables mapping to easily identify them (you guessed it, also on WorldlineDriver_W already). The description below matches the https://github.com/odoo/enterprise/pull/53951 Currently, if you have 2 browser tabs or 2 different PoS using the same Worldline terminal, there was a way to do some damage if requests were started at the same time 1) Since we call C++ code through a thread without a mutex, it was possible to get a race condition and provoke a segmentation fault 2) Even if there was no race condition, we were not specifying to who the driver is replying all the time. So a cancel request on the 1st PoS could cancel an active transaction on the 2nd PoS. This PR fixes both issues by specifying the owner of the request and the cid in every single response sent from the driver to the frontend. I am also adding the cid to the data sent in a cancellation request as otherwise we don't know which transaction line we're cancelling. It replaces the threads by a queue to avoid race conditions in the future and respect the condition that all the Driver class logic must be executed in the "run" method for safe execution. It also fixes the Last Transaction Status popup which could accidentally "catch" the response from a transaction since it doesn't care about the cid. This PR also makes the popup consistent with the response (using error popup for a response resulting in an error). task-3676153 Forward-Port-Of: odoo/enterprise#54073
This update fixes three critical issues in the manufacturing shopfloor module that were preventing proper production order closure and workorder management. The fixes address problems with closing multiple productions simultaneously, restore access to the shopfloor from production forms, and correct workorder deletion behavior to prevent unintended data transfers.
This update fixes a critical bug in the Journal Report where using the Analytic Groupby feature caused the system to crash. The fix prevents users from attempting to use this unsupported feature and also disables Horizontal Grouping and Period Comparison options that were making the report difficult to read. Users will now see a clear message if they try to use these features instead of encountering an error.
Original PR description
Descritpion of the issue/feature this commit addresses: At the moment, trying to use the analytic groupy on the Journal Report results in a traceback. It is not possible to use it at all. --- Steps…
Descritpion of the issue/feature this commit addresses: At the moment, trying to use the analytic groupy on the Journal Report results in a traceback. It is not possible to use it at all. --- Steps to reproduce: 1-Activate the Analytic Accounting in the settings 2-Activate the Analytic Groupby in the Journal Report's options 3-Go to the Journal Report and apply any Analytic Groupby filter 4-A traceback shows up --- Desired behavior after this commit is merged: This commit handles the issue by adding a check at the very start of the custom handler of the Journal Report. This new check verifies that no analytic groupby filter is being applied on the report. If it is the case, an error is raised to tell the user the feature is not supported by that report. While at it, the Horizontal Grouping and Period Comparison options have also been disabled because their rendering was making the report unreadable and they added no value to it. With this commit, the Journal Report can't use Analytic Groupby, Horizontal Grouping or Period Comparison. --- task-3600349 Forward-Port-Of: odoo/enterprise#53807
This fix corrects two critical bugs in the manufacturing unbuild process. When unbuilding a manufacturing order where the actual quantity produced differs from the original planned quantity, the system now correctly uses the actual produced quantity instead of the planned quantity. This ensures inventory adjustments are accurate and match the actual production output.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1, Qty: 1
- Create a Mo to produce 5 units of P1
- Confirm and mark as done the MO
- Unlock the MO
- Change the qty produced to 20
- Try to unbuild the MO
Problem:
Bug 1: The wizard triggered is set with the product_qty(5) instead of the qty_produced (20)
Bug 2: Set the product_qty to 5 and validate the unbuild, in result
the stock moves in the unbuild order are 20 units instead of 5 units
opw-3630001
Forward-Port-Of: odoo/odoo#148676
Forward-Port-Of: odoo/odoo#146211