Friday, April 15, 2022
14 changes · master
New functionality added to Odoo
Customers can now rent products directly from the online store by choosing rental start and end dates, with prices calculated for the selected period. Store managers can set unavailable rental days, minimum rental durations, show availability, and support rentals from wishlist, comparison, and product configurator flows.
Original PR description
This PR adds rent management on eCommerce. Purpose ====== Being able to rent on e-commerce. Specification ========= - eCommerce users are now able to input start and end dates to rent products. The…
This PR adds rent management on eCommerce. Purpose ====== Being able to rent on e-commerce. Specification ========= - eCommerce users are now able to input start and end dates to rent products. The price of the product is computed on the basis of the start and end dates introduced by the user. - eCommerce administrator are now able to configure days where rental cannot be processed (e.g. on Saturday and Sunday) and a minimal rental duration. - eCommerce wishlist or comparison users are now able to input the rental period in their dedicated wishlist or comparison page. - eCommerce stock users are now able to see the stock availability of the product for the selected rental period. - eCommerce users can now add the rental optional products to their cart with the start and end dates of the rental period taken from their initial rental period on the basis product. Technical choices ============= - A rental product which is salable is always considered as rent-able unless no product pricing is defined for the website pricelist. - The quick add to cart button is disabled on rental products to ensure the start and end date are always given to create the rental order line. - The price computation is factorized in the sale_temporal module in order to benefit from the cart_update implementation (i.e. the calls to get_product_price on the pricelist) and avoid a workflow duplication. The only usage of the pricelist is its currency and not the rules. - The update temporal prices specific method is now useless since all the computation is now made through the `_compute_price_rule` method. - The rental templates are not updatable through the editor since the input name and place are important. task-2382027 See https://github.com/odoo/odoo/pull/83359
Enhancements to existing features
Mobile users can now start VoIP calls more directly from activity records. This makes follow-up work faster and smoother for teams using Odoo VoIP on phones.
Original PR description
Task-2579306
Miscellaneous changes
Since 15.2 bank accounts are no longer required to be unique per company Two partner could share a same bank number. Thus, this constraint on SDD is no longer relevant and can cause issues by blocking the process of payment via sepa for a customer if another partner is already using the bank account. opw-2814124 Forward-Port-Of: odoo/enterprise#26261
Original PR description
Since 15.2 bank accounts are no longer required to be unique per company Two partner could share a same bank number. Thus, this constraint on SDD is no longer relevant and can cause issues by blocking the process of payment via sepa for a customer if another partner is already using the bank account. opw-2814124 Forward-Port-Of: odoo/enterprise#26261
This update adds automated test coverage to ensure sales orders correctly create project tasks for field service products with worksheet templates. It helps reduce the risk of sales-to-service workflow issues reaching customers.
Original PR description
The purpose of the task is to add new tests and tour in project This commit will add new test for project-task creation when confirming an SO - Check service based product with fsm project and worksheet template task-2723662
VoIP internal logic was reorganized so activity-related behavior is handled in the underlying models rather than screen components. This makes the feature easier to maintain and reduces the risk of future changes causing problems, without introducing a major visible change for users.
Original PR description
This commit moves some handler methods from components to models, as a step closer to having most of business code in models. Having business code in models is desirable so that the code is much more maintainable: easier to change and more robust code. Task-2579306
This update adjusts internal automated tests for enterprise mail and website helpdesk live chat to better match how chat participants are represented. It helps keep future changes safer by making the test environment more accurate, with no direct impact on day-to-day users.
Original PR description
…ck server Task-2810539 Community: https://github.com/odoo/odoo/pull/87587
Mass mailing templates can now automatically show current or future dates, such as updating the copyright year in email footers. This reduces manual template maintenance and helps keep outgoing communications accurate over time.
Original PR description
Purpose ======= Dynamically change dates in templates (such as copyright year at the footer) to current year/a date in the future. Task-2792084
Current behavior before PR: The display_name field value should be dynamically print in the digest email. While sending the digest emails, The display_name value is not showing. Desired behavior after PR is merged: With this, We set the html_sanitize after rendering the QWEB template. So, all the conditions and aliases are showing correctly. Replacing jinja with qweb template, we should use <t t-out="variable"/> to print the dynamic value so, removed the inline_template expression
Original PR description
Current behavior before PR:
The display_name field value should be dynamically print in
the digest email.
While sending the digest emails, The display_name value is not showing.
Desired behavior after PR is merged:
With this, We set the html_sanitize after rendering the QWEB template.
So, all the conditions and aliases are showing correctly. Replacing jinja with qweb template,
we should use <t t-out="variable"/> to print the dynamic value so, removed the inline_template
expression `{{` and `}}` and put the <t t-out="variable"/>.
PR #22971
Task-2704083
Forward-Port-Of: odoo/enterprise#22971Step to reproduce: - Install accounting and the l10n_multilang and account_disallowed_expenses module and add another language in the settings. - Create a disallowed expenses category if none exist in the accounting configuration - Select an account in chart of accounts and make a copy of an existing account, change de translation of this account - Set a disallowed expenses category to this account - Create a new journal entry with this new account - Go in report > disallowed expenses
Original PR description
Step to reproduce: - Install accounting and the l10n_multilang and account_disallowed_expenses module and add another language in the settings. - Create a disallowed expenses category if none exist…
Step to reproduce: - Install accounting and the l10n_multilang and account_disallowed_expenses module and add another language in the settings. - Create a disallowed expenses category if none exist in the accounting configuration - Select an account in chart of accounts and make a copy of an existing account, change de translation of this account - Set a disallowed expenses category to this account - Create a new journal entry with this new account - Go in report > disallowed expenses Current behavior: When you click on the disallowed expenses category you have no translation and instead the name with (copy) at the end. Expected behavior: You should have a the translated name of the account. Explanation: For the moment the module did not take into account the possibility that the account name was translatable (which is the case if the module l10n_multilang is installed). Hence, the name in the report was always untranslated. This is because the report does not use the classical ORM but uses raw SQL instead. This commit updates the sql query to use the translation of an account's name if it exists. This problem and fix is similar to the one of the following commit: https://github.com/odoo/enterprise/commit/76b7390d81d0642b0ac98aa1c31b52bd7b6ffef4 opw-2806289 Forward-Port-Of: odoo/enterprise#25919
In the current version, the appointment module appointment share custom URL does not support dashed strings like 'marketing-interview' . This happens due to not including `-` in re.match(). This commit fixes the issue by adding `-` in re.match(). Custom URL can now support dashes in addition to strings by including the `-` in `re.match()`. task-2818469 Forward-Port-Of: odoo/enterprise#26072
Original PR description
In the current version, the appointment module appointment share custom URL does not support dashed strings like 'marketing-interview' . This happens due to not including `-` in re.match(). This commit fixes the issue by adding `-` in re.match(). Custom URL can now support dashes in addition to strings by including the `-` in `re.match()`. task-2818469 Forward-Port-Of: odoo/enterprise#26072
Task: 2822454 After the recent changes in ```account_report```, ```no_format``` should be used instead of the ```balance``` when getting lines from the reports. Since ```balance``` is not present anymore, it was breaking the annual tax report. Forward-Port-Of: odoo/enterprise#26178
Original PR description
Task: 2822454 After the recent changes in ```account_report```, ```no_format``` should be used instead of the ```balance``` when getting lines from the reports. Since ```balance``` is not present anymore, it was breaking the annual tax report. Forward-Port-Of: odoo/enterprise#26178
This filter's style was buggy, as other filters are buttons and it wasn't. Forward-Port-Of: odoo/enterprise#26237
Original PR description
This filter's style was buggy, as other filters are buttons and it wasn't. Forward-Port-Of: odoo/enterprise#26237
Since commit [1], if for some reason we are trying to generate an XML file for a payment not linked to a valid SDD mandate, a TypeError will be raised when filling in element LclInstrm/Cd as the SDD scheme value is inherited from the mandate associated to the payment. We should fallback on the CORE scheme in that situation, so the real error behind is properly raised afterward. [1]: https://github.com/odoo/enterprise/commit/d6a6240a21457a78e49762eac5b88b84ac58f045 opw-2813673 Forward
Original PR description
Since commit [1], if for some reason we are trying to generate an XML file for a payment not linked to a valid SDD mandate, a TypeError will be raised when filling in element LclInstrm/Cd as the SDD scheme value is inherited from the mandate associated to the payment. We should fallback on the CORE scheme in that situation, so the real error behind is properly raised afterward. [1]: https://github.com/odoo/enterprise/commit/d6a6240a21457a78e49762eac5b88b84ac58f045 opw-2813673 Forward-Port-Of: odoo/enterprise#25917
Task: 2823466 Currently, both PSI and LIC declarations are exported in the XML of Partner VAT Intra report even if there is nothing to report. Customers try to upload the XML on LU portal and it is not accepted because one of the declarations is empty. Should be: If there are only goods or services invoiced, but not both of them, only one of the declarations should be exported accordingly. Forward-Port-Of: odoo/enterprise#26177
Original PR description
Task: 2823466 Currently, both PSI and LIC declarations are exported in the XML of Partner VAT Intra report even if there is nothing to report. Customers try to upload the XML on LU portal and it is not accepted because one of the declarations is empty. Should be: If there are only goods or services invoiced, but not both of them, only one of the declarations should be exported accordingly. Forward-Port-Of: odoo/enterprise#26177