When you duplicate a payment provider, a new payment method line is generated. However, in some configurations, people specifies custom outstanding accounts on payment method lines. When duplicating the payment provider, the outstanding account is not copied and then, at the end of the payment flow, the payment raises an error because an outstanding account is missing and the journal items can't be generated. task_id: 4019380 --- I confirm I have signed the CLA and read the PR guidelines

When you duplicate a payment provider, a new payment method line is generated. However, in some configurations, people specifies custom outstanding accounts on payment method lines. When duplicating the payment provider, the outstanding account is not copied and then, at the end of the payment flow, the payment raises an error because an outstanding account is missing and the journal items can't be generated.

task_id: 4019380

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

Forward-Port-Of: odoo/odoo#172803
Forward-Port-Of: odoo/odoo#171715

Create an invoice Add on a line the tax 1.4%SE Confirm Open Tax report mod 303 Issue: Section "Total cuota devengada" is incorrect This occur because tax repartition line tax tags have been inverted - Invoices tax lines should be tagged with +mod303[21] - Refunds tax lines should be tagged with -mod303[26] **edit 1** Adding also a fix for the tax 'VAT 12% (agriculture)' having a negative tag on both repartition lines opw-4060963 Forward-Port-Of: odoo/odoo#173801

Create an invoice
Add on a line the tax 1.4%SE
Confirm
Open Tax report mod 303
Issue: Section "Total cuota devengada" is incorrect

This occur because tax repartition line tax tags have been inverted
- Invoices tax lines should be tagged with +mod303[21]
- Refunds tax lines should be tagged with -mod303[26]

**edit 1**
Adding also a fix for the tax 'VAT 12% (agriculture)' having a negative tag on both repartition lines

opw-4060963

Forward-Port-Of: odoo/odoo#173801

tldr: The init function should not be used in this case for creating records. Doing so results in errors. The content of this init function can be safely moved to the post-init hook The problem: In saas~17.2, creating a company with a country can result in the installation of its accompanying localisation. If it is a European country, this will trigger the installation of base_vat too. If project_timesheet_holdiays is installed this can result in the installation of base_vat failing. The

tldr: The init function should not be used in this case for creating records. Doing so results in errors. The content of this init function can be safely moved to the post-init hook

The problem:
In saas~17.2, creating a company with a country can result in the installation of its accompanying localisation. If it is a European country, this will trigger the installation of base_vat too. If project_timesheet_holdiays is installed this can result in the installation of base_vat failing.

The init method described on res_company in project_timesheet_holidays is triggered when the res_partner model is extended, for instance, in base_vat when adding fields. The registry will contain these fields, but the accompanying fields will not yet have been written to the db.

When the project and task are created, a chain of dependencies result in the company's partner being read. In turn, a query is issued using fields from the registry that aren't yet written to the DB, resulting in an SQL error.

Solution:
Move the content of this method to the post-init hook. This is safe to do and works the same way.

task-id: 4060907

Forward-Port-Of: odoo/odoo#173719

### Issue: The reference displayed when entering a non valid VAT number for Israel is incorrect. And the check used is not the right one. ### Steps to reproduce: - In app Contact, create a new one - Select Israel as country and enter a non-valid VAT number - The default ref is displayed: 'CC##' (CC=Country Code, ##=VAT Number) - And the number 039225313 should be accepted ### Cause: he check used by the library stdnum is not up-to-date. There is a PR to modify the library stdnum: ht

### Issue:
The reference displayed when entering a non valid VAT number for Israel is incorrect. And the check used is not the right one.

### Steps to reproduce:
- In app Contact, create a new one
- Select Israel as country and enter a non-valid VAT number
- The default ref is displayed: 'CC##' (CC=Country Code, ##=VAT Number)
- And the number 039225313 should be accepted

### Cause:
he check used by the library stdnum is not up-to-date.
There is a PR to modify the library stdnum: https://github.com/arthurdejong/python-stdnum/ PR436 as the law has changed. Before only corporations could have a VAT number, now individuals can also have one.

### Solution:
Use the right check (tdnum.il.idnr), which is available in the library stdnum.

opw-3954674

Forward-Port-Of: odoo/odoo#173767
Forward-Port-Of: odoo/odoo#172760

This solves 2 issues. The first is that the flat discount due to negative lines should be divided by the quantity. It's like a discount to the price unit. The second issue is that we rounded by mistake the price unit. So an invoice with a product that had more than 2 decimals would be wrong. opw-4039333 opw-4052821 and others --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173489

This solves 2 issues.
The first is that the flat discount due to negative lines should be divided by the quantity. 
It's like a discount to the price unit.

The second issue is that we rounded by mistake the price unit. 
So an invoice with a product that had more than 2 decimals would be wrong.

opw-4039333
opw-4052821
and others



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

Forward-Port-Of: odoo/odoo#173489

This PR is created in order to sing the odoo CLA and contribute to Odoo. needed for --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173717

This PR is created in order to sing the odoo CLA and contribute to Odoo.

needed for 

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

Forward-Port-Of: odoo/odoo#173717

Description of the issue/feature this PR addresses: Add new contributor Rosen Vladimirov cla-file 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#173805

Description of the issue/feature this PR addresses: Add new contributor Rosen Vladimirov cla-file

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#173805

The `account` module adds the `tax_string` field to product forms: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/views/product_view.xml#L76 That field calls `Model(account.tax).compute_all()`: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/product.py#L71 That method needs access to `account.account.tag` records: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/acco

The `account` module adds the `tax_string` field to product forms: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/views/product_view.xml#L76

That field calls `Model(account.tax).compute_all()`: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/product.py#L71

That method needs access to `account.account.tag` records: https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/account_tax.py#L563 https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/account_tax.py#L632 https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/account_tax.py#L648 https://github.com/odoo/odoo/blob/ceb8b785fba1055deeff8d9075ccc707f2317278/addons/account/models/account_tax.py#L671

Internal users were able to read `account.tax` and `account.tax.repartition.line` records, but they couldn't read `account.account.tag` records.

So, this lead to the absurd situation where a user with permissions to read products (like stock, PoS or event users) couldn't be able to see the product form anymore whenever that product happened to have a tax with a repartition line with a tag:

https://github.com/odoo/odoo/assets/973709/1801eef5-8f1a-4883-8051-858cdd457e74



This is a regression from Odoo 14, introduced in https://github.com/odoo/odoo/pull/74138 and https://github.com/odoo/odoo/pull/73602.

I'm granting all internal users read permission over `account.account.tag`, just like the one they have for `account.tax` and `account.tax.repartition.line`. BTW that's the fix suggested by Odoo helpdesk.

@moduon MT-4390
OPW-3636032



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

Forward-Port-Of: odoo/odoo#152169
Forward-Port-Of: odoo/odoo#146787

`* = {'web', 'project', 'hr_timesheet', 'hr_holidays', 'hr_attendance', 'analytic'}` Before this Commit: The Graph view was not adaptable to the use of widgets, leading to issues with the representation of time. Specifically, hours were shown as float values in the graph view. For example, 5 hours and 30 minutes were displayed as 5.50 instead of the more intuitive hh:mm format. Although widgets like "float_time" or "timesheet_uom" were available to format these values, they were ineffe

`* = {'web', 'project', 'hr_timesheet', 'hr_holidays', 'hr_attendance', 
'analytic'}`

Before this Commit:
The Graph view was not adaptable to the use of widgets, leading to issues with
the representation of time. Specifically, hours were shown as float values in
the graph view. For example, 5 hours and 30 minutes were displayed as 5.50
instead of the more intuitive hh:mm format. Although widgets like "float_time"
or "timesheet_uom" were available to format these values, they were ineffective
in the Graph view due to the architecture parser's limitations. This caused
confusion for users trying to interpret the time accurately.

After this Commit:
The Graph view is now adaptable to the use of widgets. This means that when a
widget is applied to format a field's value, the value will be displayed in the
specified format. For example, hours can now be shown in the hh:mm format
instead of as a float. 

Widget `timesheet_uom` is used at places where the module is related/depended
on `hr_timesheet` otherwise `float_time`.

This improvement also ensures that the formatted values
are reflected in the Y-axis (Ticks/Intervals) of the Graph view, enhancing the
user's ability to interpret the data accurately.

Enterprise PR: https://github.com/odoo/enterprise/pull/66050

Task-3861721

Forward-Port-Of: odoo/odoo#173575
Forward-Port-Of: odoo/odoo#164280

Before this commit, when dragging elements with draggable hooks, the Y coordinate of the dragged element was not correctly clamped within its container. This is because its own height wasn't taken into account and it could overflow on the bottom. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173882 Forward-Port-Of: odoo/odoo#173670

Before this commit, when dragging elements with draggable hooks, the Y coordinate of the dragged element was not correctly clamped within its container.

This is because its own height wasn't taken into account and it could overflow on the bottom.

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

Forward-Port-Of: odoo/odoo#173882
Forward-Port-Of: odoo/odoo#173670

This fixes incorrect unit values in the project subscription demo data. It helps ensure sample subscription records display more accurately for testing, demos, and onboarding without affecting live customer data.