Thursday, January 30, 2025
33 changes · 18.0
Enhancements to existing features
The point of sale receipt screen now hides the Edit Payment button once a receipt has been printed when employee-based POS features are installed. This prevents staff from seeing an action that should no longer be available after completing the sale receipt flow.
Original PR description
Before this commit: =============== - The 'Edit Payment' button appears even after printing the receipt. (only when pos_hr installed) After this commit: =============== - The 'Edit Payment' button will disappear after printing the receipt. task-4507326 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update fixes a small issue in sales PDF quote building so available product documents are calculated correctly when multiple sales orders are processed together. It helps keep generated quotes consistent and avoids missing or incorrect document options in batch operations.
Original PR description
This fix addresses a minor issue with the `_compute_available_product_document_ids` method of `sale.order`, which doesn't fully support multi-compute. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The World Map view when you are on the "/partners" page doesn't zoom. This happens when any of the partners that are getting rendered doesn't have a location (longitude and latitude). Geocoder is then used to locate those addresses on the map. We use Promises, and when there is an error, we're not catching it where we are calling it from. The failed Geocode triggers the reject, which is not caught, and we're stuck in the await Promise. The zoom-in line never gets called. Steps to Rep
Original PR description
The World Map view when you are on the "/partners" page doesn't zoom. This happens when any of the partners that are getting rendered doesn't have a location (longitude and latitude). Geocoder is then used to locate those addresses on the map. We use Promises, and when there is an error, we're not catching it where we are calling it from. The failed Geocode triggers the reject, which is not caught, and we're stuck in the await Promise. The zoom-in line never gets called. Steps to Reproduce on Runbot: Integrate the Google Place Map key via Settings -> Geolocation -> Google Place Map. Go to "/partners." Toggle on the world map view for the page via the editor. Ensure one partner on the page lacks a location. Go to the "map" view, and the map will not zoom in. opw-4319619 Forward-Port-Of: odoo/odoo#189518
Fixes an issue where downloading a PDF for an unconfirmed invoice could fail with an error. Business users can now export draft invoice PDFs reliably from the invoice list, avoiding disruption during invoice preparation.
Original PR description
Steps to reproduce the error: - Create a new invoice. Don't confirm it. - Go to list view of invoices. - Select that invoice > Download > PDF Traceback: "AttributeError: 'bool' object has no attribute 'replace'" `_get_move_display_name` can be used instead as it already handles draft invoices. sentry-6191644587
This fix ensures carousel control options behave correctly when editing a website page. Business users get a more reliable preview and setup experience when choosing whether carousel arrows and indicators are hidden or centered.
Original PR description
Since [1], a method was introduced to prevent the "controllers" options from being centered when arrows and indicators are displayed. However, it was implemented in the wrong overridden method (computeWidgetState), which cannot update the DOM. Additionally, it failed to account for the preview mode. This commit resolves these issues. Steps to reproduce: - Website - Edit mode - Drag and drop a "carousel intro" snippet onto the page. - Select the option "Controllers > Arrows > Hidden." - Then select the option "Controllers > Centered." - The controllers are now displayed as centered. - Hover over the "Controllers > Arrows" options and preview a value other than "Hidden." - The preview does not update correctly. [1]: https://github.com/odoo/odoo/commit/454d743ed631c068b7b0bc72e4fd81b225a5ac52 Related to: task-4094405
The hierarchy view icon now appears in the intended tree-like orientation as soon as it is shown. This avoids a confusing visual glitch where the icon initially appeared incorrectly until users opened the hierarchy view.
Original PR description
This PR aims to fix an issue about the icon related to the hierarchy view not being rotated anymore. | 18.0 and above | This PR | |--------|--------| | <img width="529" alt="image"…
This PR aims to fix an issue about the icon related to the hierarchy view not being rotated anymore. | 18.0 and above | This PR | |--------|--------| | <img width="529" alt="image" src="https://github.com/user-attachments/assets/11289aa4-948d-4725-b8d5-e91bf5d601fc" /> | <img width="531" alt="image" src="https://github.com/user-attachments/assets/bc74ef4e-6e74-47d1-ac06-6bde1d6ed933" /> | To render the icon of the hierarchy view, we use a little trick by rotating the `fa-share-alt` icon so that it looks like a tree diagram one. Unfortunately, this does not work anymore in `18.0` and above. It seems the CSS won't be loaded until you entered the module, which leads to the icon being rendered to `fa-share-alt` by default and then rotated correctly once you click on it. To fix this issue, we actually make use of available utility classes `fa-rotate-90`to handle the icon rotation and `align-text-top` to handle the vertical alignment when the icon is rendered within a node. task-4501317 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi Arabia POS orders with a zero total, such as orders fully paid with an eWallet, no longer trigger an error during validation. This helps businesses complete legitimate sales smoothly without manual workarounds.
Original PR description
Before this commit, attempting to validate an order with a zero total (such as when fully paid using an eWallet) would result in an error. opw-4487591 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The survey editor now prevents users from adding embedded components that would not display correctly when respondents view the survey. This avoids broken or missing content in published surveys and helps creators use options that work reliably.
Original PR description
**Problem**: Embedded components do not render when the `html` field content is displayed outside the editor, as their mechanism relies on the editor plugin. **Solution**: Disable embedded components for the survey. **Steps to Reproduce**: 1. In a survey, add a section. 2. Add a "View" button. (Debug mode ON) 3. Use the `/` command box and add the "Video link" option. 4. Save and test the survey. 5. The video does not display. opw-4487027 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where users could hit an error when registering a payment for an invoice without an invoice date, especially when early payment discounts are involved. The payment flow now skips discount date calculations when the required invoice date is absent, avoiding disruption for accounting users.
Original PR description
Currently, a traceback occurs when there is no invoice date and tries to register a payment from actions. To reproduce this issue: 1) Install accounting 2) Create a customer invoice with payment term…
Currently, a traceback occurs when there is no invoice date and tries to register a payment from actions. To reproduce this issue: 1) Install accounting 2) Create a customer invoice with payment term having an early discount 3) Make sure the invoice date to be empty 4) Add a line and from actions click pay Error:- ``` TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta' ``` In account move, `invoice_date` is not required. So when the user tries to register a payment with payment term having an early discount and no invoice date, It leads to the above traceback from below line. https://github.com/odoo/odoo/blob/ee48df7f33a3aeb1798bf5852be8c6d26a7db7fd/addons/account/models/account_payment_term.py#L256-L258 Indeed, a date is required to get an early discount date. so without date, we should not execute the `_get_last_discount_date` method. In some other locations, it was managed in a similar manner as indicated in the below line. https://github.com/odoo/odoo/blob/ee48df7f33a3aeb1798bf5852be8c6d26a7db7fd/addons/account/models/account_payment_term.py#L262-L264 We can resolve this issue by adding an additional check of invoice_date, Which makes the code more robust. sentry-6149404219
A test in the Brazilian electronic invoicing area was corrected to match the current default email behavior. This helps keep automated checks reliable and reduces false failures during maintenance.
Original PR description
task-4478365
Italian point-of-sale receipts sent to fiscal printers now calculate payment totals correctly when customers receive change. This prevents change amounts from being counted as an additional payment, helping ensure fiscal documents match the actual sale.
Original PR description
The issue was that payment lines with `is_change` were also being considered in the computation.
Exemple:
Product: 14.50
Payment: 20.00
Change: 5.50This fixes an unreliable automated test in Web Studio that could fail when all apps were installed. The change makes the test steps more precise, helping reduce false failures and keeping validation of updates more stable.
Original PR description
runbot-error-108304
The reCAPTCHA feature is currently controlled by the "Module Installation" setting: `module_google_recaptcha`, which, due to dependencies, caused the removal of many other modules when disabled. The goal of this commit is to simply hide this option in stable to prevent this misleading behaviour. A user can still disable the reCAPTCHA checks by removing API keys (Which was already mentioned on the setting block) The feature behaviour will be updated in master to allow disabling reCA
Original PR description
The reCAPTCHA feature is currently controlled by the "Module Installation" setting: `module_google_recaptcha`, which, due to dependencies, caused the removal of many other modules when disabled. The goal of this commit is to simply hide this option in stable to prevent this misleading behaviour. A user can still disable the reCAPTCHA checks by removing API keys (Which was already mentioned on the setting block) The feature behaviour will be updated in master to allow disabling reCAPTCHA without uninstalling the modules. task-3380702 Forward-Port-Of: odoo/odoo#194907
The credit limit in the partner form view was missing a currency symbol, leading to ambiguity about whether the limit was in the customer's currency or the company's currency. Displayed the partner limit in the company currency to avoid confusion. task-4507336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195325 Forward-Port-Of: odoo/odoo#194807
Original PR description
The credit limit in the partner form view was missing a currency symbol, leading to ambiguity about whether the limit was in the customer's currency or the company's currency. Displayed the partner limit in the company currency to avoid confusion. task-4507336 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195325 Forward-Port-Of: odoo/odoo#194807
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in ot
Original PR description
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all…
Currently the different documents are responsible on the move's cancelation. E.g. cancel a SO will delete all the pickings with the same procurement group. Cancel a PO will cancel the receipt an all the moves destination. But in inter company transaction or inter warehouse. The source document is a stock.move directly (or a rr but it's already unlink) Some users delete the receipt from another warehouse but the delivery on the other still exists. So it let pickings that are never cancel in other companies/warehouses. This commit and an option to allow the cancel propagate upstream. It's hidden under the `stock.cancel_moves_origin` system parameter in order to avoid a huge behavior modification for other users. opw-3274939 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#195035 Forward-Port-Of: odoo/odoo#186730
Steps to reproduce the bug: - Create a storable product “P1”: - UoM: g - Go to inventory > operation > Scrap: - Create a new one: - product: P1 - UoM: KG - Quantity: 1 - Validate the scrap - A wizard is triggered indicating insufficient stock quantity. - validate it Problem: The quantity in the scrap is updated to 1000 kg, and the related move is created with a quantity of 1000 kg. opw-4485849 Forward-Port-Of: odoo/odoo#194012
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- UoM: g
- Go to inventory > operation > Scrap:
- Create a new one: - product: P1 - UoM: KG - Quantity: 1
- Validate the scrap
- A wizard is triggered indicating insufficient stock quantity.
- validate it
Problem:
The quantity in the scrap is updated to 1000 kg, and the related move is created with a quantity of 1000 kg.
opw-4485849
Forward-Port-Of: odoo/odoo#194012This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "
Original PR description
This PR addresses the layout issue in the sidebar of the portal, where a preview of the customer's invoice is displayed. Before this PR, users encountered a broken layout for large invoice amounts, making it difficult to read the total. This issue is resolved in this PR by adding a rules for the `h2` and `span` fields ensuring proper wrapping for better readability. Steps to reproduce: - Login as admin. - Go to Website app. - Navigate to "My account" at my/home url. - Click on "My invoices" or navigate to my/invoices url. - Click on one invoice in order to see its preview. - Via the browser tools, edit the amount of on the left sidebar and insert a very big number. task-4435472 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194277 Forward-Port-Of: odoo/odoo#192769
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, wh
Original PR description
Before this commit, when a new res.user is created after signing in with auth_ldap, there was no email on the linked res.partner, which may cause issues in modules such as helpdesk, where partner email is used to find related tickets. res.users created through the form view will trigger the onchange which sets the 'email' = 'login', which does not happen when creating a user directly through the ORM. This commit adds 'email' as a key which is returned by the method _map_ldap_attributes, which is used to create new partners with the correct email associated with the res.user login. opw-4378487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193495
Forward-Port-Of: odoo/odoo#195005 Forward-Port-Of: odoo/odoo#193276
Original PR description
Forward-Port-Of: odoo/odoo#195005 Forward-Port-Of: odoo/odoo#193276
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but no
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Ensure `geoip` works (or patch the `_get_geoip_country_code` method); 2. create two pricelists for the website; 3. first should be restricted to EU countries & use EUR; 4. second one shouldn't be restricted to any country & use USD; 5. log in as a Portal user without address details from a EU IP; 6. open the shop. Issue ----- The prices are displayed in USD. Cause ----- The geoip country is taken into account for public users, but not for partners. Instead it relies on the partner's country_id, which could be empty. Solution -------- When computing the `property_product_pricelist`, add the geoip country to the context. Use this value in the fallback for partners without specific pricelist property set, and without a `country_id`. opw-4398543 Forward-Port-Of: odoo/odoo#195656 Forward-Port-Of: odoo/odoo#194885
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3 different fonctionalities (a foot switch can work as a keyboard, a mouse and a joystick) Our current code only detects input from one of these 3 event files (the last one in the list) while the input is actually only sent to the keyboard event file. Since "evdev" and "usb core" libraries don't allow us t
Original PR description
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3…
Currently foot pedals often don't send their input to Odoo This is due to the fact that the foot pedals are detected as 1 usb device which is associated with 3 separate event files for its 3 different fonctionalities (a foot switch can work as a keyboard, a mouse and a joystick) Our current code only detects input from one of these 3 event files (the last one in the list) while the input is actually only sent to the keyboard event file. Since "evdev" and "usb core" libraries don't allow us to determine which evdev device is the right one this PR allows listening to all of the event files associated to a usb device to read input from all of them. This PR also adds some comment to simplify the understanding of the input detection and event files structure on Linux. Note: on IoT Box images > 25.01 the user "odoo" which runs Odoo service needs to be in the group "input" to be able to correctly detect evdev devices and have access to their event files. task-4432802 Related PR: #195307 Forward-Port-Of: odoo/odoo#195306
- open a record with an URL: `/{model}/{id}`; - delete or archive the record; Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button. This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is : - if a pager exists, disp
Original PR description
- open a record with an URL: `/{model}/{id}`;
- delete or archive the record;
Before this commit, an empty form view was displayed, with an incorrect URL: `/{model}/new`. This form view was inconsistent, and would throw an error in some applications (such as accounting). Even if no error was thrown, an error would be thrown if the user clicked on the 'back' button.
This is not the correct behaviour, when deleting or archiving a record, the correct behaviour is :
- if a pager exists, display the next record;
- if not, return to the previous controller (the previous action, usually the multi-record view);
The issue here is that we don't have a previous action or a multi-record view.
Now, in this particular case, we will fallback to the default application.
opw-4354129
Forward-Port-Of: odoo/odoo#195622
Forward-Port-Of: odoo/odoo#195393In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determin
Original PR description
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already…
In the current implementation, updating translations for a `blog.post` via the route `/web/dataset/call_kw/blog.post/web_update_field_translations` fails to apply changes when the post has already been translated once. This issue is caused by how the system fetches `website.default_lang_id` from the request. __Current behavior before commit:__ When editing a previously translated field for `blog.post` or `product.template`, the system retrieves the website from the request to determine the `source_lang`. This is used to search for the original term in the source language and update its translation. However, due to the `website=True` parameter not being set for the controller,the system defaults to English (`source_lang = 'en_US'`). As a result: 1. The system searches for the original word in English, even if it exists in another language. 2. The translation update fails because the original word cannot be found in English. __Description of the fix:__ A new controller was introduced to specifically handle translation updates, ensuring the correct language is fetched and the translation logic is applied correctly. __Steps to reproduce the issue:__ 1. Add 2 or more languages to the website. 2. Set the default language to any language other than English (US). 3. Create a blog post and write text in the default language. 4. Switch to another language, translate the text and save. 5. Edit the translated text again. The last edits are not saved. - bug introduced in: [#06346b0][1] - opw-4239512 [1]: https://github.com/odoo/odoo/commit/06346b049a3a13a9a8b63a4f60151ec24fabb59e Forward-Port-Of: odoo/odoo#184415
When a note was logged or a message was posted on any move, the email recipients of that message would get an email with both the move name and the total move amount (without any context) in the header. For invoices and vendor bills, this makes sense. As these are typically amounts that can be paid or received. However, for miscellaneous moves this was confusing users. Often it means nothing, and users wonder if they have to pay something. We remove the amount from messages sent on miscell
Original PR description
When a note was logged or a message was posted on any move, the email recipients of that message would get an email with both the move name and the total move amount (without any context) in the header. For invoices and vendor bills, this makes sense. As these are typically amounts that can be paid or received. However, for miscellaneous moves this was confusing users. Often it means nothing, and users wonder if they have to pay something. We remove the amount from messages sent on miscellaneous moves here. [opw-4042715](https://www.odoo.com/odoo/project.task/4042715) Forward-Port-Of: odoo/odoo#195647 Forward-Port-Of: odoo/odoo#195541
### Description of the issue/feature this PR addresses: - Similar error: https://github.com/odoo/odoo/pull/194338 - In `_compute_plan_available_ids()` with `self` there can be multiple records but still use `self.department_id` in `for scheduler in todo`. ### Current behavior before PR: - The error ValueError: Expected singleton: mail.activity.schedule(1, 2) occurred Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read
Original PR description
### Description of the issue/feature this PR addresses: - Similar error: https://github.com/odoo/odoo/pull/194338 - In `_compute_plan_available_ids()` with `self` there can be multiple records but still use `self.department_id` in `for scheduler in todo`. ### Current behavior before PR: - The error ValueError: Expected singleton: mail.activity.schedule(1, 2) occurred Desired behavior after PR is merged: - The problem has been fixed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194650
### Description of the issue/feature this PR addresses: Since this PR #162009, all uncommented invisible fields raise an error. This commit improves the error message from the method `test_uncommented_invisible_field` by showing which line of the view should be removed/commented. The error message before this commit : ``` Addons: 'module_name' Views: ['view_name1', 'view_name2'] ``` After: ``` Addon: 'module_name' View: view_name1 Fields: <field name="field1"
Original PR description
### Description of the issue/feature this PR addresses:
Since this PR #162009, all uncommented invisible fields raise an error.
This commit improves the error message from the method `test_uncommented_invisible_field` by showing which line of the view should be removed/commented.
The error message before this commit :
```
Addons: 'module_name' Views: ['view_name1', 'view_name2']
```
After:
```
Addon: 'module_name'
View: view_name1
Fields:
<field name="field1" invisible="1">
<field name="field2" invisible="1">
View: view_name2
Fields:
<field name="field1" invisible="1">
```
The main benefit of this change is to display in a single test all uncommented fields that need to be fixed.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#195166Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "cha
Original PR description
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before…
Have a form view opened in a dialog and edit the value of an input field (with onchange='1'), without bluring the input (i.e. such that the "change" event isn't fired yet). Press "Escape". Before this commit, it crashed with error "Component is destroyed". The reason is that when the dialog closes itself, the ui service focusses the previously active element (an element that was behind the dialog), which in turn blurs the current active element (the input that we edited), which fires the "change" event. However, at that point, the form controller is already destroyed, hence the error. In that flow, we don't want to perform the onchange as we're discarding the form. Actually, we don't want the field to listen to the "change" event anymore. We delay for a micro-tick the activation of the previously active element, to wait for owl to have called destroy on the whole component hierarchy, and thus for the "change" handler to be removed (in input_field_hook). The issue could be reproduced in Studio: - click on Edit menu - open a menu to edit it - change its name but to not blur/click out - press Esc This is a backport of odoo/odoo#195238, where we add a test (hoot). The faulty scenario could not be reproduced in the QUnit suite because we do not precisely enough mock events that occur when focusing/bluring elements. opw-4490577 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#195430 Forward-Port-Of: odoo/odoo#195242
Steps to Reproduce: ========= - Install the modules: pos_razorpay, l10n_in, and pos_restaurant. - Create a payment method for the Razorpay terminal. - Open a restaurant register linked to an Indian company with the added Razorpay terminal payment method. - Create an order, add a Razorpay payment line, and navigate to the floor screen. Issue: ========== - A traceback occurs when completing a payment. Cause: ========= - Polling for the Razorpay terminal continues even after leaving
Original PR description
Steps to Reproduce: ========= - Install the modules: pos_razorpay, l10n_in, and pos_restaurant. - Create a payment method for the Razorpay terminal. - Open a restaurant register linked to an Indian company with the added Razorpay terminal payment method. - Create an order, add a Razorpay payment line, and navigate to the floor screen. Issue: ========== - A traceback occurs when completing a payment. Cause: ========= - Polling for the Razorpay terminal continues even after leaving the payment screen and navigating to the floor screen. Fix: ========= - Stop the polling process when the user leaves the payment screen. - Resume polling only when the user returns to the payment screen. task-4414016 Forward-Port-Of: odoo/odoo#192072
- make kiosk mode open in the same page and logout the user to avoid unwanted rights Task: 4509632 Forward-Port-Of: odoo/enterprise#77852
Original PR description
- make kiosk mode open in the same page and logout the user to avoid unwanted rights Task: 4509632 Forward-Port-Of: odoo/enterprise#77852
### Steps to reproduce the issue: 1. Create an clean Analytic Account and use it in a Budget 2. Create a Purchase Order with Analytic Account in the Distribution and a Discount then Confirm 3. In the Budget report, the Committed Amount does not include the Discount ### Explanation: In the `purchase.order.line` side of the calculation of the committed amount of the budget report, we are using `unit_price` as base, because of it having a `not null` constraint, then adding a lot of other
Original PR description
### Steps to reproduce the issue: 1. Create an clean Analytic Account and use it in a Budget 2. Create a Purchase Order with Analytic Account in the Distribution and a Discount then Confirm 3. In the Budget report, the Committed Amount does not include the Discount ### Explanation: In the `purchase.order.line` side of the calculation of the committed amount of the budget report, we are using `unit_price` as base, because of it having a `not null` constraint, then adding a lot of other variables to extract the correct amount: `currency_rate`, `analytic_distribution`, `product_qty` and `qty_invoiced`. This does not include `discount` nor price-included `taxes_id`. ### Fix reasoning: To avoid an issue regarding down payment lines, which have no `price_subtotal`, we will prioritize the field with a fallback on `price_unit`. opw-4391098 Forward-Port-Of: odoo/enterprise#75902
At the moment, when grouping by a selection field, the in-database name of the selection option is shown rather than the human-readable name. This is fixed by the present commit. task-none Forward-Port-Of: odoo/enterprise#78145 Forward-Port-Of: odoo/enterprise#78128
Original PR description
At the moment, when grouping by a selection field, the in-database name of the selection option is shown rather than the human-readable name. This is fixed by the present commit. task-none Forward-Port-Of: odoo/enterprise#78145 Forward-Port-Of: odoo/enterprise#78128
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
Original PR description
Issue: Translations for terms "month", "year," and "week" are missing in the eCommerce subscription. Steps to reproduce: - Navigate to the website shop. - Pick a subscription product. - Change the language. "month" (along with the other two alternatives) is not translated. opw-4404734 Forward-Port-Of: odoo/enterprise#77395
Versions -------- - 17.0 - saas-17.2 - saas-17.4 - 18.0 Default automation rules were removed from the module via ca5de2aea907 Steps ----- 1. Copy a default automation from Subscriptions; 2. try to edit it. Issue ----- Action form is readonly, displaying the following message: > Action data can not be updated to avoid unexpected behaviors. Create a new automation rule instead. This makes sense for the default automations, but copies should be editable. Cause ----- T
Original PR description
Versions -------- - 17.0 - saas-17.2 - saas-17.4 - 18.0 Default automation rules were removed from the module via ca5de2aea907 Steps ----- 1. Copy a default automation from Subscriptions; 2. try to edit it. Issue ----- Action form is readonly, displaying the following message: > Action data can not be updated to avoid unexpected behaviors. Create a new automation rule instead. This makes sense for the default automations, but copies should be editable. Cause ----- The Subscriptions module adds a `is_sale_order_alert` field to its automations to make them readonly. This field is copied when duplicating an automation. Solution -------- Add `copy=False` to the field declaration to make copies editable. opw-4055597 Forward-Port-Of: odoo/enterprise#77008