Friday, July 19, 2024
42 changes · saas-17.4
Resolved issues and error corrections
Editing a message without attachments no longer creates an empty attachment record. This keeps message histories cleaner and avoids confusing users with placeholder files that were never uploaded.
Original PR description
When editing a message, even if there are no attachments, the post will create a null attachment. This is because the attachments from _message_update_content is an empty object rather than a list so that it is parsed as a record.  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures delivery location selection pages load their supporting code correctly and no longer fail because of an internal controller mistake. It helps customers complete checkout with delivery options more reliably.
Original PR description
This commit addresses those problems: - The location selector's controllers wrongly used `self`; - The controllers' folder was not imported into the `delivery` module.
This fix ensures Odoo correctly finds all IP addresses associated with a device, rather than only the most recent one. This improves accuracy for device tracking and related audit or troubleshooting activities without changing user workflows.
Original PR description
Issue: ------ The method which finds all the ip addresses linked to a device uses the `_read_group` method. This method can be called as part of the `res.device` model (which is the model that deduplicates `res.device.log` records and only keeps the most recent one for a device). As a result, we do not retrieve all ip addresses but only that of the last record. Solution: --------- Force the `res.device.log` model to perform the `_read_group`. It is also necessary to group together the "keys" that determine a given device in order to distinguish them when you want to retrieve all ip addresses linked to a device.
This fixes an issue where upgraded databases could have a disabled working hours view because payroll changes loaded in the wrong order. The view now uses the correct dependency, helping HR payroll screens continue to display reliably after upgrades.
Original PR description
Context: On an upgraded database we detected that the resource calendar inherited views where disabled, because they were not able to find parent element. The full timeline is as below: - 2021-01-01:…
Context: On an upgraded database we detected that the resource calendar inherited views where disabled, because they were not able to find parent element. The full timeline is as below: - 2021-01-01: commit odoo/enterprise@1d9fdd624497 introduced `hr_payroll.resource_calendar_view_tree` view - 2021-02-05: commit odoo/enterprise@0506d4e6fa18 introduced `hr_contract.resource_calendar_view_tree` view (with `contracts_count` field) - 2024-07-02: commit odoo/enterprise@1f03fb675922 updated `hr_payroll.resource_calendar_view_tree` view to add a field after `contracts_count` field. For databases that were update with each individual changes (at specified date), the `hr_payroll` inherited view will have a lower id than the `hr_contract` one and as such will be applied before (considering the standard view order). And following commit odoo/enterprise@1f03fb675922 this will raise a ValidationErorr: `Element '<field name="contracts_count">' cannot be located in parent view` This commit update `hr_payroll.resource_calendar_view_tree` view to inherit from the view that really add the `contracts_count` field.
This fixes an issue in Documents Spreadsheet where pivot table measures could miss their calculation method. Keeping a default calculation prevents inconsistent pivot behavior and helps users get reliable spreadsheet results.
Original PR description
Now the pivot's measures always have an aggragator, it cannot be undefined anymore. Task: 4052502
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
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
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
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#173654
Forward-Port-Of: odoo/odoo#173362In 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
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
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
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
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
Steps to reproduce: - Add a product to your cart (not a service) - Try to pay with express checkout with payment_demo - Validation Error:No shipping method is selected. After this PR the first available shipping method will be assigned to the order when payment with demo express checkout. opw-4010925 Forward-Port-Of: odoo/odoo#173297 Forward-Port-Of: odoo/odoo#171180
Original PR description
Steps to reproduce: - Add a product to your cart (not a service) - Try to pay with express checkout with payment_demo - Validation Error:No shipping method is selected. After this PR the first available shipping method will be assigned to the order when payment with demo express checkout. opw-4010925 Forward-Port-Of: odoo/odoo#173297 Forward-Port-Of: odoo/odoo#171180
The restrictions on `button_draft` method on account move were moved to a new method to allow inherit and mute the restrictions in necessary cases for some customizations. A user case is the next: Allow the deletion of cash basis or Exchange Differential entries to facilitate the accounting audit process. As the number of lines in the accounting entries generated by these transactions can grow significantly, this occurs each time a payment that has generated CABA or Exchange Differen
Original PR description
The restrictions on `button_draft` method on account move were moved to a new method to allow inherit and mute the restrictions in necessary cases for some customizations. A user case is the next:…
The restrictions on `button_draft` method on account move were moved to a new method to allow inherit and mute the restrictions in necessary cases for some customizations. A user case is the next: Allow the deletion of cash basis or Exchange Differential entries to facilitate the accounting audit process. As the number of lines in the accounting entries generated by these transactions can grow significantly, this occurs each time a payment that has generated CABA or Exchange Differential entries is canceled or unreconciled, reverse lines are generated for these entries. Setting the posted journal entries to "draft" when canceling by using the `button_cancel` method was introduced in [1], this does not allow deleting the CABA or Exchange Differential entries generated in the unreconciled and reconcile process. [1] 1de5c98 Related: #96134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172456 Forward-Port-Of: odoo/odoo#170067
Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data. This commit avoid fetching image fields with `hierarchy_read`. Forward-Port-Of: odoo/odoo#173040 Forward-Port-Of: odoo/odoo#172934
Original PR description
Before this commit, the avatar for the employees in the org chart is loaded by the URL but also when we fetched the data. This commit avoid fetching image fields with `hierarchy_read`. Forward-Port-Of: odoo/odoo#173040 Forward-Port-Of: odoo/odoo#172934
Currently, if a restaurant has so many table that some are hidden down the screen, it is impossible to scroll down to select the hidden table. Steps to reproduce: ------------------- * Open the **Poin of sale** App * Open restaurant session * Switch floor view * Edit plan * Add many tables such as some are not visible on the screen * Try scrolling > Observation: Unable to scroll Why the fix: ------------ For some reason, the ability to scroll in the floor view was removed with th
Original PR description
Currently, if a restaurant has so many table that some are hidden down the screen, it is impossible to scroll down to select the hidden table. Steps to reproduce: ------------------- * Open the **Poin of sale** App * Open restaurant session * Switch floor view * Edit plan * Add many tables such as some are not visible on the screen * Try scrolling > Observation: Unable to scroll Why the fix: ------------ For some reason, the ability to scroll in the floor view was removed with this commit https://github.com/odoo/odoo/commit/b42b0f8b541a13621b671b0b7e57812ef11fc1b2 The value changed from `overflow-auto` to `overflow-hidden` here https://github.com/odoo/odoo/blob/fb4d758ed78211a61ea797759e1fb3b02b51be60/addons/pos_restaurant/static/src/app/floor_screen/floor_screen.xml#L66 opw-4051308 Forward-Port-Of: odoo/odoo#173664
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#173242 Forward-Port-Of: odoo/odoo#172609
Forward-Port-Of: odoo/odoo#173617
Original PR description
Forward-Port-Of: odoo/odoo#173617
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
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
Saskatchewan 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
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
…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
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#66948 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#66948 Forward-Port-Of: odoo/enterprise#66869
The trust widget was missing a prop causing a client stacktrace when in debug mode. It appears in saas-17.2 due to https://github.com/odoo/enterprise/commit/47434fba1acd9b7bcc0a4eb74f6b2dc4454f0068 opw-4058127 Forward-Port-Of: odoo/enterprise#66891
Original PR description
The trust widget was missing a prop causing a client stacktrace when in debug mode. It appears in saas-17.2 due to https://github.com/odoo/enterprise/commit/47434fba1acd9b7bcc0a4eb74f6b2dc4454f0068 opw-4058127 Forward-Port-Of: odoo/enterprise#66891
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Order Lines: Product | Quantity | Unit Price | Taxes ---------------|----------------|----------------|---------- Product A | 1.00 | 1000.00 | 16% Product B | 1.00 | 1500.00 | 16% Product C | 1.00 |
Original PR description
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Order Lines:
Product | Quantity | Unit Price | Taxes
---------------|----------------|----------------|----------
Product A | 1.00 | 1000.00 | 16%
Product B | 1.00 | 1500.00 | 16%
Product C | 1.00 | 3000.00 | 16%
- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI
**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.
**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.
**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.
opw-4033979
Forward-Port-Of: odoo/enterprise#66715We send the name of an old blackbox Now we send a generic name for blackbox device "blackbox" Forward-Port-Of: odoo/enterprise#66920
Original PR description
We send the name of an old blackbox Now we send a generic name for blackbox device "blackbox" Forward-Port-Of: odoo/enterprise#66920
…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
This addresses several issues: - on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved - make this view clearer by separating the product and the other fields - 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant - fix component remaining quantity when no producing quantity has been set - generate a new pdf for barcodes: add print barcode & new ghostscript version seems t
Original PR description
This addresses several issues: - on 'register_consumed_materials' & 'register_byproducts' quality checks, the quantity entered and the selected lot were not saved - make this view clearer by separating the product and the other fields - 'print' & 'next' barcode triggers were sometimes capitalized, making them inoperant - fix component remaining quantity when no producing quantity has been set - generate a new pdf for barcodes: add print barcode & new ghostscript version seems to solve some erratic scanning problems task: 3987346 Forward-Port-Of: odoo/enterprise#66755 Forward-Port-Of: odoo/enterprise#65396
Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66691 Forward-Port-Of: odoo/enterprise#65893
Original PR description
Steps to reproduce: - Install "Field Service" - Open a random task - Click on "Navigate To" Issues: The link is constructed using the coordinates, however Google will convert those coordinates back to an address which will cause a potential discrepancy between the two. opw-4004846 Forward-Port-Of: odoo/enterprise#66691 Forward-Port-Of: odoo/enterprise#65893
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#66495Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#66531 Forward-Port-Of: odoo/enterprise#63965
Original PR description
Before this commit, when clicking on the action with the hierarchy enabled, the parent line were not unfolded which cause the purpose of the action to be useless. task-3839845 Forward-Port-Of: odoo/enterprise#66531 Forward-Port-Of: odoo/enterprise#63965
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#65769Steps to reproduce ================== - Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale - Go to invoices - Open studio ``` enterprise/web_studio/models/ir_ui_view.py:103 in _postprocess_access_rights 100 │ │ │ for node in tree.xpath('//*[@groups]'): 101 │ │ │ │ node_groups[node] = node.get('groups') ❱ 103 │ │ │ │ if not self.user_has_groups(node.get('groups')): odoo/odoo/models.py:1550 in user_has_groups ❱ 1550 │ │ │ if
Original PR description
Steps to reproduce ================== - Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale - Go to invoices - Open studio ``` enterprise/web_studio/models/ir_ui_view.py:103 in…
Steps to reproduce
==================
- Install account_accountant,l10n_fr_invoice_addr,web_studio,website_sale
- Go to invoices
- Open studio
```
enterprise/web_studio/models/ir_ui_view.py:103 in _postprocess_access_rights
100 │ │ │ for node in tree.xpath('//*[@groups]'):
101 │ │ │ │ node_groups[node] = node.get('groups')
❱ 103 │ │ │ │ if not self.user_has_groups(node.get('groups')):
odoo/odoo/models.py:1550 in user_has_groups
❱ 1550 │ │ │ if group_ext_id[0] == '!':
1551 │ │ │ │ not_has_groups.append(group_ext_id[1:])
IndexError: string index out of range
```
Cause of the issue
==================
The l10n_fr_invoice_addr sets an [empty group] attribute on a node. When opening studio, user_has_groups is called with the groups attribute value. In this case, it's an empty string and it fails.
Solution
========
Since an empty group is [allowed] by the ORM, we simply check that the value is not empty before calling user_has_groups
---
[empty group]: https://github.com/odoo/odoo/blob/00a78373f87c84dfa8ffa97ca255cf01368cd423/addons/l10n_fr_invoice_addr/models/account_move.py#L17
[allowed]: https://github.com/odoo/odoo/blob/a913272136182e6f4b1e28337686dd14616ea0ca/odoo/addons/base/tests/test_views.py#L2791
opw-4046078
Forward-Port-Of: odoo/enterprise#66914
Forward-Port-Of: odoo/enterprise#66595