Thursday, April 4, 2024
5 changes · saas-17.1
Resolved issues and error corrections
This update fixes several usability issues in the POS self-ordering flow, making combo selection, free orders, kiosk closing, and order history clearer and easier to use. Customers should experience fewer dead ends and faster screen transitions during self-service ordering.
Original PR description
- menu combo will not ask to select an item, if there only one in the category. - self-order do not show last screen with order number, when prices = 0.00. - kiosk: close button too small: we don't…
- menu combo will not ask to select an item, if there only one in the category. - self-order do not show last screen with order number, when prices = 0.00. - kiosk: close button too small: we don't notice it on large screens as it's not where we look. before:  after:  - 30 sec to close the "ticket number" screen since 5 minutes is too long. - self: My Orders outline with semi transparent background. before:  after:  - self: order date on closed orders. - fix: when you select a product with a variant but do not choose a variant and click on "discard" it is no longer possible to cancel the order and return to the home page. Task-3801901 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale users can now scan customer barcodes successfully again. This helps cashiers quickly identify and assign customers during checkout, reducing manual lookup time and avoiding checkout friction.
Original PR description
Prior to this commit, scanning a customer's barcode was not functioning as expected. This fix ensures that customer barcodes can be successfully scanned. opw-3825471 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix helps prevent brief, random errors that could affect users just after apps or system components are updated on one server worker. It ensures requests use the refreshed system information so the service stays more reliable during updates.
Original PR description
After modifying the registry on a worker (e.g. by installing a module), the first HTTP request on other workers may fail to compute the endpoint's readonly attribute and throw an exception (see _call_kw_readonly()). The user may then experience 'random' errors for a short period of time (until the registries/workers are recycled). The problem is that we are using the old registry (`registry`) instead of the one that can be reset by the check_signaling (`self.registry`).
This fix restores automatic installation of a required Dutch tax reporting support module. It helps ensure the related Dutch SBR reporting service works correctly without manual setup.
Original PR description
A current problem prevents modules with a list of countries in their manifest to be auto installed. This ensures this fix module will be auto installed as the main service is not working without it.
Shift templates that do not have a project assigned are now visible in the Planning configuration list and the Add Shift wizard. This prevents valid reusable shift templates from being hidden, helping planners access all available templates consistently.
Original PR description
Steps to reproduce: ------------------- 1. In Planning > Configuration > Shift Templates 2. Create a shift template without setting the project field 3. The shift templates without any project set do…
Steps to reproduce:
-------------------
1. In Planning > Configuration > Shift Templates
2. Create a shift template without setting the project field
3. The shift templates without any project set do not appear in the list view
4. The same thing happens when opening the 'Add Shift' wizard
Fix:
-------------------
In 17.1, when searching over the field 'company_id' of 'planning.slot.template', the ORM was not handling the case when the relation ('project_id' here) was not set. Thus, the "planning_slot_template_rule_multi_company" ir.rule was not accepting records whose 'project_id' was not set, as the 'company_id' was not considered to be False in this case. This limitation has been fixed in the following PR in 17.2: https://github.com/odoo/odoo/pull/127353 but was not backported. So we have to make our fix in 17.1 manually (and only in 17.1). The solution we found is then to expand the domain to accept shift templates whose 'project_id' is not set.
task-3839487
version-17.1