Monday, February 17, 2025
3 changes · 18.0
Resolved issues and error corrections
The Import Serials/Lots dialog in inventory receipts now displays its fields in the intended two-column layout instead of stacking them incorrectly. This improves usability when entering or importing lot and serial information, especially during purchase receipt processing.
Original PR description
Issue: The grid elements on the import Lots dialog are placed in one column instead of two, which misses up the layout. Reproduction steps: 1. install "purchase_stock" 2. create a product tracked by…
Issue:
The grid elements on the import Lots dialog are placed in one column instead of two, which misses up the layout.
Reproduction steps:
1. install "purchase_stock"
2. create a product tracked by lots
3. make an RFQ for that product and confirm it
4. click on the generated receipt smart button
5. in "Operations" tab, click fa-list icon to open the dialog
6. in the dialog, click "Import Serials/Lots
Reason:
The bug was introduced in [239e75b1385fa023e97396baa0c8d46c50997dda](https://github.com/odoo/odoo/commit/239e75b1385fa023e97396baa0c8d46c50997dda#diff-1377579fdb76de80cd31ca67d798b752a90600ab4c82a3c8799786a130b7a46fR431-R433), where the following style was added
```css
.o_cell:first-child:last-child {
grid-column: span 2;
}
```
which applies for the children of the first and the third grid elements; However, since the first and the third grid elements have `display: contents`, the `grid-column: span 2` of their children messes up the grid layout, and makes it 4x1 instead of 2x2.
The fix:
Remove `display: contents` on the first and third grid elements, as it seems to not be useful. Have tested on web and mobile layouts.
opw-4505725Restaurant kitchen preparation receipts now show the time the order was sent from the point of sale, using the cashier device's current time. This prevents missing times for unsynced orders and avoids showing UTC instead of the local business time.
Original PR description
When printing a preparation receipt the correct time was not shown (It was always UTC time). Also when the order was not sent to the server the time was not shown at all. Steps to reproduce: ------------------- * Setup a kitchen printer for a PoS * Open PoS go on a table and add some products * Click on the Order button > Observation: The time is not shown in the receipt * Leave the table and come back to it to make sure order is sent to the server * Add another product and send the order to the kitchen > Observation: The time is in UTC Why the fix: ------------ Instead of relying on the write date of the order we now rely on the current time of the client to show the time in the receipt. This time will always correspond to the time the order was sent to the kitchen. opw-4454102
Users now see the correct access-related error when trying to split a PDF in a Documents folder they no longer have permission to use. This avoids a confusing unrelated message and helps users understand that the action is blocked by folder permissions.
Original PR description
## Issue: When we upload a pdf document to a folder and remove access to that folder, if we attempt to split the document it shows an unralted error. ## Steps to reproduce: - install…
## Issue: When we upload a pdf document to a folder and remove access to that folder, if we attempt to split the document it shows an unralted error. ## Steps to reproduce: - install documents_project - Open documents app - Select "Projects" folder - Upload a pdf document - Edits "Projects" folder sharing settins to remove Mitchell Admin and restrict Internal users to None - Select the pdf document and click on "Split" button - Try to split the document - Not possible due to folder access error but the error message is not related to the issue ## Solution: - In the `PdfManager` component, we noticed that inside the `_sendChanges` method, we don't verify whether the response from the `pdf_split` controller is JSON before calling `.json()`. As a result, when we attempt splitting, an access error is raised in the controller, and Werkzeug returns an HTML error response by default. This leads to an error when `.json()` is called, which is eventually caught in `_applyChanges` and displayed in the notification instead of the intended access error. - this fix handles the error response from the `pdf_split` controller better by checking if the reponse is ok before calling `.json()`, and handling the error response accordingly. OPW-4453150