Wednesday, October 2, 2024
5 changes · saas-17.4
Miscellaneous changes
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contra
Original PR description
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click…
Steps to reproduce: - Download payroll and Time off - Time Off > Configuration > Time off types - In Paid and unpaid type, set 'Take Time Off in' to Hours - Employees > Pick one > Time off - Click calendar day and create 2 leaves: -- Paid type, Custom hours from 8:00 to 9:00 -- Unpaid type, Custom hours from 9:00 o 10:00 - Time off > Management > Time off - Approve and validate both leaves - The employee needs to have a running contract so if needed -- Payroll > Contracts > Contracts > New - Payroll > Regenerate work entries for your employee - Leaves are generated as a single block of type 'Generic time off' The leaves are merged. The Interval class sorts its entries' boundaries in such a way that it will see the start of an entry before the stop of the previous one if the start/stop time are the same. Its counterpart WorkIntervals does not merge overlapping entries. i.e with entries 8:00-9:00 and 9:00-10:00 Intervals will interpret as: 8:00 start, 9:00 start, 9:00 stop, 10:00 stop => Merged entries. And WorkIntervals as: 8:00 start, 9:00 stop, 9:00 start, 10:00 stop => No merged entries. This happens regardless of the content of the merged resources, in this case two different types of leaves which should not be treated the same by nature (Paid/Unpaid). When going though the leaves, we currently loop over the associated work intervals, this is part of the reason several leaves are processed as a single interval. The only reason we need the attendance interval is because some work entry types can take precedence over leaves (For instance a long term medical disability must supercede a public holiday). In the interest of avoiding a change in the return type of the method '_get_interval_leave_work_entry_type' we instead rebuild the intervals with the bounds of the leave and the work entry type of the attendance. opw-4193334 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182273
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to
Original PR description
This issue occurs only in frontend debug (which I initially missed but odony caught), the problem is that the `InputConfirmationDialog` used for the creation dialog has a required `onInput` callback in its props but none is provided by the "new api key" button case. Props are (I assume) only validated in debug mode, so that's the only situation in which the error appears... and blocks users. While `onInput` seems like a useful hooks for input validation and stuff, it doesn't seem necessary to mandate it, and the code specifically checks if it's unchecked (and ignores it in that case). OPW-4194305 Forward-Port-Of: odoo/odoo#182285
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
Original PR description
In #167973 (merged in 17.0+), we enabled the audit trail by default when loading the German localization. TSB requested that we indicate this explicitly in the manifest. task-none Forward-Port-Of: odoo/odoo#182295
Starting from `18.0`, text highlight effects are used for snippets customizations in themes, which means snippets can be provided with highlighted content (in a minimal format) that allows the JS code to rebuild the SVGs later when it's needed: ``` <span class="o_text_highlight o_text_highlight_[highlightId]" style="--text-highlight-width: ...; --text-highlight-color: ...;"> text content ... </span> ``` The highlights code provides some tools to adapt them when the content
Original PR description
Starting from `18.0`, text highlight effects are used for snippets customizations in themes, which means snippets can be provided with highlighted content (in a minimal format) that allows the JS…
Starting from `18.0`, text highlight effects are used for snippets
customizations in themes, which means snippets can be provided with
highlighted content (in a minimal format) that allows the JS code to
rebuild the SVGs later when it's needed:
```
<span class="o_text_highlight o_text_highlight_[highlightId]"
style="--text-highlight-width: ...; --text-highlight-color: ...;">
text content ...
</span>
```
The highlights code provides some tools to adapt them when the content
is changed: add & remove text, resize… But It doesn't handle the case
of a dropped snippet with highlights.
The goal of this commit is to be able to build the highlights of a
snippet once dropped.
Remark: The behavior fixed in this commit wasn't possible until `18.0`
(with themes snippets using highlights) but we target `17.0` to handle
every possible customization that uses the effects before themes
refactoring.
task-4215788
Forward-Port-Of: odoo/odoo#182452
Forward-Port-Of: odoo/odoo#182208## Steps to reproduce: 1. Create a new batch picking (in the Inventory app) 2. Set an operation type and save 3. Open the batch picking in the barcode application ## Before this commit: Because the batch picking has an operation type, Odoo will try to load it from the cache, but since the batch picking is empty, the backend did not send any `stock.picking.type`. ## After this commit: Load the `stock.picking.type` in the frontend cache. opw-4175883 Forward-Port-Of: odoo/enterprise#
Original PR description
## Steps to reproduce: 1. Create a new batch picking (in the Inventory app) 2. Set an operation type and save 3. Open the batch picking in the barcode application ## Before this commit: Because the batch picking has an operation type, Odoo will try to load it from the cache, but since the batch picking is empty, the backend did not send any `stock.picking.type`. ## After this commit: Load the `stock.picking.type` in the frontend cache. opw-4175883 Forward-Port-Of: odoo/enterprise#70400