This fix is to solve a bug that appears in the demo data of the l10n_be specifically in the cash journal using an income type account for the negative cash difference which should be an expense type. current behavior: using income type in a loss account. desired behavior: expense account instead. opw-3642586 Forward-Port-Of: odoo/odoo#146936

This fix is to solve a bug that appears in the demo data of the l10n_be specifically in the cash journal using an income type account for the negative cash difference which should be an expense type. 
current behavior: using income type in a loss account.
desired behavior: expense account instead.
opw-3642586

Forward-Port-Of: odoo/odoo#146936

This commit simply changes the title of the skills resume wizard for clarity. task-3660000 Forward-Port-Of: odoo/odoo#146294

This commit simply changes the title of the skills resume wizard for clarity.

task-3660000

Forward-Port-Of: odoo/odoo#146294

In 17.0 the calendar view was revamped and the boolean field `all_day` started being rendered with the boolean_toggle widget. This widget, however, behaves differently than the boolean widget without passing explicit props. This caused the onchange call not to be made after this change. This commit fixes this by passing the autosave option as False on the field. task-3669879 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is m

In 17.0 the calendar view was revamped and the boolean field `all_day` started being rendered with the boolean_toggle widget. This widget, however, behaves differently than the boolean widget without passing explicit props. This caused the onchange call not to be made after this change. This commit fixes this by passing the autosave option as False on the field.

task-3669879

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#148874

Fix 1: Before this commit, the smart button on the employee would display `x/y` Time Off, indicating remaining leaves over max leaves. However, while `y` was correctly taking into account current allocations only, `x` didn't, resulting in incoherent values. Reproduce the issue: - For an employee, create an expired allocation and validate it of x days; - Create an additional allocation which is still valid today of y days and validate it as well; - Go on the employee form view; - Time O

Fix 1:

Before this commit, the smart button on the employee would display `x/y` Time Off, indicating remaining leaves over max leaves. However, while `y` was correctly taking into account current allocations only, `x` didn't, resulting in incoherent values.

Reproduce the issue:
- For an employee, create an expired allocation and validate it of x days;
- Create an additional allocation which is still valid today of y days and validate it as well;
- Go on the employee form view;
- Time Off smart button display (x+y)/y instead of y/y

Fix 2:

Before this commit, there was no way to track error inducing leaves that were created through a bug or that were already created in the database prior to the changes brought in version 17.0. This commit adds a new property in the leave data indicating the id and the start date of the leave that is causing the discrepancies in the database and displays a warning on the dashboard if there are some error inducing leaves.

Forward-Port-Of: odoo/odoo#151288

After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens when the cron is run after the first trigger of the recurrence. Imagine we have an alarm of 5 minutes before the event, the call for_setup_alarm from _send_reminder will try to get the next event in the recurrency to notify. However, the SQL query uses `WHERE start > now` and if the cron trigger runs be

After https://github.com/odoo/odoo/pull/118738, we start generating a single cron trigger per recurrence, however it fails to create the cron trigger for daily recurrences. The main issue happens when the cron is run after the first trigger of the recurrence. Imagine we have an alarm of 5 minutes before the event, the call for_setup_alarm from _send_reminder will try to get the next event in the recurrency to notify. However, the SQL query uses `WHERE start > now` and if the cron trigger runs before the event is started (most cases) this query will return the event that we're notifying. This commit fixes this by passing the events that are being notified in the context of the `_setup_alarm` call, so that we can exclude them from the query.

How to reproduce?

Install calendar
- Create a recurring event with daily recurrence repeating for 3 days. Invite Demo, set an email alarm for 5 min before the event and create the event
- A cron trigger will be created for 5 min before the event
- Change your computer's time so that it is 5min before the event
- The cron trigger will be called and it should create a new cron trigger for the other day, however no cron trigger is created

Issue: SQL query in _setup_alarms in calendar.recurrence is getting the first event with start > now, however it returns the event that was already notified

Solution: Pass in the context which events are already being notified so that they are excluded from the query

task-3663455

Forward-Port-Of: odoo/odoo#147914

`getLoggedInAsText` is a function, due to missing brackets the function content was dumped instead of evaluation of function. opw-3701333 Before  After  Forward-Port-Of: odoo/odoo#151523

`getLoggedInAsText` is a function, due to missing brackets the function content was dumped instead of evaluation of function.

opw-3701333

Before
![before](https://github.com/odoo/odoo/assets/6569390/710abe68-93ab-4d9d-a4e7-3ee376bff2cd)

After
![after](https://github.com/odoo/odoo/assets/6569390/1ce01a83-91be-4f21-896f-dc414b722114)

Forward-Port-Of: odoo/odoo#151523

The `see records` action that drill downs to the specific AccountMoveLines that match the formula domain would break if we left some optional formula arguments empty (specifically concerns the offset and companyId arguments). This revision ensures that we use their default value when the arguments are not provided. Task: 3621110 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed t

The `see records` action that drill downs to the specific AccountMoveLines that match the formula domain would  break if we left some optional formula arguments empty (specifically concerns the offset and companyId arguments). This revision ensures that we use their default value when the arguments are not provided.

Task: 3621110

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151423
Forward-Port-Of: odoo/odoo#148284

Since the refactoring of base_automation, the 'website-publishing' option of server actions was broken; it did get included in the view but outside of a group node and without labels. The result was a floating checkbox which would trigger a label-less char field upon selection - not the clearest of UIs. This commit properly insert these fields into a group node. Note that since server actions can normally only be reached by going through technical menus, the fact that this section of view is

Since the refactoring of base_automation, the 'website-publishing' option of server actions was broken; it did get included in the view but outside of a group node and without labels. The result was a floating checkbox which would trigger a label-less char field upon selection - not the clearest of UIs.

This commit properly insert these fields into a group node. Note that since server actions can normally only be reached by going through technical menus, the fact that this section of view is now in a group_no_one-only section should not change anything functionally.

Forward-Port-Of: odoo/odoo#151498

Commit[1] implemented a way to output an image as its raw representation `<img src="data:image/png;base64......." />` It is useful for integrating an image of a record not accessible publicly. However the original commit forgot to allow the img node to handle the options passed to the field. Classes in particular were absent After this commit, the options are handled correctly, and the image in raw mode has the right classes. opw-3517861 [1]: f8b901d04b6c5874b56576f9b89899b2812296f2

Commit[1] implemented a way to output an image as its raw representation `<img src="data:image/png;base64......." />`
It is useful for integrating an image of a record not accessible publicly.

However the original commit forgot to allow the img node to handle the options passed to the field. Classes in particular were absent

After this commit, the options are handled correctly, and the image in raw mode has the right classes.

opw-3517861

[1]: f8b901d04b6c5874b56576f9b89899b2812296f2

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151410
Forward-Port-Of: odoo/odoo#150140

Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs: odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp [Excerpts of those massive useless logs](https://github.com/odoo/odoo/files/14065596/odoo.log.txt) This is because this method is a callback that can come in a different thread, creating a race condition. There's no problem on checking wether the directory exists before creating the file

Without this patch, running this command on an environment where the tour will fail, will create massive and useless logs:

    odoo --stop-after-init -i auth_totp --test-enable --test-tags /auth_totp

[Excerpts of those massive useless logs](https://github.com/odoo/odoo/files/14065596/odoo.log.txt)

This is because this method is a callback that can come in a different thread, creating a race condition.

There's no problem on checking wether the directory exists before creating the file, and then safeguarding from the problem.

@moduon MT-1075



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151364

When changing the GST treatment on customers, update draft invoices task-3339052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151503

When changing the GST treatment on customers, update draft invoices

task-3339052


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151503

Prior to this commit, using an online payment method with an image in self-ordering mode resulted in an issue preventing the opening of the mobile menu. The specific error encountered was: `TypeError: Object of type bytes is not JSON serializable` This issue arose due to the image field being of type bytes. Since the image field is not necessary for self-ordering, this commit addresses the problem by preventing the loading of the image for a payment method, resolving the serialization error.

Prior to this commit, using an online payment method with an image in self-ordering mode resulted in an issue preventing the opening of the mobile menu. The specific error encountered was:
`TypeError: Object of type bytes is not JSON serializable`

This issue arose due to the image field being of type bytes. Since the image field is not necessary for self-ordering, this commit addresses the problem by preventing the loading of the image for a payment method, resolving the serialization error.

opw-3624798

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151388

## Description Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value. ## Analysis Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. ### Before this commit All of the select menu are sorted when the user select a value in one of them. This is not

## Description
Having several select menu containing a lot of options on a page may lead to significant wait times and browser crashes when selecting or deleting a value.

## Analysis
Sorting of the options is being computed on each mounted select menu during the useEffect() hook since this commit: https://github.com/odoo/odoo/commit/8a4485748f49c5b8fdb780b0bcd2435eeadd63b. 

### Before this commit
All of the select menu are sorted when the user select a value in one of them. This is not necessary as the sorting is already handled in beforeOpen.

### After this commit
Selecting or deleting a value from a select menu is significantly faster as the sorting is not being unnecessarily computed in useEffect() anymore.

## Benchmarks
When importing an Excel file containing 70 columns as an invoice with subfields search enabled, selecting/deleting an option from a select menu:
|             | Before  | After  |
|-------------|---------|--------|
| Selecting      | 31.2 s | 1.5 s |
| Deleting      | 35.9 s | 1.6 s |


## References
opw-3616438



---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#151318
Forward-Port-Of: odoo/odoo#146324

Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear. The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it.

Recently, a new option 'always_range' has been added to the datetime field (task 3628069, commit bc98aad). This option forces the display of the arrow between the two dates from the start. Before that, you would add a first date, click a button to add a second date and then only would the arrow appear.

The oversight here is when the field is empty AND readonly. In that case, you have an visible arrow next to the label but you can't do anything with the field anyway. So better not to show it.

This commit makes sure to not display the arrow in this case.

task 3690523

Forward-Port-Of: odoo/odoo#149912

Before this commit, it was not possible to create a new picking on mobile if this picking has multiple moves. How to reproduce: - Open Odoo on mobile (or on desktop but simulate mobile device with devtools); - Inventory > Operations > Transfers; - Create a new transfer (a receipt for example); - In its operations (moves), add a new product, then add a second product. - Try to save or validate the picking -> A warning prevent to do it, saying you're trying to write on the field `product_q

Before this commit, it was not possible to create a new picking on mobile if this picking has multiple moves.

How to reproduce:
- Open Odoo on mobile (or on desktop but simulate mobile device with devtools);
- Inventory > Operations > Transfers;
- Create a new transfer (a receipt for example);
- In its operations (moves), add a new product, then add a second product.
- Try to save or validate the picking -> A warning prevent to do it, saying you're trying to write on the field `product_qty` instead of the field `product_uom_qty`.

What's happening:
For a unknown reason, the fields from the `stock.move` list view are saved once a second move is created, even if we're using the kanban view in the mobile version.
To avoid this issue, we force the `force_save` to be false for the field `product_qty` in the kanban view. That's way, it prevents the issue.

OPW-3577844

Forward-Port-Of: odoo/odoo#144282
Forward-Port-Of: odoo/odoo#143776

**Steps to reproduce the bug:** - Create a storable product P1: - Create a BoM: - type: subcontracting - Add vendor - Add any component - Create a purchase order with 3 units of P1 - Confirm the purchase order - Go to the picking - receive 2 units of P1 and validate it - create a backorder - Cancel the backorder - Try to update the purchased qty in the PO line **Problem**: A user error is triggered: “Nothing to check the availability for.” When upd

**Steps to reproduce the bug:**
- Create a storable product P1:
    - Create a BoM:
        - type: subcontracting
        - Add vendor
        - Add any component
- Create a purchase order with 3 units of P1
- Confirm the purchase order
- Go to the picking
- receive 2 units of P1 and validate it
- create a backorder
- Cancel the backorder
- Try to update the purchased qty in the PO line

**Problem**:
A user error is triggered:
“Nothing to check the availability for.”

When updating the quantity in the purchase order line, the
"_create_or_update_picking" function is called to search for a linked
picking and update its quantity. However, in our case, since no picking
can be updated, a new picking is created:
https://github.com/odoo/odoo/blob/783048616362702f/addons/purchase_stock/models/purchase.py#L271-L272

Subsequently, the moves are confirmed:
https://github.com/odoo/odoo/blob/e38ed7c780d35fb9d5d799ac783048616362702f/addons/purchase_stock/models/purchase.py#L277

However, as the product is subcontracted, the "action_assign" function
is called: https://github.com/odoo/odoo/blob/4055293873132d56fe3787c77e499808b136f300/addons/mrp_subcontracting/models/stock_move.py#L105-L106

Since there is no move in the confirmed state, a user error is
triggered: https://github.com/odoo/odoo/blob/d45996c9155b9576c74aa8c6c6f718f8ab4d0af6/addons/stock/models/stock_picking.py#L450-L453

**Solution**:
When updating the quantity in the purchase order, if no picking requires
an update, it is better to avoid creating a new picking.

opw-3616381

Forward-Port-Of: odoo/odoo#151422
Forward-Port-Of: odoo/odoo#150013

Current behavior before PR: - On table when we hit tab it displays toolbar as it sets selection between startPosition and endPosition. - On hitting tab it selects the text in the next cell completely, which should not happen. Desired behavior after PR is merged: - Now toolbar is not displayed on hitting tab. - selection is made to collapse at the end the lastNode of the cell. task-3475079 Forward-Port-Of: odoo/odoo#132807

Current behavior before PR:

- On table when we hit tab it displays toolbar as it sets selection between
startPosition and endPosition.
- On hitting tab it selects the text in the next cell completely, which
should not happen.

Desired behavior after PR is merged:

- Now toolbar is not displayed on hitting tab.
- selection is made to collapse at the end the lastNode of the cell.

task-3475079

Forward-Port-Of: odoo/odoo#132807

Current Behavior before PR: When we have some text in selection and we move away from the selection the the toolbar disappear. Desired behavior after this PR is megerd: The toolbar is still visible when we move far from the selected text. task-3054229 Forward-Port-Of: odoo/odoo#151354 Forward-Port-Of: odoo/odoo#117645

Current Behavior before PR:

When we have some text in selection and we move away from the selection the the toolbar disappear.

Desired behavior after this PR is megerd:

The toolbar is still visible when we move far from the selected text.

task-3054229

Forward-Port-Of: odoo/odoo#151354
Forward-Port-Of: odoo/odoo#117645

The helper `toggleCogMenuSpreadsheet`is quite slow atm. As much as this should be investigated, there is a quick win by cutting in the functional flow to insert a list in a spreadsheet and rely on the implementation by triggering the bus event related to tje insert of the list in a spreadsheet. This revision speeds up the related concerned tests by ~6.2 seconds on a local installation. Testing the modules `documents_spreadsheet > list view` and `documents_spreadsheet > insert_list_spreadsh

The helper `toggleCogMenuSpreadsheet`is quite slow atm. As much as this should be investigated, there is a quick win by cutting in the functional flow to insert a list in a spreadsheet and rely on the implementation by triggering the bus event related to tje insert of the list in a spreadsheet.

This revision speeds up the related concerned tests by ~6.2 seconds on a local installation.

Testing the modules `documents_spreadsheet > list view` and `documents_spreadsheet > insert_list_spreadsheet_menu`:

Average on 10 runs

Before: 11600 ms
After: 5400 ms

Forward-Port-Of: odoo/enterprise#55276
Forward-Port-Of: odoo/enterprise#55202

### Steps to reproduce issue: 1. In Appraisals settings, activate 360 feedback if it is not 2. Create and confirm an appraisal 3. Ask for a feedback, set deadline to today and send it 4. Go to emails list (debug) and open the feedback request mail 5. The survey is expired, which is expected 6. Repeat 3. and use the same settings except for the deadline, set it in the future 7. Repeat 4. 8. The survey is expired, which should not be the case - You can also observe the issue by opening

### Steps to reproduce issue:

1. In Appraisals settings, activate 360 feedback if it is not
2. Create and confirm an appraisal
3. Ask for a feedback, set deadline to today and send it
4. Go to emails list (debug) and open the feedback request mail
5. The survey is expired, which is expected
6. Repeat 3. and use the same settings except for the deadline, set it in the future
7. Repeat 4.
8. The survey is expired, which should not be the case
- You can also observe the issue by opening `survey.user.input.view.tree.inherit.appraisal` (debug) instead of emails list. No survey to click on but the deadline is visible.

### Explanation:

Deadline is not transmitted to answers in [action_send](https://github.com/odoo/enterprise/blob/df62564226d0ac9b4a3c7c489e5b2ff486dc7b2f/hr_appraisal_survey/wizard/appraisal_ask_feedback.py#L127-L130), which makes it not updating, despite being created with a deadline.

### Suggested Fix:

The fix from 17.0 (commit: aecbb5c3e9b708e117510fb4ffd60baed3b6930c) is working in multiple version ranging from 15.0 to 16.4, applying it from 15.0. A test is also added to ensure workflow is not compromised again.

opw-3665560

Forward-Port-Of: odoo/enterprise#55326
Forward-Port-Of: odoo/enterprise#54234