### Steps to reproduce: - Create a flexible working schedule with not even hours per day (e.g. 9:15) - Assign this working schedule to one of the employees - Create a time off type its request unit is hours - Create a time off for the employee that has the flexible calendar for one day - Notice the duration of the leave is rounded up ### Cause: This is happening because when calculating the leave duration for a flexible resource we are using ceil() to round up the hours variable ht

### Steps to reproduce:
	- Create a flexible working schedule with not even hours per day (e.g. 9:15)
	- Assign this working schedule to one of the employees
	- Create a time off type its request unit is hours
	- Create a time off for the employee that has the flexible calendar for one day
	- Notice the duration of the leave is rounded up

### Cause:
This is happening because when calculating the leave duration for a flexible resource we are using ceil() to round up the hours variable https://github.com/odoo/odoo/blob/ece2a795a303a1ce1b837a4b65e1cf99f1b717b5/addons/hr_holidays/models/hr_leave.py#L428-L429

### Fix:
Since we are not really benefiting from using ceil() as we are not
using it anyways in case of half-days so it is better to avoid rounding
the hours up.

opw-4640130

Forward-Port-Of: odoo/odoo#202707

Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves interval. To replicate: 1. set a timeoff to a flexible resource 2. open p

Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability.

This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves interval.

To replicate:
1. set a timeoff to a flexible resource
2. open planning app
3. in the gantt view, the day in which the timeoff was set should be grayed.

ticket-id: 4492625
enterprise: [79532](https://github.com/odoo/enterprise/pull/79532)

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#202849
Forward-Port-Of: odoo/odoo#198032

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#203509 Forward-Port-Of: odoo/odoo#201780

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#203509
Forward-Port-Of: odoo/odoo#201780

Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169 Forward-Port-Of: odoo/odoo#203057

Steps:
- create a stage from "To-Do" app
- reload the page

Actual result:
- stage disappear

Expected result:
- stage is shown as personal stage

opw-4637169

Forward-Port-Of: odoo/odoo#203057

Test introduced in 6a4c02e6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456) Forward-Port-Of: odoo/odoo#203225

Test introduced in 6a4c02e6 fails because the `attribute_line_ids` field is not visible by default in product forms.

Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456)

Forward-Port-Of: odoo/odoo#203225

Before this commit: The deduceURLfromText function was executed at the normalization step. This caused restrictions when creating links, as the link's href would be overridden if the label was deducible to a URL. Example: If a user wanted to link a WhatsApp URL to a phone number, the href would automatically change to tel:1234, making it impossible to set a different URL. After this commit: The deduceURLfromText function is no longer part of the normalization process. Instead: 1.

Before this commit:
The deduceURLfromText function was executed at the normalization step.
This caused restrictions when creating links, as the link's href would
be overridden if the label was deducible to a URL.

Example: If a user wanted to link a WhatsApp URL to a phone number, the
href would automatically change to tel:1234, making it impossible to set
a different URL.

After this commit:
The deduceURLfromText function is no longer part of the normalization
process. Instead:

1. It is executed only when the user change directly inside a link, not
when editing through a link popover. User change can be input, paste or
delete
2. If the user edits the link using the popover, the href will not be
overridden by deduceURLfromText.
3. If the current href differs from the deduced URL, the href remains
unchanged.
4. If the deduced URL matches the current href and the user changes the
link's text by typing, pasting or deleting, the href will also be
updated to reflect the text changes.

These adjustments ensure better flexibility and prevent unwanted
overrides when creating or editing links. Related link tests are also
adapted.

task-3787019




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

Forward-Port-Of: odoo/odoo#189623

Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator:

Versions
--------
- 17.0+

Steps
-----
1. Open website in French;
2. select a pricelist using CHF as currency;
3. add a product to the wishlist;
4. open wishlist in mobile view.

Issue
-----
With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated.

Cause
-----
View was probably designed with only English & USD in mind.

Solution
--------
Same approach as commit ba2a0d7e33e8 took for the product configurator:
- In full view, display `<fa-shopping-cart> Add`
- On mobile, display `<fa-shopping-cart>`

opw-4624112

Forward-Port-Of: odoo/odoo#202650

Users of SA localization needs to add a QR (resulting from the EDI validation) to their official invoices. This should occurs also for point of sales invoices but this is currently not working. Steps to reproduce: - With SA localization setup - Open POS session - Add a product - Invoice to a customer - Validate order - Check generated invoice Issue: QR is missing This occurs because we print the invoice before sending it to ZATCA. This way we generate an invoice without the nee

Users of SA localization needs to add a QR (resulting from the EDI
validation) to their official invoices. This should occurs also for
point of sales invoices but this is currently not working.

Steps to reproduce:
- With SA localization setup
- Open POS session
- Add a product
- Invoice to a customer
- Validate order
- Check generated invoice

Issue: QR is missing

This occurs because we print the invoice before sending it to ZATCA.
This way we generate an invoice without the needed fiscal information

opw-4562837

Forward-Port-Of: odoo/odoo#199039

Description of the issue/feature this PR addresses: - Setup an eWallet for POS and website - Place an order of eWallet top up from POS - Place an order of eWallet top up from ecommerce - Make sure both has the same ID, or any POS order that has the same ID with sale.order ID - You will see the loyalty issued becomes the sum of the unrelated model Current behavior before PR: - The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID Desired behavior after PR

Description of the issue/feature this PR addresses:
- Setup an eWallet for POS and website
- Place an order of eWallet top up from POS
- Place an order of eWallet top up from ecommerce
- Make sure both has the same ID, or any POS order that has the same ID with sale.order ID
- You will see the loyalty issued becomes the sum of the unrelated model

Current behavior before PR:
- The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID

Desired behavior after PR is merged:
- Only consider the order that comes from the sale order model



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

Forward-Port-Of: odoo/odoo#202433

Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-

Steps to reproduce:
  - Access with the demo user
  - Open Timesheet dashboard
  - Switch to list view

Issue: Access error will raise

Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f
Readonly account users have now read access to analytic account lines.
However, when sale_timesheet is installed, in the lowest access right it
is possible to see only the own timesheets, so the rule needed to be
limited as it occurs with Billing users.

Forward-Port-Of: odoo/odoo#203460

**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820 Forward-Port-Of: odoo/odoo#201212 Forward-Port-Of: odoo/odoo#196987

**issue:**

When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible.
The error message suggests archiving the payment; however, there is no option to archive it.

A more flexible error message should be used instead.

opw-4494820

Forward-Port-Of: odoo/odoo#201212
Forward-Port-Of: odoo/odoo#196987

Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the following causes: - portal composer has special margin/padding at the top to compensate with website header, so that scrolling on website keeps the composer at the top - portal composers should not autofocus on mount compared to backend views. The portal sharing page was mistakenly not conside

Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut.

This comes from the following causes:

- portal composer has special margin/padding at the top to compensate with website header, so that scrolling on website keeps the composer at the top
- portal composers should not autofocus on mount compared to backend views.

The portal sharing page was mistakenly not considered a portal composer at some point and was fixed by [1].

However had regression to include the margin/padding top compensation, thus it cut the 'Follow' button.

The margin/padding top is not pretty but it works fine for website. Here for project we want to ignore them. This commit fixes the issue by ignoring project sharing for the padding/margin top compensation, using variable `env.projectSharingId`.

opw-4509372

[1]: https://github.com/odoo/odoo/pull/189568

Before
![before](https://github.com/user-attachments/assets/1ad66b75-bad6-4fc2-b6e2-a7840acb60ee)

After
![after](https://github.com/user-attachments/assets/0d0e4166-a977-4e48-a8e6-0a5bf936d364)

Forward-Port-Of: odoo/odoo#203308

Steps: - Compute no_validated_overtime_hours for many records Actual result: - Singleton expected Expected result: - Compute is done for all records Forward-Port-Of: odoo/odoo#201544

Steps:
- Compute no_validated_overtime_hours for many records

Actual result:
- Singleton expected

Expected result:
- Compute is done for all records

Forward-Port-Of: odoo/odoo#201544

When a user changes the theme colors and applies a dark background the attribute filters will not be apparent Also the color applied to text is not applied to the attributes only if the accordion is active As a fix now the accordion headers will match the updated text color from the theme opw-4559710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202691

When a user changes the theme colors and applies a dark background the attribute filters will not be apparent

Also the color applied to text is not applied to the attributes only if the accordion is active

As a fix now the accordion headers will match the updated text color from the theme

opw-4559710

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

Forward-Port-Of: odoo/odoo#202691

Steps to reproduce: ------------------- 1. Enable "basic receipt" from pos configs 2. Make an order and on the ticket screen, click "Print basic receipt" -> The price info are shown on the printed receipt, even though it shouldn't be the case since a basic ticket is meant for gifts for instance. Reason and fix: --------------- Commit b83b13030d8fbc1ca51731c13d88b194d93945ac showed some prices infor without taking into consideration the prop `basic_receipt`, which was fixed by this com

Steps to reproduce:
-------------------
1. Enable "basic receipt" from pos configs
2. Make an order and on the ticket screen, click "Print basic receipt"

-> The price info are shown on the printed receipt, even though it shouldn't be the case since a basic ticket is meant for gifts for instance.

Reason and fix:
---------------
Commit b83b13030d8fbc1ca51731c13d88b194d93945ac showed some prices infor without taking into consideration the prop `basic_receipt`, which was fixed by this commit.

opw-4652730

Forward-Port-Of: odoo/odoo#203085

Steps to reproduce: ------------------- - Switch to a Mexican company (or any company with cash basis option enabled). - Go to analytic plans and set at least one plan to mandatory. - Create a vendor bill, with a line having a vat (16% for example), and confirm the bill. - Click on credit note, try to confirm the credit note, it will show error. Cause ----- The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the

Steps to reproduce:
-------------------
- Switch to a Mexican company (or any company with cash basis option enabled).
- Go to analytic plans and set at least one plan to mandatory.
- Create a vendor bill, with a line having a vat (16% for example), and confirm the bill.
- Click on credit note, try to confirm the credit note, it will show error.

Cause
-----
The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the default display type (product). And this affects the function that applies the mandatory analytic plans, as it filters out lines that have display_type != product.

Fix
---
Add lines to copy the display_type for the move lines of the cash basis.

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

Forward-Port-Of: odoo/odoo#200389

**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD) 3. Create a purchase order for the product like: a. currency: USD b. price unit: 12.6 c. qty: 6 d. discount: 33.33% 4. Confirm the order 5. Receive the product 6. Create the bill 7. Open the journal items tree view The credit/debit amounts of the journal entrie

**Steps to reproduce:**
1. Create a company with IQD as its currency
1. Create a product with average costing and real_time accounting
2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD)
3. Create a purchase order for the product like:
    a. currency: USD
    b. price unit: 12.6
    c. qty: 6
    d. discount: 33.33%
4. Confirm the order
5. Receive the product
6. Create the bill
7. Open the journal items tree view

The credit/debit amounts of the journal entries for the reception and the invoice don't match. The `amount_currency` is the same, but there are additional exchange differences items.

The reception journal item balance is taken from the `stock.valuation.layer`.
In the example, `unit_cost` is in the company currency IQD:
https://github.com/odoo/odoo/blob/191d44c91a4578445d8cb59d3172042022cb5a9a/addons/stock_account/models/product.py#L177

The invoice's balance is computed with `amount_currency`, which is converted to USD with the exchange rate and rounded:
https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1570

The difference between the roundings (depending on the conversion rate) may generate exchange differences that shouldn't be there.

**Fix:**
Try to prepare the AML balance while creating it from a purchase
line- we have the unrounded `price_unit_discounted` that may be
used to find an accurate balance.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4103167)
opw-4103167

Forward-Port-Of: odoo/odoo#203386
Forward-Port-Of: odoo/odoo#190043

Steps ===== 1. Create an online payment method for POS 2. In a POS restaurant, set the self-ordering feature on "QR-Menu Ordering" 3. Add the online payment method in the settings of the kiosk 4. Set the product prices on "tax-included price" 5. Set the sales tax on "Tax included" 6. Open the kiosk and make an order => the final price to pay is tax excluded. Reason ====== When adding a product to the cart, we create for it an order line with unit_price as the price tax exluded, cau

Steps
=====
1. Create an online payment method for POS
2. In a POS restaurant, set the self-ordering feature on "QR-Menu Ordering"
3. Add the online payment method in the settings of the kiosk
4. Set the product prices on "tax-included price"
5. Set the sales tax on "Tax included"
6. Open the kiosk and make an order
=> the final price to pay is tax excluded.

Reason
======
When adding a product to the cart, we create for it an order line with
unit_price as the price tax exluded, causing bad behavior when the
product has a tax included tax.

Fix
===
Now, we use the pricelist price as the unit_price when creating the
order line.

opw-4613648
opw-4640119

Forward-Port-Of: odoo/odoo#200581

Currently, the Odoo code on the IoT Box is almost only updated when the client upgrades his db. The only way for us to provide new code to the user if he doesn't change his db version, is to release a new image (users can also update manually from the IoT Box homepage, but it nearly never happens). IoT Boxes will now checkout on every Monday, allowing us to deploy updates more regularly. Additionally, it will checkout on every boot to allow hot fixing, as clients will only have to reboot t

Currently, the Odoo code on the IoT Box is almost only updated when the client upgrades his db.

The only way for us to provide new code to the user if he doesn't change his db version, is to release a new image (users can also update manually from the IoT Box homepage, but it nearly never happens).

IoT Boxes will now checkout on every Monday, allowing us to deploy updates more regularly. Additionally, it will checkout on every boot to allow hot fixing, as clients will only have to reboot their IoT Box if we fix an issue in the middle of a week.

Task: 4306247

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

Forward-Port-Of: odoo/odoo#203465

## [FIX] resource: make sure flexible resource don't use attendances This commit makes sure the resource calendar attendance is not used for a flexible resource even if that resource has a working schedule with hours per day equals to 0 hour. ## [FIX] hr: recompute is_flexible when working schedule becomes flexible Before this commit, when the user sets a working schedule to an employee and convert that working schedule into a flexible working schedule, the employee is not considere

## [FIX] resource: make sure flexible resource don't use attendances

This commit makes sure the resource calendar attendance is not used for
a flexible resource even if that resource has a working schedule
with hours per day equals to 0 hour.

## [FIX] hr: recompute is_flexible when working schedule becomes flexible

Before this commit, when the user sets a working schedule to an employee
and convert that working schedule into a flexible working schedule, the
employee is not considered as working with flexible hours.

This commit makes sure the `_compute_is_flexible` method defined in
`hr.employee` model is triggered when the `flexible_hours` field of the
working schedule linked to the employee is altered.

Steps to reproduce the issue:
-----------------------------

0. Install Attendance app (`hr_attendance` module).
1. Set a working schedule A to employee E
2. Go to the form view of the working schedule A and check `Flexible
   Hours` field to convert the working schedule as flexible working
   schedule.
3. Go to Attendance app

Expected Behavior:
-----------------

The Attendance app should loaded without any issue.

Current Behavior:
----------------

A traceback is occurred saying we have a division by zero.

opw-4492625

Forward-Port-Of: odoo/odoo#203358
Forward-Port-Of: odoo/odoo#203253

Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203088 Forward-Port-Of: odoo/odoo#202875

Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users.

Now, the error will be shown on the ui only if we are in debug mode

TASK-ID: 4600145



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

Forward-Port-Of: odoo/odoo#203088
Forward-Port-Of: odoo/odoo#202875

**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200546 Forward-Port-Of: odoo/odoo#184035

**Current behavior before PR:**

When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted.

**Desired behavior after PR is merged:**

Text color can now be applied without removing or affecting the existing gradient color.

task: 4196424

Forward-Port-Of: odoo/odoo#200546
Forward-Port-Of: odoo/odoo#184035

Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to reproduce ----- - Install Sales, Inventory, Purchase and German localization - Switch to a German company - Create a product - Create a Sale Order for the product & confirm it - Validate the linked Delivery - Go back to the SO & create a (draft) Invoice - Set a delivery date & confirm the

Issue
-----
For a German company, when confirming an invoice for an order the
delivery date (of the invoice) gets set to the invoice date, even when one was
manually provided beforehand.

Steps to reproduce
-----
- Install Sales, Inventory, Purchase and German localization
- Switch to a German company
- Create a product
- Create a Sale Order for the product & confirm it
- Validate the linked Delivery
- Go back to the SO & create a (draft) Invoice
- Set a delivery date & confirm the Invoice

-> The delivery date changed to the invoice date

Cause
-----
When posting, we set the invoice date if no value was provided. This triggers
compute_delivery_date because it is overridden in the German localization to
depend on the invoice_date field. The override is present because delivery_date
is a legal requirement for the German localization.

However, forcing a value for invoice_date is also handled in the _post override
of the localization. We can thus change the compute into an onchange method (to
keep suggesting a value to the user).

This creates a problem of there being no value for delivery_date if invoice_date
is also False. This is because _post sets delivery_date = invoice_date before
calling the logic that forces a value for invoice_date. We should thus provide a
fallback value.

-----
Ticket:
opw-4599301

Forward-Port-Of: odoo/odoo#203373
Forward-Port-Of: odoo/odoo#201731

### Steps to reproduce: - Create a storable product tracked by serial number available from the pos and with a set pos category. - Open a pos session and click on your product. > A dialog openns for you to register serial numbers. - Edit a first SN: SN001 and press enter > A new line can now be set to create a second one. - Edit a second SN: SN002 and press enter - Confirm the dialog #### > The quantity displayed on teh POS order line is 1 rather than 2. ### Cause of the issue: C

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#202589
Forward-Port-Of: odoo/odoo#199127

**Steps to reproduce:** - Use version 2.12.1 of PyPDF2 as required if python version > 3.10 - Install Accounting - Upload an encrypted PDF as a bill - Go to the bills list view - Select the uploaded bill - Print "Original Bills" **Issue:** A traceback is raised: "PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm" **Cause:** When printing the original bill, we try to add a banner on the PDF. If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt

**Steps to reproduce:**
- Use version 2.12.1 of PyPDF2 as required if python version > 3.10
- Install Accounting
- Upload an encrypted PDF as a bill
- Go to the bills list view
- Select the uploaded bill
- Print "Original Bills"

**Issue:**
A traceback is raised:
"PyPDF2.errors.DependencyError: PyCryptodome is required for AES algorithm"

**Cause:**
When printing the original bill, we try to add a banner on the PDF.
If the PDF is encrypted, PyPDF2 (2.12.1) will only try to decrypt it if "PyCryptodome" library is installed.
Otherwise, it will raise a "DependencyError", which is not handled in the "except" clause.
As "PyCryptodome" library is not part of Odoo requirements, we should handle the raised "DependencyError".

**Solution:**
Try to import "DependencyError" from "PyPDF2.errors" and catch that exception when adding the banner to the PDF.
Our own "DependencyError" exception should be created because version 1.26.0 of PyPDF2 doesn't declare "DependencyError" and therefore the import will fail.
"NotImplementedError" is used instead in version 1.26.0 and is already handled.

opw-4634417




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

Forward-Port-Of: odoo/odoo#203319
Forward-Port-Of: odoo/odoo#202129

Remove empty core file. The file was introduced by mistake in another forwardport Forward-Port-Of: odoo/odoo#202520

Remove empty core file.

The file was introduced by mistake in another forwardport

Forward-Port-Of: odoo/odoo#202520

Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270

Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys.

This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]:

> Either the result member or error member MUST be included [...]

[jsonrpc-response]: https://www.jsonrpc.org/specification#response_object

Forward-Port-Of: odoo/odoo#203270

Query counter values are higher if only survey app is installed. Based on the SQL query, it looks like with only survey there is extra query to load the default language rb-111093 rb-111094 rb-111095 Forward-Port-Of: odoo/odoo#202526

Query counter values are higher if only survey app is installed.
Based on the SQL query, it looks like with only survey there is extra query to load the default language

rb-111093
rb-111094
rb-111095

Forward-Port-Of: odoo/odoo#202526

Forward-Port-Of: odoo/enterprise#72380

Forward-Port-Of: odoo/enterprise#72380

### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_va

### Steps to reproduce:
- Accounting > Dashboard > Bank > Import Statement
- Select a QIF file with a transaction having a total of 0
- Traceback

### Cause:
The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_vals['unique_import_id']` so an error is raised.

### Solution:
The read is done to store the skipped lines in `ignored_statement_lines_import_ids`. This variable is then only used to get the number of skipped lines. https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L291 The fix is to increment a counter instead of storing the lines.

opw-4656142

Forward-Port-Of: odoo/enterprise#81944

eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer. opw-4411615 Forward-Port-Of: odoo/enterprise#81887 Forward-Port-Of: odoo/enterprise#80490

eLearning uses server date when processing dashboard values, which causes a mismatch from the perspective of the user. This commit changes the source of "today" to use the user's timezone on the dashboard and actions, while keeping compute functions on the server date as these values should not change based on the timezone of the observer.

opw-4411615

Forward-Port-Of: odoo/enterprise#81887
Forward-Port-Of: odoo/enterprise#80490

…nning gantt Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability. This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves intervals. To replicate: 1. set timeoffs to a flexible res

…nning gantt

Prior to this commit, flexible resources did not have their leaves reflected as gray cells in the planning gantt view. This was due to the work_intervals being ignored for the calculation of flexible resources availability.

This commit adds measures to handle the leaves for flexible resources by setting a dummy attendance (which covers the whole length of the period in gantt interval), and then injects their leaves intervals.

To replicate:
1. set timeoffs to a flexible resource (whole day and half day)
2. open planning app
3. in the gantt view, the day in which the timeoff was set for a whole day should be fully grayed (in the default month granularity view)
4. when selecting only a day as the granularity of the gantt view, the day in which the timeoff was set for a half day should be half grayed. (from 00:00-12:00 in case of a morning timeoff, and from 12:00-24:00 in case of an afternoon timeoff)

ticket-id: 4492625
community: [198032](https://github.com/odoo/odoo/pull/198032)

Forward-Port-Of: odoo/enterprise#81899
Forward-Port-Of: odoo/enterprise#79532

Forward-Port-Of: odoo/enterprise#82212 Forward-Port-Of: odoo/enterprise#81465

Forward-Port-Of: odoo/enterprise#82212
Forward-Port-Of: odoo/enterprise#81465

During this commit: https://github.com/odoo/enterprise/commit/eae026d97399e0cf77c4d55fa1975968a27a3d2d We adapted the report to IMB. But by doing so there was some mistake in the report. opw-4625920 Forward-Port-Of: odoo/enterprise#81313

During this commit: https://github.com/odoo/enterprise/commit/eae026d97399e0cf77c4d55fa1975968a27a3d2d We adapted the report to IMB. But by doing so there was some mistake in the report.

opw-4625920

Forward-Port-Of: odoo/enterprise#81313

How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-446

How to reproduce the issue:

- Create an analytic distribution model.

- In the bank reconciliation, create a new transaction. In manual operations, remove the analytic.

If you reload the reconciliation, the analytic distribution is not deleted.

In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line.

opw-4460079

Forward-Port-Of: odoo/enterprise#81504
Forward-Port-Of: odoo/enterprise#78732

In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribut

In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`).

Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting.

In the view, they will not be used (any of those 4 chars will simply be considered a whitespace).
One could add `style="white-space: pre-line"` as an attribute to the span tag of those element, but this is not necessary. This PR simply aims to patch the already existing data in databases.

opw-4480250

Forward-Port-Of: odoo/enterprise#78684

Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases. opw-4569580 Forward-Port-Of: odoo/enterprise#82101

Accessing the tax report from a branch company raised a user error due to attempting to fetch tax group XML IDs using the company’s CID. While this could be resolved by using `self.env["account.chart.template"].ref`, the report isn’t intended to be shown for branch companies. Instead, a constraint was added to prevent access in such cases.

opw-4569580

Forward-Port-Of: odoo/enterprise#82101

The test requires `stock_dropshipping` to be installed to have sense, but the condition set to avoid the test running without it was insufficient. Since it was only checking on a string in the database, it wouldn't raise a ValueError, but just not find any matching record, thus running the test even without the module installed. Forward-Port-Of: odoo/enterprise#81981

The test requires `stock_dropshipping` to be installed to have sense, but the condition set to avoid the test running without it was insufficient.
Since it was only checking on a string in the database, it wouldn't raise a ValueError, but just not find any matching record, thus running the test even without the module installed.

Forward-Port-Of: odoo/enterprise#81981

Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used. taskid: 4607315 Forward-Port-Of: odoo/enterprise#82116 Forward-Port-Of: odoo/enterprise#80388

Before this commit, it was possible to pay payment links linked to renewed orders. It would cause issues as the renewed order would be reopened once the transaction was set to done. Two subscription in progress would live side by side. This commit ensure that such links can't be created and existing links can't be used.

taskid: 4607315

Forward-Port-Of: odoo/enterprise#82116
Forward-Port-Of: odoo/enterprise#80388

Issue: ------ When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets. Here : https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224 Solution: ----------- Passing an empty dictionay '{}' if it gets empty quotes as `b''` during pr

Issue:
------
When migrating a database having 'Documents' module installed and also having empty/blank spreadsheets created in version saas-17.2 or lower will lead to a JSON decoder error. This happens when the 'spreadsheet_data' value become an empty `b''` because of empty spreadsheets.
Here :
https://github.com/odoo/enterprise/blob/17.0/spreadsheet_edition/models/spreadsheet_mixin.py#L224

Solution:
-----------
Passing an empty dictionay '{}' if it gets empty quotes as `b''` during processing.

Steps to reproduce:
------------------------
1. Create a database in version 17.2 or lower and install Documents module.
2. Create empty/blank spreadsheets (we can manually upload an empty spreadsheet).
3. Migrate the database to version saas~17.4 or above.
4. Finally, during testcases one of the test case will fail. Because of empty quotes.

Traceback:
```
   File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 44, in _compute_current_revision_uuid
    snapshot = spreadsheet._get_spreadsheet_snapshot()
   File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 234, in _get_spreadsheet_snapshot
    return json.loads(self.spreadsheet_data)
   File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
    return _default_decoder.decode(s)
   File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
   File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
 json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```

UPG - 2263261
TBG - 1416

Forward-Port-Of: odoo/enterprise#76211
Forward-Port-Of: odoo/enterprise#74685

Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is d

Issue
=====
When validating an uncompleted return in Barcode, an error is raised.

How to reproduce
================
- Open Barcode app > Operations > Receipts and create a new receipt;
- Scan at least two times the same product's barcode;
- Validate.
- Re-open the same receipt and click on "Return Products";
- Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised.

Cause of the issue
==================
The return's move is done but `_split` is called and calling this method on a done move is forbidden.

How to fix
==========
In the `split_uncompleted_moves` move's method, done and cancel move are skipped.
Also, the JS method who call `post_barcode_process` will now doesn't call it if operation is done or cancelled or if there is no moves (to avoid to do useless RPC.)

[OPW-4535205](https://www.odoo.com/odoo/project/49/tasks/4535205)
[OPW-4535257](https://www.odoo.com/odoo/project/49/tasks/4535257)

Forward-Port-Of: odoo/enterprise#81829
Forward-Port-Of: odoo/enterprise#81312

This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue. opw-4492625 Forward-Port-Of: odoo/enterprise#82125 Forward-Port-Of: odoo/enterprise#82068

This commit adds a test to make sure the progress bar of employee fetched in gantt view of attendance returns the expected values without any issue.

opw-4492625

Forward-Port-Of: odoo/enterprise#82125
Forward-Port-Of: odoo/enterprise#82068

Reproducing the issue in the database currently requires a real digital DIAN certificate. However, it can be tested in Python: - Create a credit note for a CO company with a foreign currency. - Generate the XML report. The tags SourceCurrencyBaseRate and CalculationRate are being added with a negative sign, but the DIAN only accepts positive values. This commit replace the locally computed rate with the account_move invoice_currency_rate (which meant correcting a few already existing t

Reproducing the issue in the database currently requires a real digital DIAN certificate. However, it can be tested in Python:

- Create a credit note for a CO company with a foreign currency.
- Generate the XML report.

The tags SourceCurrencyBaseRate and CalculationRate are being added with a negative sign, but the DIAN only accepts positive values.

This commit replace the locally computed rate with the account_move invoice_currency_rate (which meant correcting a few already existing test because of decimal accuracy differences)

opw-4608444

Forward-Port-Of: odoo/enterprise#80850

### Steps to reproduce: - Install "l10n_mx_edi" and switch to Mexican company - In Accounting > Configuration > Taxes create a new tax with "Factor Type" set to "Cuota" - Create an invoice with this tax - Click "Send", select "CFDI" and send - Traceback ### Cause: Apparently a typo: The code tries to read `grouping_key['importe']` but `importe` is in the dictionary `tax_value` not `grouping_key`. ### Solution: Change `grouping_key` to `tax_value`. opw-4594061 Forward-Port-Of: o

### Steps to reproduce:
- Install "l10n_mx_edi" and switch to Mexican company
- In Accounting > Configuration > Taxes create a new tax with "Factor Type" set to "Cuota"
- Create an invoice with this tax
- Click "Send", select "CFDI" and send
- Traceback

### Cause:
Apparently a typo:
The code tries to read `grouping_key['importe']` but `importe` is in the dictionary `tax_value` not `grouping_key`.

### Solution:
Change `grouping_key` to `tax_value`.

opw-4594061

Forward-Port-Of: odoo/enterprise#81328

The field `res.company.hr_recruitment_monster_password` has the same label `Password` as the field `res.company.l10n_co_edi_password` from module [`l10n_co_edi`](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/l10n_co_edi/models/res_company.py#L15), as well as the related field on `res.config.settings` model, which generates warnings. The label on the field can be changed and the [view](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fb

The field `res.company.hr_recruitment_monster_password` has the same label `Password` as the field
`res.company.l10n_co_edi_password` from module [`l10n_co_edi`](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/l10n_co_edi/models/res_company.py#L15), as well as the related field on `res.config.settings` model, which generates warnings. 
The label on the field can be changed and the [view](https://github.com/odoo/enterprise/blob/b2fcd4e679fd6e4dedebdc13a5de0c89fbe3ef9a/hr_recruitment_integration_monster/views/res_config_settings.xml#L16-L21) where it is used will not be affected since the label is set in the view.

Forward-Port-Of: odoo/enterprise#81175

This commit is meant to fix a test in appointment failing randomly. The issue likely came from the fact that records were altered several times on the same model within the same test, with the gantt view being destroyed and re-created each time. To avoid this issue altogether, the test has been split for each case. Forward-Port-Of: odoo/enterprise#81735

This commit is meant to fix a test in appointment failing randomly. The issue likely came from the fact that records were altered several times on the same model within the same test, with the gantt view being destroyed and re-created each time.

To avoid this issue altogether, the test has been split for each case.

Forward-Port-Of: odoo/enterprise#81735

With the PR [1] added test case which is failing in no demo mode (see [2]). This commit will ensure the test case will completely run witth no demo mode. [1] https://github.com/odoo/enterprise/pull/77334 [2] https://runbot.odoo.com/runbot/build/76189941 Forward-Port-Of: odoo/enterprise#80969

With the PR [1] added test case which is failing in no demo mode (see [2]).

This commit will ensure the test case will completely run witth no demo mode.

[1] https://github.com/odoo/enterprise/pull/77334
[2] https://runbot.odoo.com/runbot/build/76189941

Forward-Port-Of: odoo/enterprise#80969

Steps to reproduce: === - Install point_of_sale. - pos_online_payment is auto-installed. - Uninstall pos_online_payment. - Install pos_urban_piper. - Installation fails with an XPath error. Issue: === - XPath targeting is_online_payment is not found when pos_online_payment is uninstalled. Fix: === - Replaced XPath from is_online_payment to split_transactions to ensure proper installation. task-4639074 Forward-Port-Of: odoo/enterprise#80944

Steps to reproduce:
===
- Install point_of_sale.
- pos_online_payment is auto-installed.
- Uninstall pos_online_payment.
- Install pos_urban_piper.
- Installation fails with an XPath error.

Issue:
===
- XPath targeting is_online_payment is not found when pos_online_payment is uninstalled.

Fix:
===
- Replaced XPath from is_online_payment to split_transactions to ensure proper installation.

task-4639074

Forward-Port-Of: odoo/enterprise#80944

Following this commit : - Initially for image_1920 in the product form view `options` was passed as `convert_to_webp': True`. - Since whenever the image is been uploaded irrespective of any format (.jpeg, .png) it will be converted to .webp which is not supported by Urban Piper. - So for pos_urban_piper this option is been modified and made False. task-4658346 Forward-Port-Of: odoo/enterprise#82044

Following this commit :
- Initially for image_1920 in the product form view `options` was passed as `convert_to_webp': True`.
- Since whenever the image is been uploaded irrespective of any format (.jpeg, .png) it will be converted to .webp which is not supported by Urban Piper.
- So for pos_urban_piper this option is been modified and made False.

task-4658346

Forward-Port-Of: odoo/enterprise#82044