Saturday, July 20, 2024
10 changes · saas-17.2
Miscellaneous changes
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
Original PR description
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
Original PR description
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
Original PR description
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…
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
Original PR description
### 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
Original PR description
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
Original PR description
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
Original PR description
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
Original PR description
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…
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
Original PR description
`* = {'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…
`* = {'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#164280Before 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
Original PR description
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