Friday, July 19, 2024
42 changes · saas-17.1
Miscellaneous changes
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
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
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
### 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
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#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#173670
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away.
Original PR description
A VAT number in Spain is a concatenation of the country prefix ES and another code, either: NIF - Número de Identificación Fiscal for individuals. CIF - Certificado de Identificación Fiscal for registered companies. The `res_partner.vat` field in Odoo is labelled "NIF" in the UI, and supports both the full VAT code with ES prefix and the shorter one without. This fix addresses two cases where the code assumed the ES prefix was present and incorrectly trimmed the first two characters away. Reference: https://www.strongabogados.com/tax-id-spain.php Ticket [link](https://www.odoo.com/odoo/project.task/3891248) opw-3891248 Forward-Port-Of: odoo/odoo#168052
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog. This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique in
Original PR description
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one…
In the contact form view, click on "Add" in the x2many on a record that isn't a company. In the dialog, select the type "Contact" and click on the "Title" label. Before this commit, the many2one autocomplete dropdown of the title field behind the dialog (in the main form view) opens, instead of the one inside the dialog. This is because the id associated with that occurrence of the field and used as "for" attribute of the label isn't unique cross form views (we only ensured it to be unique inside a given form view). There are several ways to fix this, but to minimize the diff and to comply with stable policy, this commit temporarily removes the ids that are already in the DOM (behind the dialog), and resets them when the dialog is closed. In master, we may explore alternative solutions, like generate (globally) unique ids in the arch parser. opw 3996642 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#173689 Forward-Port-Of: odoo/odoo#173584
Backport of #171924 `git cherry-pick ccacc9031548ba95b8e65b7f1d8e23fb22aaedf8..7d43ad05b15afbbe1c9ca0668a0308cb514195e7` Conflict notes: - requirements.txt conflicted on Babel and chardet, kept as the target - 0414da47d3548270380c9d577f84fbbcd0d5967e was adapted manually since the file was moved in some version Forward-Port-Of: odoo/odoo#173788
Original PR description
Backport of #171924 `git cherry-pick ccacc9031548ba95b8e65b7f1d8e23fb22aaedf8..7d43ad05b15afbbe1c9ca0668a0308cb514195e7` Conflict notes: - requirements.txt conflicted on Babel and chardet, kept as the target - 0414da47d3548270380c9d577f84fbbcd0d5967e was adapted manually since the file was moved in some version Forward-Port-Of: odoo/odoo#173788
Steps to reproduce: - Create a kit BOM composed of 40kg of storable product X. - Set cost of X as 10$ - Sell 3 kits in POS - Select customer and create an invoice - in accounting check the the invoice lines - Odoo is calculating the COGS as 3kg instead of 120kg. (30$ instead of 120$) Bug: kit quantities not taken into consideration opw-3962665 Forward-Port-Of: odoo/odoo#171277
Original PR description
Steps to reproduce: - Create a kit BOM composed of 40kg of storable product X. - Set cost of X as 10$ - Sell 3 kits in POS - Select customer and create an invoice - in accounting check the the invoice lines - Odoo is calculating the COGS as 3kg instead of 120kg. (30$ instead of 120$) Bug: kit quantities not taken into consideration opw-3962665 Forward-Port-Of: odoo/odoo#171277
Steps to reproduce: - Go to Contact - Select Abigail Peterson - Set her as a company, don't fill the field country - In Partner assignment, set partner level, activation, level weight - Cick on go to website - Back to Resellers What happens: Error with traceback ending in "TypeError: 'bool' object is not subscriptable". This is due to the country field of a reseller not being filled in, the resellers page tries to load the list of all countries with resellers and displays either res
Original PR description
Steps to reproduce: - Go to Contact - Select Abigail Peterson - Set her as a company, don't fill the field country - In Partner assignment, set partner level, activation, level weight - Cick on go to website - Back to Resellers What happens: Error with traceback ending in "TypeError: 'bool' object is not subscriptable". This is due to the country field of a reseller not being filled in, the resellers page tries to load the list of all countries with resellers and displays either resellers of the user's country or all resellers if no match is found. If any reseller's country is not filled in there is no 'country.id' to access leading to the error above. Expected behavior: Fallback: Show all partners when user's country has no resellers (as described in the file itself by comments). opw-4042404 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173086
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new sol - give a name 'youpi' to the sol - save the sol The name of the sol will be overwritten with a default one. Expected behavior: The name of the sol should be the one the user has set. Source of the problem: The name of sol is used for some computation in some use case when the fo
Original PR description
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new…
This commit's purpose is to keep the user input when he creates an sol from the formview sol. Step to reproduce : - open project update - cilck on 'sols' stat button - click on 'new' to create a new sol - give a name 'youpi' to the sol - save the sol The name of the sol will be overwritten with a default one. Expected behavior: The name of the sol should be the one the user has set. Source of the problem: The name of sol is used for some computation in some use case when the form view of sol from the sale_project module is used. But this form view is also used in the use case where the name override is not needed. Solution: add a context key to differentiate the 2 use cases. task - 4031977 version : 17.0 - master 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#171786
Before this commit, rewards associated with archived products were still accessible, leading to errors when attempting to claim them due to the non-existence of the reward product. opw-4055792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173499
Original PR description
Before this commit, rewards associated with archived products were still accessible, leading to errors when attempting to claim them due to the non-existence of the reward product. opw-4055792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173499
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. - Click on the button, make it a link. - Choose style as custom in the sidebar - Click on the circles for text color or fill color - Colorpicker is not position correctly. Origin of the issue: ==================== See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43c
Original PR description
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. -…
Issue: ====== Half of the colorpicker isn't visible in the sidebar toolbar. Steps to reproduce the issue: ============================= - Go to mass mailing and choose any template with a button. - Click on the button, make it a link. - Choose style as custom in the sidebar - Click on the circles for text color or fill color - Colorpicker is not position correctly. Origin of the issue: ==================== See commit: https://github.com/odoo/odoo/commit/88c16966b6b2d29d464ac3b43cc4998d3f4fe0e2 Solution: ========= Fixing this issue properly would require huge changes to how the SnippetsMenu is constructed and would most likely require going back to the slow iframe with all the assets inside. That would not be a desirable outcome, especially in a stable version. With that in mind, and considering the issue doesn't exist in saas-17.1, we decided it was a prime example where a local change in the popper.js library was actually the best fix. The library is very unlikely to be updated in a stable version and the change won't reach saas-17.1. co-authored with dmo-odoo opw-3984170 Forward-Port-Of: odoo/odoo#170278
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email marketing app - In the browser dev tools, set a big network throttle - Create a new mailing - Write in the editable zone before the template selection has had a chance to appear - Click on design tab in the sidebar - Traceback Spec: ===== We should not be able to write in the edi
Original PR description
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email…
Issue: ====== We can update the content of the editable before we choose the theme which results in unexpected behaviors. Steps to reproduce the issue: ============================= - Open the email marketing app - In the browser dev tools, set a big network throttle - Create a new mailing - Write in the editable zone before the template selection has had a chance to appear - Click on design tab in the sidebar - Traceback Spec: ===== We should not be able to write in the editable zone before choosing a template. Solution: ========= We add a new option `waitForSnippets` for the `wysiwyg` to force the editable element as `contenteditable="false"` until the snippets are loaded. Once the snippets are loaded we set `contenteditable="true"` back again. Note 1: Removing the line of `this._activatecontenteditable` from `_onMouseDown` in `odooEditor` because it keeps setting the editable element as `contenteditable="true"` everytime we click. The line can be safely removed because it's a leftorver from when clicking on links would set everything to `contenteditable=false` except the link itself, then clicking somewhere else would reactivate it. (introduced here https://github.com/odoo/odoo/commit/72dd8d6e3c95f614353b1e87322a67c877c255c7) . When it was outside the condition, it was hard to guess that it was not needed anymore when we removed that `contenteditable` hack for links. Note 2: the `odoo-editor` div in website have `contenteditable=false` so dropped snippets will not be editable too. We call `activatecontenteditable` after the drop of the snippets. task-3901534 Forward-Port-Of: odoo/odoo#173642 Forward-Port-Of: odoo/odoo#168008
Purpose ======= Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step. Specification ============= After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset. This happens because the method which updates the undo/redo but
Original PR description
Purpose ======= Fix the undo button in the website snippets which is enabled after choosing a template from the theme selector. The undo button shouldn't be enabled as the first selected theme is meant to be the first history step. Specification ============= After selecting a theme in the theme selector, the history steps are reset. However the undo/redo buttons of the website snippets aren't being updated with the reset. This happens because the method which updates the undo/redo buttons is triggered on the 'historyStep' event and this event is only trigerred when adding a new step in the history, not when resetting the history. Fixing the issue by trigerring the 'historyStep' event after reseting the history so that the undo/redo buttons are correctly being updated with the reset. Task-4000990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170998
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This co
Original PR description
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures…
Description of the issue/feature this PR addresses: - Commit [1] changed `getDeepestPosition` to let it change the selection to its next block. This commit partially reverts commit [1] and ensures that it only changes blocks when the node is invisible. - Commit [2] changed the behavior of Ctrl+A when the first child of an editor was contenteditable false element, causing it to not select the first element. This behavior is incorrect, as Ctrl+A should always select all contents. This commit partially reverts commit [2] and provides an alternative solution to the original issue. - Inserting a horizontal rule was only possible on paragraph related elements. This PR makes sure horizontal rule can be inserted directly to block elements such as div. task-3850023 [1]: https://github.com/odoo/odoo/commit/ddc8587f8a712fdddaa714bee2931cb149c03a38 [2]: https://github.com/odoo/odoo/commit/530f102720458e5e1c224bf38073cd763309bf0a --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#164345
In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts. In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes. task-4016899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173686 Forward-Port-Of: odoo/odoo#173138
Original PR description
In the list view of the Chart of Accounts, the only available tags in the field Tags are the ones applicable to Accounts. In the list view of journal items, the only available tags in the field Tax Grids are the ones applicable to Taxes. task-4016899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173686 Forward-Port-Of: odoo/odoo#173138
Steps to reproduce: 1) Install and enable wire transfer. 2) Disable and enable it again. 3) Go to the payment form and see that wire transfer is not in the list of available payment methods. Reason: No default payment method codes were defined to activate with the provider. opw-4042165 Forward-Port-Of: odoo/odoo#173637
Original PR description
Steps to reproduce: 1) Install and enable wire transfer. 2) Disable and enable it again. 3) Go to the payment form and see that wire transfer is not in the list of available payment methods. Reason: No default payment method codes were defined to activate with the provider. opw-4042165 Forward-Port-Of: odoo/odoo#173637
Forward-Port-Of: odoo/odoo#173617
Original PR description
Forward-Port-Of: odoo/odoo#173617
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language
Original PR description
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language, to make sure the formula of the report expression matches the tag name (since that expression's formula is not translatable). enterprise: https://github.com/odoo/enterprise/pull/65030 Forward-Port-Of: odoo/odoo#173520 Forward-Port-Of: odoo/odoo#170041
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`) information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated. Also it avoids a warning in the JS console ("Missing widget: separator for field of type separator"). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/o
Original PR description
Since https://github.com/odoo/odoo/issues/113974, Properties fields can contain separator (virtual `<group>`)
information inside its value. But in the view list, these separator can be selected in the optional fields. It doesn't make sense because there no value associated.
Also it avoids a warning in the JS console ("Missing widget: separator
for field of type separator").
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#173362Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926 Forward-Port-Of: odoo/odoo#171033
Original PR description
Saskatchewan tax report was missing a line for `Total before Sales` opw-3955926 Forward-Port-Of: odoo/odoo#171033
Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities. As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activ
Original PR description
Introduced in 5f4add917a55f62c024a7a79c9240dc628a9f14f, we allowed filtering on 'done' activities. This induced a change in the search method of activity_user_id field, now readonly, to allow searching on done activities. As user_id is required on mail.activity, we can do as we do for the activity_date_dateline search method (date_dateline being required too on mail.activity): when using 'is not set' as a custom domain (~ '= False'), return records having no activities, and therefore no activity_user_id. A small test is added in test_mail Task-4027928 Forward-Port-Of: odoo/odoo#172082
Description of the issue/feature this PR addresses: [CLA] add corporate samadeva.md to contribute as developper Current behavior before PR: Desired behavior after PR is merged: --- v I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173597
Original PR description
Description of the issue/feature this PR addresses: [CLA] add corporate samadeva.md to contribute as developper Current behavior before PR: Desired behavior after PR is merged: --- v I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173597
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component.
Original PR description
This commit fixes an issue where the property values were not reset after creating a property, setting its value, using the pager to access another record and changing the property's type. When going back to the initial record, the old value would still be there and it could trigger a traceback depending on the type change (e.g. from string to integer). The issue is fixed by using a record observer to trigger _saveInitialPropertiesValues on record id change in the properties field component. This allows to keep coherent values inside the initialValues and to generate a new property name properly when the property's definition changes. In case of a change in the property's name, the value of the property for all other records using it will be properly reset to default. OPW-4015949 Forward-Port-Of: odoo/odoo#173505
This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with. When using the days end of month payment term with a days_next_month to 0, the calculation was wrong. Ex: With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will
Original PR description
This commit https://github.com/odoo/odoo/pull/166560/commits/fc2ee9e003f317e34dcc1d01e8e1a34acdb3b8dd fixed the due date which was wrong in some case, but one case was not dealt with. When using the days end of month payment term with a days_next_month to 0, the calculation was wrong. Ex: With the current implementation, If we do a case with 30 end of month 1 with a start date the 22/04, we will add 30 days and end up the 22/05 then we add 1 month (22/06) and fix the day at 1, so we will end up the 01/06. With a days_next_month to 0, the problem is that the relative delta will keep the 22/06 which is not what we wanted. task: 4045689 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172609
Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events. opw-3933140 opw-3981108 Forward-Port-Of: odoo/odoo#172729
Original PR description
Before this commit, some calendar didn't show multiple days events in day and week modes. This commit enables the day slots in every calendar to show these events. opw-3933140 opw-3981108 Forward-Port-Of: odoo/odoo#172729
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553 Forward-Port-Of: odoo/enterprise#66990
Original PR description
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553 Forward-Port-Of: odoo/enterprise#66990
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520 Forward-P
Original PR description
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520 Forward-Port-Of: odoo/enterprise#66909
To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003 Forward-Port-Of: odoo/enterprise#66896
Original PR description
To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003 Forward-Port-Of: odoo/enterprise#66896
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1
Original PR description
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829 Forward-Port-Of: odoo/enterprise#65408
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#64956
Original PR description
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#64956
backport of #66166 Conflict notes: - ccfdc06546828868bfcfbe64f6f9c68914d96220 was dropped since the module does not exist in 17.0 (created in 17.3) - 2d58ab9042d823743bf9b0534d4572b88a30dc58 import adapted - 1728d1e448f90d3e32fc135de2370e054d0216f5 was dropped since the module does not exist in 17.0 (created in 17.2) Forward-Port-Of: odoo/enterprise#66974
Original PR description
backport of #66166 Conflict notes: - ccfdc06546828868bfcfbe64f6f9c68914d96220 was dropped since the module does not exist in 17.0 (created in 17.3) - 2d58ab9042d823743bf9b0534d4572b88a30dc58 import adapted - 1728d1e448f90d3e32fc135de2370e054d0216f5 was dropped since the module does not exist in 17.0 (created in 17.2) Forward-Port-Of: odoo/enterprise#66974
…bill Forward-Port-Of: odoo/enterprise#66846
Original PR description
…bill Forward-Port-Of: odoo/enterprise#66846
Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484 Forward-Port-Of: odoo/enterprise#61456
Original PR description
Problem --- When a stock picking is clicked from the barcode view, its responsible is always automatically assigned to the current user. Fix --- assign current user only if they change anything (validate, edit a line, etc) but not if they just look. opw-3878484 Forward-Port-Of: odoo/enterprise#61456
Prior to this commit, validating a picking that triggers this error message would raise a "TypeError: not enough arguments for format string" because the extra '()' caused all three %s to be considered as one argument. After this commit, everything works as expected. Additionally, I have reformulated the error messages to be clearer and better structured. OPW-3945812 Forward-Port-Of: odoo/enterprise#64372
Original PR description
Prior to this commit, validating a picking that triggers this error message would raise a "TypeError: not enough arguments for format string" because the extra '()' caused all three %s to be considered as one argument. After this commit, everything works as expected. Additionally, I have reformulated the error messages to be clearer and better structured. OPW-3945812 Forward-Port-Of: odoo/enterprise#64372
The accounting date is used as acquisition date instead of bill date. Steps: 2 flows leads to the bug: 1) - Create and confirm a bill with different accoutning and bill dates - Open a new asset form and click on "select related purchases" button - Select the bill -> The acquisition is set as the accounting date instead of the bill date 2) - Set the expense account to create an asset - Create and confirm a bill with line using the expense account - An asset should be
Original PR description
The accounting date is used as acquisition date instead of
bill date.
Steps:
2 flows leads to the bug:
1) - Create and confirm a bill with different accoutning and bill dates
- Open a new asset form and click on "select related purchases"
button
- Select the bill
-> The acquisition is set as the accounting date instead of the bill
date
2) - Set the expense account to create an asset
- Create and confirm a bill with line using the expense account
- An asset should be created, open it
-> Same as before
Cause:
In the `_compute_acquisition_date`, we use the field `date` from
`account.move.line` which is a related field to the `date` field of
`account_move`
Fix:
In the compute, we get the `invoice_date` field from the related move
of each `original_move_line_ids` then fallback to `date` if it is not
set (case of journal entries)
opw-4000259
Forward-Port-Of: odoo/enterprise#66921
Forward-Port-Of: odoo/enterprise#65769Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe
Original PR description
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe if a bug occurs, we decide to prevent the payment request if the amount is negative. In that case, we keep the draft invoice and keep the "payment_exception" flag to avoid running the subscription invoice cron again on that contract. opw-3874964 Forward-Port-Of: odoo/enterprise#64098
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language
Original PR description
To reproduce the issue: 1) Make an invoice using a tax impacting some tag 2) Add a tanslation to that tag 3) Switch the user language to the one you added a translation for 4) Open the tax report: the line the tag is linked to has a value of 0 ===> It should contain the value you added in 1) l10n_multilang makes the 'name' field of account.account.tag translatable. Because of that, it is important to always check the tags matching a report expression's formula using en_US as the language, to make sure the formula of the report expression matches the tag name (since that expression's formula is not translatable). community: https://github.com/odoo/odoo/pull/170041 Forward-Port-Of: odoo/enterprise#66829 Forward-Port-Of: odoo/enterprise#65030
Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#65609
Original PR description
Issue: -------------------- When you open a sign template you can see there are double scroll bars on the iframe Cause: ---------------------- The sign item toolbar placed on the left side is given 100% height and 1px border which is causing the iframe body to overflow Solution: ----------------------------- The 100% height given to the toolbar is changed with -webkit-fill-available task-4014519 Forward-Port-Of: odoo/enterprise#65609
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66869
Original PR description
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66869
When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries. So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue. task: 4027290 Forward-Port-Of: odoo/enterprise#66582 Forward-Port-Of: odoo/enterprise#66495
Original PR description
When you select a city from the city list (city_id field) on the res.partner the cities are filtered by country in standard. However this is complicated to use because more often than not there are many cities with the same name. This is specially frequent in large countries.
So simply changing it to domain="[('state_id', '=', state_id)]" solves the issue.
task: 4027290
Forward-Port-Of: odoo/enterprise#66582
Forward-Port-Of: odoo/enterprise#66495