Monday, December 30, 2024
12 changes · saas-17.2
Miscellaneous changes
Issue: - When an employee has timesheets older than 2 weeks, opening timesheets for a new week displays a "No Timesheets Found" banner, and the ability to navigate the grid to the previous week or display a month is disabled. Steps To Reproduce: 1. Go to the Timesheets app. 2. Ensure there are only timesheets older than 2 weeks. 3. Exit the Timesheets app and reopen it. 5. Notice the "No Timesheets Found" banner is displayed. 6. Observe that the ability to naviga
Original PR description
Issue:
- When an employee has timesheets older than 2 weeks, opening timesheets for a new week displays a "No Timesheets Found" banner, and the ability to navigate the grid to the previous week or display a month is disabled.
Steps To Reproduce:
1. Go to the Timesheets app.
2. Ensure there are only timesheets older than 2 weeks.
3. Exit the Timesheets app and reopen it.
5. Notice the "No Timesheets Found" banner is displayed.
6. Observe that the ability to navigate to previous weeks or display a month is disabled.
Solution:
- this issue was fixed here: https://github.com/odoo/enterprise/pull/64792/commits/1f2ef9fd9200045b556a6dbcefd2dd3f57098cc8 this is a simple backport of the fix to the 17.0 branch.
opw-4238024
Forward-Port-Of: odoo/enterprise#76041### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. community: https://github.com/odoo/odoo/pull/190320 opw-4357325 Forward-Port-Of: odoo/enterprise#75915 Forward-Port-Of: odoo/enterprise#75502
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++] Forward-Port-Of: odoo/enterprise#75962
Original PR description
Before this commit, spans with no attribute and no special style were unwrapped by the OdooEditor, meaning the span itself disappeared, leaving its content in the parent element. This behavior breaks translations, as the whole span is used as a key to match translations After this commit, those spans are not removed. opw-3746922 opw-4318712 [++] Forward-Port-Of: odoo/enterprise#75962
**Issue:** Tax reports can't be exported as PDFs.  **Expected:** Users should be able to generate tax reports PDFs. **Steps to reproduce:** - Activate Accounting app; - Install the Argentina localization; - Move to the Argentine company; - Go to `Accounting` > `Reporting` > `Tax Report`; - Change selection to display some lines (or add invoice lines); - Print
Original PR description
**Issue:** Tax reports can't be exported as PDFs.  **Expected:** Users…
**Issue:** Tax reports can't be exported as PDFs.  **Expected:** Users should be able to generate tax reports PDFs. **Steps to reproduce:** - Activate Accounting app; - Install the Argentina localization; - Move to the Argentine company; - Go to `Accounting` > `Reporting` > `Tax Report`; - Change selection to display some lines (or add invoice lines); - Print PDF report. **Cause:** A fix (https://github.com/odoo/enterprise/commit/4c45cd704a7ddd46c93a1d8b8f5f3cf6934215a4#diff-8eb5e11a8f74f533b8999b3a5382c0d750bc87d2acc16ff5b4225775ba3ddd86L50) badly backports a correction for Argentine reports. This implies all Odoo users need to update their `account_reports` module to update the report view. **Fix:** Revert backport and keep useless currencies' display removal in subheaders only.  opw-4431015 opw-4430982 opw-4427336 opw-4430855 opw-4430735 Forward-Port-Of: odoo/enterprise#76155
**Problem**: After this commit: https://github.com/odoo/odoo/commit/cf8f0ff7ba4bb33425003399bc4e5b33d3d5629a the toolbar is hidden when it overflows (`this.toolbar.classList.toggle('d-none', distToScrollContainer < OFFSET / 2);`). This behavior is not suitable for selections containing elements with a height that exceeds the viewport, as the toolbar becomes inaccessible. **Solution**: Ensure the toolbar is always visible, even when overflowing. In such cases, reposition the toolbar to alig
Original PR description
**Problem**: After this commit: https://github.com/odoo/odoo/commit/cf8f0ff7ba4bb33425003399bc4e5b33d3d5629a the toolbar is hidden when it overflows (`this.toolbar.classList.toggle('d-none',…
**Problem**:
After this commit:
https://github.com/odoo/odoo/commit/cf8f0ff7ba4bb33425003399bc4e5b33d3d5629a the toolbar is hidden when it overflows (`this.toolbar.classList.toggle('d-none', distToScrollContainer < OFFSET / 2);`). This behavior is not suitable for selections containing elements with a height that exceeds the viewport, as the toolbar becomes inaccessible.
**Solution**:
Ensure the toolbar is always visible, even when overflowing. In such cases, reposition the toolbar to align with the top of the selection, providing consistent accessibility.
**Picture before fix**
***top***
***bottom***
**Picture after fix**
***top***
***bottom***
**Steps to reproduce**:
1. Add an image to the editor that overflows the viewport.
2. Select the image.
3. Observe that the toolbar does not appear.
opw-4398551
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#190465Previously, the "Images Subtitles" template in the Megamenu had an issue where the images were stretching vertically to fill the container's height. Adding an additional class to the container fixes the styling and maintains the images' correct aspect ratio. task-4203427  Forward-Port-Of: odoo/odoo#191932 Forward-Port-Of: odoo/odoo#182903
Original PR description
Previously, the "Images Subtitles" template in the Megamenu had an issue where the images were stretching vertically to fill the container's height. Adding an additional class to the container fixes the styling and maintains the images' correct aspect ratio. task-4203427  Forward-Port-Of: odoo/odoo#191932 Forward-Port-Of: odoo/odoo#182903
Before this fix it was not possible to reconcile the stock valuation lines created from PoS as one of them was missing the partner_id Steps to reproduce: ------------------- * Activate automatic stock valuation for the `All` category * Sell a product and ship it later * Close the session and go to the accounting entries > Observation: 2 of them are not reconciled, when clicking on reconcile it was not finding the good one to reconcile with opw-4395468 Forward-Port-Of: odoo/odoo#190
Original PR description
Before this fix it was not possible to reconcile the stock valuation lines created from PoS as one of them was missing the partner_id Steps to reproduce: ------------------- * Activate automatic stock valuation for the `All` category * Sell a product and ship it later * Close the session and go to the accounting entries > Observation: 2 of them are not reconciled, when clicking on reconcile it was not finding the good one to reconcile with opw-4395468 Forward-Port-Of: odoo/odoo#190519
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div` elements for the first and last columns (or sometimes only one of them). This occurs because the columns are partially selected (content but not container). **Solution**: To ensure `range.extractContents` removes the columns completely, extend the selection to encompass the entire content of the
Original PR description
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div`…
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div` elements for the first and last columns (or sometimes only one of them). This occurs because the columns are partially selected (content but not container). **Solution**: To ensure `range.extractContents` removes the columns completely, extend the selection to encompass the entire content of the `o_text_columns` element when the selection starts at the first leaf and ends at the last leaf within the columns. **Steps to reproduce**: 1. Open the editor. 2. Create columns (any number). 3. Select all content (e.g., with `Ctrl+A`). 4. Press `Backspace` to delete the content. 5. Observe that the DOM still contains `o_text_columns` and `row` elements, even though the content appears deleted. opw-4350486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191671 Forward-Port-Of: odoo/odoo#189978
Step to Reproduce: 1. Enter the edit mode of Homepage 2. click on drop zone area having "Drag building blocks here" message. -> sometime the "drag and drop a building block here" unexpectedly moves up. which should stay as it is. Before this commit, all `<p>` and `<div>` elements were considered as potential PowerBox elements, making them editable using the `/` command. This occurred even when the elements had the `o_not_editable` class or `contenteditable="false"` attribute. For
Original PR description
Step to Reproduce: 1. Enter the edit mode of Homepage 2. click on drop zone area having "Drag building blocks here" message. -> sometime the "drag and drop a building block here" unexpectedly moves…
Step to Reproduce: 1. Enter the edit mode of Homepage 2. click on drop zone area having "Drag building blocks here" message. -> sometime the "drag and drop a building block here" unexpectedly moves up. which should stay as it is. Before this commit, all `<p>` and `<div>` elements were considered as potential PowerBox elements, making them editable using the `/` command. This occurred even when the elements had the `o_not_editable` class or `contenteditable="false"` attribute. For example, in the case of the `#wrap` element, it has the `o_editable` class along with `contenteditable="false"`. This caused PowerBox element or placeholders to be added unnecessarily, even though no text editing was allowed. In this commit, we adapted the solution merged[1] in master and specify the selector to make sure that no command hint shown on div while having `o_not_editable` class or `contenteditable=false` attribute. [1] https://github.com/odoo/odoo/commit/302250cdde936a47048b8f3403e024e2e617ace7 Before this PR :  Desired behavior after PR is merged: No hint/placeholder is added to contenteditable false block, resulting in data editor message to stay on its place. task-3443430 Forward-Port-Of: odoo/odoo#153001
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking
Original PR description
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the…
### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation. ### Steps to reproduce: - Configure sendcloud shipping method + website + payment providers - In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg). - Create 2 storable products with respective weigth 1 and 100 kg. - Publish them on the website for sale. - Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier. - Repeat the operation with the other product to generate a seconde SO. - Back to your main window > Inventory Overview > Delivery Orders - Select both deliveries > Action > Validate (in batch) #### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website) #### > the UserError of the second DO rollbacked its validation in Odoo. ### Fix: As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side. ### Note: It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops. enterprise: https://github.com/odoo/enterprise/pull/75502 opw-4357325 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191235 Forward-Port-Of: odoo/odoo#190320
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191780 Forward-Port-Of: odoo/odoo#191066
Original PR description
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191780 Forward-Port-Of: odoo/odoo#191066
Issue: ====== We can't insert a link with `/url` in mass mailing Steps to reproduce the issue: ============================= - Install website and email marketing - Create a new mass mailing - Add a button using `/button` - Add a label - Write `/` in url and choose any option make sure to click on it using the mouse - Save - The link isn't inserted Origin of the issue: ==================== When we click to select an item, the event `mousedown` is triggered on the document which
Original PR description
Issue: ====== We can't insert a link with `/url` in mass mailing Steps to reproduce the issue: ============================= - Install website and email marketing - Create a new mass mailing - Add a button using `/button` - Add a label - Write `/` in url and choose any option make sure to click on it using the mouse - Save - The link isn't inserted Origin of the issue: ==================== When we click to select an item, the event `mousedown` is triggered on the document which will force a wysiwyg blur. So the selection is no more in the editable and we can't insert the link. Solution: ========= To avoid the blur, we add the selector of the autocomplete to the selectors that delay the blur. opw-4283325 Forward-Port-Of: odoo/odoo#186638