Monday, May 27, 2024
15 changes · saas-17.2
Resolved issues and error corrections
This change prevents an error when staff open the restaurant Mobile View after a register has been closed and there are no active orders. It keeps the self-ordering page accessible instead of triggering a backend failure, improving reliability for restaurant operations.
Original PR description
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the…
This error usually occurs when there are no active orders present, and we've closed the register and then tried to access the ``Mobile View`` feature. Steps to reproduce: - Install the ``pos_restaurant`` and ``point_of_sale`` modules - Make sure there are no active orders in the restaurant - Dashboard > Open Register > Open session > Close Register - Dashboard > Restaurant > Dropdown Menu > Mobile View - An Error will be generated in the terminal Traceback : ``ValueError: bus.Bus only string channels are allowed.`` This situation arises because we have two self-ordering modes: i) ``Mobile`` and ii) ``kiosk``. When the condition at [1] is evaluated, it will become false because the session has been closed, causing ``pos_config.has_active_session`` to be false. Additionally, since the mode is ``Mobile``, the condition in the ``elif`` statement at [1] also evaluates to false. As a result, we will get the value of ``config_access_token`` as a boolean value from line [2] because the value of ``config_access_token`` will not be set from both of the above conditions. Due to ``config_access_token`` being a boolean value, the value of ``channels`` ends up being a boolean value. This commit will fix the above error by providing an empty string within ``config_access_token``, rather than boolean values. So, the value of ``channels`` will consistently be a string. [1]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L35-L47 [2]: https://github.com/odoo/odoo/blob/16120774d6e7b16b44f771ca8224426e78676295/addons/pos_self_order/controllers/self_entry.py#L16C8-L23C50 sentry-5136273134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reverts a previous update that could incorrectly switch an online shopper's cart customer to OdooBot in some website shop requests. Reverting it prevents wrong customer assignments while a cleaner long-term solution is prepared separately.
Original PR description
This reverts commit 4246d6e93e8450adc727981f3bb2b8c24aebafc9. This commit included changes that triggered sale_get_order calls in routes/requests that did not use it previously. Since those routes were using an environment sudoed with the superuser, the call to sale_get_order wrongly changed the customer to OdooBot. This will be addressed in a cleaner way in a separate PR, but for now, we only revert the wrong commit. opw-3949391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Settings page now properly activates developer mode when users click the option. This ensures administrators can access advanced configuration tools without needing a manual workaround or page refresh.
Original PR description
Steps to reproduce ================== - Go to settings - Click on "Activate the developer mode" => Nothing happens Cause of the issue ================== The page isn't reloaded Solution ======== Use the router and pass the reload option. The same call is done in debug_provider.js opw-3922717
Fixed an issue where gift cards sold in Point of Sale could fail to generate when product loading was restricted by category. The checkout now includes the required gift card products from the start of the session, ensuring customers receive the expected generated gift card.
Original PR description
Steps: --- - Install pos_loyalty with demo. - Configure shop to restrict product loading, only chairs. - Also make sure the setting is "Generate PDF Cards". - Open pos. - Search for the gift card (search more to load the product from server). - Sell the gift card. Issue: --- At checkout, there should be a generated gift card. Cause: --- Gift card product was not being loaded at the start of the POS session due to category restrictions. This caused `trigger_product_ids` to be empty since the product with the matching ID wasn't loaded. FIX: --- When loading data at the start of the session, load all products listed in `trigger_product_ids`. task-3911737
Miscellaneous changes
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_o
Original PR description
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in…
Steps to reproduce the bug: - In Website edit mode. - Drop 2 "Columns" snippets. - Hide one of the columns in the first snippet by clicking on the "Hide on desktop" button of the "Column" options in the side panel. - Start to drag another snippet. - Bug: There is no dropzone between the 2 "Column" snippets. The issue happens because when the column becomes invisible, after clicking the button, the attribute `data-invisible="1"` is added to the column in the DOM thanks the 'snippet_option_visibility_update' event. However, this event then propagates to the column's parent elements (`<section>` and `<main>`). So, the attribute `data-invisible="1"` is also added to the `<section>`, causing the dropzone not to be inserted as expected. We should investigate this further later because it doesn't seem consistent. For now, we prefer not to make changes at this level to avoid introducing other bugs. In this commit, we change the selector that determines where not to insert dropzones so that it no longer considers `data-invisible="1"`. This was added by this commit [1], but it seems unnecessary, and ':not(:visible)' in the selector is sufficient to avoid placing dropzones between two non-visible elements. [1]: https://github.com/odoo/odoo/commit/f9bd3033b21dbd1e4487d6d6cd1d8d8fdfbfb2ac Forward-Port-Of: odoo/odoo#165797
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155029 Forward-Port-Of: odoo/odoo#153993
Original PR description
refactor 'scan_barcode' method to use barcodes function task id: 3674936 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155029 Forward-Port-Of: odoo/odoo#153993
If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l
Original PR description
If some of the taxes in l10n_hu have been deleted, the installation of l10n_hu_edi fails with a NotNullViolation. This is not ideal, because sometimes users have heavily customized taxes and may want to use the EDI without reloading the default taxes. We now avoid failing the installation if the tax configuration would fail. This therefore gives users 3 options: - manually setting the NAV tax code on their Hungarian taxes - reloading the CoA after installing l10n_hu_edi - uninstalling l10n_hu_edi (if they don't want to use it) opw-3912298 Forward-Port-Of: odoo/odoo#166043
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available. - Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping. ## Steps To Reproduce: - Install UPS US on your db and publish it. - unpublish the other shipping methods. - Go to /shop and purchase any product a
Original PR description
## Issue: - When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping…
## Issue:
- When a customer places an order on the website and there are errors in the shipping informations, such as an invalid address format, the shipping costs drop to 0€ if only one shipping method is available.
- Despite these errors, Odoo does not block the "Pay now" button, allowing the customer to proceed and pay 0€ for shipping.
## Steps To Reproduce:
- Install UPS US on your db and publish it.
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, add an address that has more than 35 characters
- Notice you'll be allowed to pay and your order will be confirmed.
In an other scenario:
- Install Fedex US on your db and publish it.
- Set Fedex service type to STANDARD_OVERNIGHT
- unpublish the other shipping methods.
- Go to /shop and purchase any product as a customer
- During the checkout process, set Hawaii in state/Povince
- Notice you'll be allowed to pay and your order will be confirmed even though Hawaii doesn't support STANDARD_OVERNIGHT shipping.
## Explanation and Solution:
- The first issue arises when there is only one shipping provider available; it gets selected by default. After this selection, the `start` method of `websiteSaleDelivery` is triggered, which attempts to force-click the already checked shipping carrier. Consequently, it returns without completing the logic because the click event handler `_onCarrierClick` dismisses with the following condition:
`if (radio.checked && !this._shouldDisplayPickupLocations(ev)) {return;}`
- The second problem occurs because the `start` method is triggered as soon as the `websiteSaleDelivery` public widget is rendered, which does not allow enough time for the `PaymentButton` to be rendered. This delay causes the `_disablePayButton` method to fail.
- To address the first issue, I added a flag `refreshclick` to indicate that the shipping carrier was set by default.
- To address the second issue, I modified the `_enableButton` method to actively disable the button if the status is false. This change ensures that the `PaymentButton` widget has sufficient time to render since `_enableButton` is called within `_handleCarrierUpdateResult` after awaiting the response from an RPC call.
opw-3844214
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#165832
Forward-Port-Of: odoo/odoo#161704### Issue: Trying to validate a wave transfer with an empty picking will raise and error. ### Expected behavior: The empty picking should be removed from the wave transfer and the rest of the operations should be validated. ### Steps to reproduce: - In the settings: enable Batch Transfers > Wave Transfers - Create 2 receipts: 1) 1 x product P1 2) 1 x product P2 - In the inventory overview, click on the dots of receipts > operations - Select your receipts > Add to w
Original PR description
### Issue: Trying to validate a wave transfer with an empty picking will raise and error. ### Expected behavior: The empty picking should be removed from the wave transfer and the rest of the…
### Issue:
Trying to validate a wave transfer with an empty picking will raise and error.
### Expected behavior:
The empty picking should be removed from the wave transfer and the rest of the operations should be validated.
### Steps to reproduce:
- In the settings: enable Batch Transfers > Wave Transfers
- Create 2 receipts:
1) 1 x product P1
2) 1 x product P2
- In the inventory overview, click on the dots of receipts > operations
- Select your receipts > Add to wave > Create new wave transfer
- Go to inventory > Operations > Transfers > Wave transfers
- Open your wave transfer and set the quantity of P1 to 0
### Cause of the issue:
Currently, only the empty pickings 'waiting for another operation' are removed from the batch when it is validated:
https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L201-L204
In particlar, other empty pickings will not pass the sanity check: https://github.com/odoo/odoo/blob/3cfe548ee03f96713c7a6d462409be9c825d22e7/addons/stock_picking_batch/models/stock_picking_batch.py#L217-L218 and an operation error will be raised for them.
opw-3884043
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163320**Current behavior before PR:** Opening a chatwindow for a channel the user is not a member of would result in an error. This occurs because the chatwindow' fold state is saved to the server, but the server expects the user be a member of the channel. **Steps to reproduce:** 1. Create a channel and change it's Authorized group to null making it public 2. Mention a user who is not a member of this channel. 3. Login through the mentioned user. 4. Open the systray and click on the mess
Original PR description
**Current behavior before PR:** Opening a chatwindow for a channel the user is not a member of would result in an error. This occurs because the chatwindow' fold state is saved to the server, but the server expects the user be a member of the channel. **Steps to reproduce:** 1. Create a channel and change it's Authorized group to null making it public 2. Mention a user who is not a member of this channel. 3. Login through the mentioned user. 4. Open the systray and click on the message notification. 5. It will open the chatwindow and throw the error. **Desired behavior after PR is merged:** Prevent saving the fold state to server if the user is not a member of the channel. task-[3890519](https://www.odoo.com/web?debug=1#id=3890519&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163161
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website p
Original PR description
Inside our `_fetchQuiz` we pass the markup() to the quiz description to check that the description we have introduced is safe to be converted into html, the problem is that this markup() is not handling properly when the value of `quiz_data.slide_description` is false, so instead of not displaying anything we are sending a string of 'false'. Steps to reproduce: 1. Create quiz-type content inside a course in the e-learning app. 2. Do not add a description to the quiz. 3. Go to the website page of the course. 4. Open the quiz in fullscreen. 5. A "false" message is displayed on the top-left corner. opw-3887445 Forward-Port-Of: odoo/odoo#164549
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor bill in USD (10 $) > Now Receive the quantities > Check the valuation > Wrong value (15.92 $) the value should be 10$ (taken from the bill) Bug: In the case of BIlling policy on Ordered Quantities and PO in a foreign currency we assume the bill will be in same currency as the PO Fix:
Original PR description
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor…
Steps to reproduce: > The Company Currency is the Dollar > Create a product > Set FIFO and Manual valuation > Set BIlling policy as Ordered Quantities > Create Purchase order in Euro > Create Vendor bill in USD (10 $) > Now Receive the quantities > Check the valuation > Wrong value (15.92 $) the value should be 10$ (taken from the bill) Bug: In the case of BIlling policy on Ordered Quantities and PO in a foreign currency we assume the bill will be in same currency as the PO Fix: currently unit price is first computed in PO currency and then converted in the end to company currency added conversion from bill to PO opw-[3805454](https://www.odoo.com/web#id=3805454&view_type=form&model=project.task) also fixed a rounding issue opw-[3773413](https://www.odoo.com/web#id=3773413&view_type=form&model=project.task) alternative fix: compute everything in company currency (https://github.com/odoo/odoo/pull/155937) Forward-Port-Of: odoo/odoo#166346 Forward-Port-Of: odoo/odoo#162827
Default Price on POS would not show on older versions if there was a default pricelist set already on the POS. But would show default price if it was unset. This was not changed in the refactor, so the line that was referenced to see if default pricelist was set was referring to a variable that was no longer being set. Using the current default pricelist that is stored at pos.config.pricelist_id achieves the same functionality as before on this version of the POS. opw-3926123 --- I con
Original PR description
Default Price on POS would not show on older versions if there was a default pricelist set already on the POS. But would show default price if it was unset. This was not changed in the refactor, so the line that was referenced to see if default pricelist was set was referring to a variable that was no longer being set. Using the current default pricelist that is stored at pos.config.pricelist_id achieves the same functionality as before on this version of the POS. opw-3926123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166577
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166597 Forward-Port-Of: odoo/odoo#163938
Original PR description
When company is not passed as parameter, take the company from the environment by consistency with 'retrieve_partner'. Also, search for a product explicitely linked to the company in priority. enterprise PR: https://github.com/odoo/enterprise/pull/61741 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#166597 Forward-Port-Of: odoo/odoo#163938
In september 2023 7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 replaced this._rpc by `this.bindService("rpc")`. In may 2024 58324ee59946c7bfe9970b5202cce8d4a36a69b0 was forward-ported without adaptating it to the new way rpc is used. This is causing report of an error in some case when using stripe express checkout. note: in saas-17.1 the code has to be changed again to `await rpc`. opw-3917632 Forward-Port-Of: odoo/odoo#166602
Original PR description
In september 2023 7422eb643c5922bde8c70edfbe7b6f8dad53c1d9 replaced
this._rpc by `this.bindService("rpc")`.
In may 2024 58324ee59946c7bfe9970b5202cce8d4a36a69b0 was
forward-ported without adaptating it to the new way rpc is used.
This is causing report of an error in some case when using stripe
express checkout.
note: in saas-17.1 the code has to be changed again to `await rpc`.
opw-3917632
Forward-Port-Of: odoo/odoo#166602