Wednesday, July 17, 2024
9 changes · 17.0
Enhancements to existing features
Point of Sale now loads the company’s fiscal country information in the client, enabling country-specific sales behavior where needed. The refund process was also made easier to extend, supporting smoother localization and customization of refund workflows.
Original PR description
[IMP] point_of_sale: load company fiscal_country in the client The `account_fiscal_country_id` is required in the client to trigger l10n_* specific behaviour. task-3801234 [IMP] point_of_sale: add hook in onDoRefund Allows to add extra behaviour when clicking on the "Refund" button (when refunding a previous order). task-3801234 https://github.com/odoo/enterprise/pull/64761
Resolved issues and error corrections
Point of Sale sessions no longer fail when a product category has an archived parent category. This prevents an unexpected startup error and helps stores continue using PoS without needing to manually reactivate old category records.
Original PR description
Before this commit, attempting to open a PoS session with a product category whose parent category was archived would result in an error. opw-4050863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includ
Original PR description
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'.…
Current behavior: In hr_expenses, list and kanban views have different buttons being shown: list view displays 'New', 'Scan' and 'Create Report', while kanban view displays only 'New' and 'Upload'. In mobile, list view shows only 'New', and kanban shows 'Scan' and 'New'. Expected behavior: 'Create Report' button should be displayed in both list and kanban view, in mobile or desktop. In mobile list view, 'Scan' should also be displayed. Cause of the issue: The static view for list includes only button 'Scan' with display utility classes that hide the button in mobile. Similarly for 'Create Report' button in list. In Kanban, the button 'Create Report' has not been added. Fix: In the list view, 'Upload' button was added for desktop view, and the classes of the 'Scan' button were changed to display it in mobile view. The display utility classes for 'Create Report' were removed, so the button is displayed in mobile. In kanban view, button 'Create Report' was added. The main div of web.KanbanView.Buttons is replaced to ensure that the mobile view buttons are also displayed correctly. Without replacing it, the buttons 'New' and 'Scan' do not match the height of 'Create Report'. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169396
This fix resolves intermittent test failures in the Report Editor that occurred about 8% of the time. The issue was caused by report editing being triggered before the editor was fully loaded. By improving how the system identifies when the editor is ready, these unreliable test failures are now eliminated, ensuring more consistent and reliable testing.
Original PR description
Before this commit, in about 8% of the time for some test tours, some edition of the report was triggered before the OdooEditor had a chance to start, so the concerned step failed. After this commit, there is no such race condition, as we add OdooEditor's specific class to the step selectors. runbot-error-29949 (and all linked error)
To recreate the bug: 1- Create a loyalty program with a reward of $ per point and a fixed required amount. 2- Test the loyalty program and observe the rewards and points consumed. 3- We see that whenever we have an amount of points exceeding the required amount, they get consumed entirely, and the reward is calculated as total points * ($ per point). The problem here is that when using a loyalty reward with points, it is possible to give partial rewards. This commit prevents partial rewar
Original PR description
To recreate the bug: 1- Create a loyalty program with a reward of $ per point and a fixed required amount. 2- Test the loyalty program and observe the rewards and points consumed. 3- We see that whenever we have an amount of points exceeding the required amount, they get consumed entirely, and the reward is calculated as total points * ($ per point). The problem here is that when using a loyalty reward with points, it is possible to give partial rewards. This commit prevents partial rewards. Example: - Rule: Grant 1 point per product bought; - Reward: 1.5$ per point in exchange of 2 points (3$) Before this commit, if you buy 3 products, you get 4.5$ by using 3 points. After, you only use 2 points and get 3$ (no partial reward). opw-3922835 Forward-Port-Of: odoo/odoo#170129
Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR
Original PR description
Description of the issue/feature this PR addresses: Translations added with https://github.com/odoo/odoo/commit/e76453bf869f0a5bc2edfe861d3628b6695a205b contains unicode \u00a0 which are rendered as \u00a0 on PDF Current behavior before PR: PDF show the unicode characters  Desired behavior after PR is merged: no more unicode characters --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172490
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. ---
Original PR description
Purchase IRPF 19% Spanish tax has 2 target models: 111 and 123. New law requires a more specific breakdown. Now, the tax for 111 is relabeled as "Retenciones IRPF 19% (Compra consejero de persona física)" to be more accurate, and the new one for model 123 is named "Retenciones IRPF 19% (Compra consejero de sociedad)". Since Odoo doesn't implement model 123 yet, that new tax includes no repartition lines. See https://github.com/OCA/l10n-spain/issues/3520 for more context. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-5767 Ticket link: https://www.odoo.com/web#model=project.task&id=3864840 opw-3864840 Forward-Port-Of: odoo/odoo#162968 Forward-Port-Of: odoo/odoo#161633
Current behavior: After settling the payment of an order, the order remains in the orders list Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Start a shop session, select an order and proceed to the payment - Go back to the orders list and see the paid order still there Note: Forward the test of https://github.com/odoo/odoo/pull/171609 opw-4019204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/
Original PR description
Current behavior: After settling the payment of an order, the order remains in the orders list Steps to reproduce: - Install "Point of Sale" and "Sales" apps - Start a shop session, select an order and proceed to the payment - Go back to the orders list and see the paid order still there Note: Forward the test of https://github.com/odoo/odoo/pull/171609 opw-4019204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173103
When configuring an outgoing SMTP server for outlook, there is a check that the username in the filter must match exactly the account to connect. This is not needed. It is perfectly acceptable, and in some cases needed, to connect with an ENTRA-ID user to send mail for a shared maibox. Example: connect with administrator@example.com to send mail for info@example.com. Description of the issue/feature this PR addresses: Impossible to send mail through Outlook for shared mail boxes/ Cur
Original PR description
When configuring an outgoing SMTP server for outlook, there is a check that the username in the filter must match exactly the account to connect. This is not needed. It is perfectly acceptable, and in some cases needed, to connect with an ENTRA-ID user to send mail for a shared maibox. Example: connect with administrator@example.com to send mail for info@example.com. Description of the issue/feature this PR addresses: Impossible to send mail through Outlook for shared mail boxes/ Current behavior before PR: Trying to configure outgoing mail server for shared mail box results in UserError exception. Desired behavior after PR is merged: A single ENTRA-ID can be used for one or multiple mail addresses, differing from the mail address of the connection account. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172231