Friday, July 12, 2024
14 changes · saas-17.1
Resolved issues and error corrections
Fixed an issue that could block users from loading Point of Sale demo data when loyalty features were installed and no POS products were available. This prevents an error screen during onboarding, making it easier to explore and set up POS.
Original PR description
Currently a traceback is occurring when the user tries to load demo data in POS. To reproduce this issue: 1) Install `POS`, `pos_loyalty` without demo data 2) Make sure no products are available in…
Currently a traceback is occurring when the user tries to load demo data in POS.
To reproduce this issue:
1) Install `POS`, `pos_loyalty` without demo data
2) Make sure no products are available in `POS` by disabling
the `Available in POS` for `products` in the `POS`
3) Now open a session and click the explore `demo data` button
Error:-
```
KeyError: 'pos_special_products_ids'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/point_of_sale/models/pos_session.py", line 2127, in load_product_frontend
return self.get_onboarding_data()
File "home/odoo/src/enterprise/saas-17.2/pos_preparation_display/models/pos_session.py", line 20, in get_onboarding_data
result = super().get_onboarding_data()
File "addons/point_of_sale/models/pos_session.py", line 1902, in get_onboarding_data
response = self.load_data(['pos.category', 'product.product'], True)
File "home/odoo/src/enterprise/saas-17.2/pos_settle_due/models/pos_session.py", line 20, in load_data
response = super().load_data(models_to_load, only_data)
File "addons/pos_loyalty/models/pos_session.py", line 103, in load_data
result['custom']['pos_special_products_ids'].extend(
```
When the user clicks on the `load demo` button, it triggers with `only_data` as a truthy value from `[1]`
But the `pos_special_products_ids` value assigns only if no `only_data` from `[2]`
which leads to a traceback from `[3]`
[1]
https://github.com/odoo/odoo/blob/d0cf45dc6bb472907f6b8542992f717c699f5a34/addons/point_of_sale/models/pos_session.py#L1904-L1905
[2]
https://github.com/odoo/odoo/blob/d0cf45dc6bb472907f6b8542992f717c699f5a34/addons/point_of_sale/models/pos_session.py#L289-L307
[3]
https://github.com/odoo/odoo/blob/d0cf45dc6bb472907f6b8542992f717c699f5a34/addons/pos_loyalty/models/pos_session.py#L103-L105
After applying this commit, it will resolve this issue by only accessing the value when the only_data value is falsy.
sentry-5588106710The web interface now handles unexpected language or locale formats safely instead of crashing. This improves reliability for users whose locale settings do not match the expected pattern, and ensures the related automated tests are loaded correctly.
Original PR description
If the regex used by pyToJsLocale doesn't match anything, the function will crash. This problem should have been caught by the tests, but they weren't added correctly to the assets bundle. This commit: - Fixes pyToJsLocale to return the locale as it is when parsing fails. - Converts the tests to HOOT (HOOT tests are loaded correctly) *: web Follow-up of https://github.com/odoo/odoo/pull/171176 Forward-Port-Of: odoo/odoo#172678 Forward-Port-Of: odoo/odoo#172580
Miscellaneous changes
This error occurs when we delete the specific ``Resupply Subcontractor on Order`` route and subsequently attempt to replenish the product. Steps to reproduce: - Install the ``stock`` and ``mrp_subcontracting`` module - Inventory > Configuration > Settings > Warehouse > Activate Multi-Step Routes - Go to routes and delete ``Resupply Subcontractor on Order`` - Now go to any product > Click on ``Replenish`` Traceback: ``AttributeError 'NoneType' object has no attribute 'id'`` At [1],
Original PR description
This error occurs when we delete the specific ``Resupply Subcontractor on Order`` route and subsequently attempt to replenish the product. Steps to reproduce: - Install the ``stock`` and…
This error occurs when we delete the specific ``Resupply Subcontractor on Order`` route and subsequently attempt to replenish the product. Steps to reproduce: - Install the ``stock`` and ``mrp_subcontracting`` module - Inventory > Configuration > Settings > Warehouse > Activate Multi-Step Routes - Go to routes and delete ``Resupply Subcontractor on Order`` - Now go to any product > Click on ``Replenish`` Traceback: ``AttributeError 'NoneType' object has no attribute 'id'`` At [1], this error occurs when we try to access an attribute called ``id`` on an object that is actually None. This commit will fix the above error by returning the value of ``domains`` if the route is not present in the ``_get_allowed_route_domain`` method. [1]: https://github.com/odoo/odoo/blob/731766aa03ad4cf14349169faab3957c710bc002/addons/mrp_subcontracting/wizard/product_replenish.py#L13 sentry-5514962307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170269
In Sweden, Peppol endpoint is required to be exactly 10 digits - no other characters are allowed. Currently, we're mapping SE peppol endpoint to be the VAT number, which contains the country code prefix and a 12-digit number. As a result, a lot of our invoices are being rejected by the Swedish access points. Let's map it to the company registry number and add a check in constrains. See: https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/ no task, customer feedback --- I confirm
Original PR description
In Sweden, Peppol endpoint is required to be exactly 10 digits - no other characters are allowed. Currently, we're mapping SE peppol endpoint to be the VAT number, which contains the country code prefix and a 12-digit number. As a result, a lot of our invoices are being rejected by the Swedish access points. Let's map it to the company registry number and add a check in constrains. See: https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/ no task, customer feedback --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172756
Issue: ====== Traceback occurs when you select more than one table cell Steps to reproduce the issue: ============================= - Go to to-do - Add a table 1row x 3cols - Add some content with somewhat big length for example "abcde" in the first cell - Add anything in the second cell - Start the selection from the last character of the first cell - Move the cursor to add selection from the second cell - Traceback Origin of the issue: ==================== When we have table
Original PR description
Issue: ====== Traceback occurs when you select more than one table cell Steps to reproduce the issue: ============================= - Go to to-do - Add a table 1row x 3cols - Add some content with somewhat big length for example "abcde" in the first cell - Add anything in the second cell - Start the selection from the last character of the first cell - Move the cursor to add selection from the second cell - Traceback Origin of the issue: ==================== When we have table cells selected, the first while loop stops at the `td` element and not the startContainer so we shouldn't enter in the if condition that handles the `br` elements task-4043879 Forward-Port-Of: odoo/odoo#172517
With the version 3.3, the 3bl tax tag has been removed and so the 3.2 script is throwing an error since that tag doesn't exist anymore The fix is that we remove the 3.2 script and change 3b tag to 3bg or 3bs in the 3.3 script along with the replacement of the 3bl tag Task: 4032184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172443 Forward-Port-Of: odoo/odoo#171737
Original PR description
With the version 3.3, the 3bl tax tag has been removed and so the 3.2 script is throwing an error since that tag doesn't exist anymore The fix is that we remove the 3.2 script and change 3b tag to 3bg or 3bs in the 3.3 script along with the replacement of the 3bl tag Task: 4032184 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172443 Forward-Port-Of: odoo/odoo#171737
For records such as blogs, no specific rights exists. Customizations could decide to give access to specific records based on their own rules. They are limited by the fact that the check for edition is not overridable. This commit makes it possible to implement specific checks for restricted editors to edit records from the website builder. Steps to reproduce: - Install `website_blog`. - Setup a restricted editor user. - Override `website._check_user_can_modify` to allow access for a gi
Original PR description
For records such as blogs, no specific rights exists. Customizations could decide to give access to specific records based on their own rules. They are limited by the fact that the check for edition is not overridable. This commit makes it possible to implement specific checks for restricted editors to edit records from the website builder. Steps to reproduce: - Install `website_blog`. - Setup a restricted editor user. - Override `website._check_user_can_modify` to allow access for a given user to a given blog post record. - Edit that blog post with that user from the website builder. => Blog post could not be edited. Forward-Port-Of: odoo/odoo#172385
Previously, seats availability check was not working properly. The check was comparing the availability of each ticket with the global amount of tickets in the registration (all tickets combined). This commit fixes the issue by comparing the availability of each ticket. In addition to that, the commit also adds an error message on the event page so that the user can see the error message when the ticket is not available. TASK-4029299 Forward-Port-Of: odoo/odoo#171614
Original PR description
Previously, seats availability check was not working properly. The check was comparing the availability of each ticket with the global amount of tickets in the registration (all tickets combined). This commit fixes the issue by comparing the availability of each ticket. In addition to that, the commit also adds an error message on the event page so that the user can see the error message when the ticket is not available. TASK-4029299 Forward-Port-Of: odoo/odoo#171614
Before this commit, the absence of rewards in a loyalty program would trigger an error, preventing the Point of Sale from opening. Although the current design does not support removing all rewards from a program, there exist databases in this state. opw-4045063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172597
Original PR description
Before this commit, the absence of rewards in a loyalty program would trigger an error, preventing the Point of Sale from opening. Although the current design does not support removing all rewards from a program, there exist databases in this state. opw-4045063 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172597
[IMP] l10n_tr: Add tax and tax report translation Add tax and tax report translation in turkish language for the new tr improvements task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172713
Original PR description
[IMP] l10n_tr: Add tax and tax report translation Add tax and tax report translation in turkish language for the new tr improvements task-id#3924220 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172713
Steps to reproduce ================== - Install web_studio,calendar - Go to calendar - Open studio => In the sidebar, Quick Create is disabled but should be enabled Toggling it does nothing Cause of the issue ================== The value was incorrectly read from `archInfo.hasQuickCreate` Solution ======== `hasQuickCreate` -> `quickCreate` This shows a second issue: Now that it's enabled, we can't disable it. This is because we remove the attribute instead of se
Original PR description
Steps to reproduce ================== - Install web_studio,calendar - Go to calendar - Open studio => In the sidebar, Quick Create is disabled but should be enabled Toggling it does nothing Cause of the issue ================== The value was incorrectly read from `archInfo.hasQuickCreate` Solution ======== `hasQuickCreate` -> `quickCreate` This shows a second issue: Now that it's enabled, we can't disable it. This is because we remove the attribute instead of setting it to false If we don't pass the attribute, it will keep it's default value (true) https://github.com/odoo/odoo/blob/2afce223268c4ee1ac3c98a6108b1390be82716b/addons/web/static/src/views/calendar/calendar_arch_parser.js#L34 opw-4023026 Forward-Port-Of: odoo/enterprise#66253
The aim of this commit is fixing the filtering of transactions when transactions have an empty identifier. Even if it's shouldn't be the case, it happens that providers return transactions without an identifier. In this case, it will always importe the first transaction and not the others as they have a similar id (an empty string). Now, we ignore in the filter these transactions. opw-4014171 Forward-Port-Of: odoo/enterprise#66473
Original PR description
The aim of this commit is fixing the filtering of transactions when transactions have an empty identifier. Even if it's shouldn't be the case, it happens that providers return transactions without an identifier. In this case, it will always importe the first transaction and not the others as they have a similar id (an empty string). Now, we ignore in the filter these transactions. opw-4014171 Forward-Port-Of: odoo/enterprise#66473
Steps to reproduce ------------------- - create a commission plan with: product category: "All" rate: R capped: True max commission: >>> - create a partner level with the created commission plan - create a partner with the created partner level - create a product in the correct category with price P - create a quotation template with the created product - create a sale order with the partner as referrer - add the quotation template (the product is added automatically)
Original PR description
Steps to reproduce ------------------- - create a commission plan with: product category: "All" rate: R capped: True max commission: >>> - create a partner level with the created commission plan -…
Steps to reproduce
-------------------
- create a commission plan with:
product category: "All"
rate: R capped: True
max commission: >>>
- create a partner level with the created commission plan
- create a partner with the created partner level
- create a product in the correct category with price P
- create a quotation template with the created product
- create a sale order with the partner as referrer
- add the quotation template (the product is added automatically)
- confirm
- create the invoice, confirm it and register the payment
At this moment, a purchase order is created (the commission) If we repeat these steps with a new sale order,
the amount of the purchase order will increase as expected.
- add a quotation template on the commission plan (in the rules)
- repeat the creation of a sale order.
No commission is added (purchase order line).
Cause:
------
We have no template when calling `_match_rules`.
However, our plan has a default template.
The result is that no rules are found.
Solution:
---------
Fallback on the sale order's template
if it is not a subscription.
opw-3933323
Forward-Port-Of: odoo/enterprise#64884**Current behavior:** Having a picking whose operation type has the `create_backorder='ask'` setting, if a barcode line is modified using the edit button rather than actually scanning, the confirmation dialog for the backorder will be skipped. **Expected behavior:** When the 'ask' option is used, the dialog should always be displayed. **Steps to reproduce:** 1. Create a picking with a demand of 2.0 for some product, ensure the picking's op type has the 'ask' options set for
Original PR description
**Current behavior:** Having a picking whose operation type has the `create_backorder='ask'` setting, if a barcode line is modified using the edit button rather than actually scanning, the…
**Current behavior:**
Having a picking whose operation type has the
`create_backorder='ask'` setting, if a barcode line is modified
using the edit button rather than actually scanning, the
confirmation dialog for the backorder will be skipped.
**Expected behavior:**
When the 'ask' option is used, the dialog should always be
displayed.
**Steps to reproduce:**
1. Create a picking with a demand of 2.0 for some product,
ensure the picking's op type has the 'ask' options set for
backorder creation (it's the default option) -> confirm the
picking
2. In Barcode, open the picking and add 1.0 quantity to the
barcode line
3. Save the edit form, then validate the picking -> no dialog
**Cause of the issue:**
Compared the actually scanning product, modifying the line via
the form actually updates the record data. This causes the
corresponding `StockMoveLine` to get marked as `picked=True`
(via `_inverse_qty_done()` in `stock_barcode::StockMoveLine`.
The end result is `!this.lineIsReserved(line)` evaluates to
True in the Barcode client when checking whether to do
the backorder dialog which means we skip it.
**Fix:**
Remove the `lineIsReserved()` check, only look at whether
the line quantity is positive, non-zero.
*Note: the behavior between the two flows (scans vs. form edits)
diverges when the user reloads the page, however, this was also
the case prior to this change.*
opw-3972478
Forward-Port-Of: odoo/enterprise#64318