Monday, December 18, 2023
9 changes · 17.0
Resolved issues and error corrections
Fixed an issue where customers could not book multiple consecutive appointment slots for the same person when using paid appointments with eCommerce. The system was incorrectly rejecting valid back-to-back bookings during checkout. This fix allows customers to successfully book and pay for contiguous time slots without receiving availability errors.
Original PR description
HOW TO REPRODUCE: With eCommerce and appointment_account_payment installed, book Mitchell admin on a slot at 9am on a paid appointment. Once the booking is in cart, book another one at 10pm and with…
HOW TO REPRODUCE: With eCommerce and appointment_account_payment installed, book Mitchell admin on a slot at 9am on a paid appointment. Once the booking is in cart, book another one at 10pm and with Mitchell Admin, try to pay the cart. An error message spawns and warn you that one of the bookings is not available. ISSUE: When filtering out unavailable bookings, the availability was computed on the different time intervals formed by bookings time ranges. However, the method returning intervals grouped the contiguous ones. So the user was considered as having a unique availability on the grouped intervals. Therefore, all but the first would be considered as unavailable. FIX: Use custom means to check all intervals, not merging contiguous ones. A test is added. At the same time, coverage is maximized in a simple way for bookings based on users. A condition is also added for resources when evaluating booking availability to avoid a crash when a resource is not linked to any appointment anymore. Task-3570588 for reference, method used for users https://www.geeksforgeeks.org/how-to-implement-interval-scheduling-algorithm-in-python/
Fixed an issue where certain menu options in the helpdesk team dashboard were hidden from users without editing permissions. Now, users with read-only access can see and access View Tickets and Reporting options (Tickets Analysis and SLA Status Analysis), which are also available in the main Reporting menu. The layout has also been improved to prevent text from shrinking when these options are displayed.
Original PR description
Some condition in the helpdesk team dashboard kanban-menu prevented to display some options if the widget was not editable by the user, which makes sense for the settings/color options but not that much for the View > tickets or Reporting > Tickets Analysis/ SLA Status Analysis since those are available in the Rporting menu anyway In terms of implementation: Removed the widget.editable condition for those Changed the style for the Reporting column to take as much place has needed, this shoudl prevent the longer text from shrinking and won't change anythin if the colorpicker/Settings menu are available for the user Task-3599248
Fixed an issue where clicking on a Gantt chart cell to create a new record wasn't preserving important default information like the assigned user or correct dates. Now when you click on a specific row in the Gantt view and create a new record, it will automatically populate with the relevant details from that row, making task creation faster and more accurate.
Original PR description
*= sale_planning, industry_fsm_sale Before this commit user was unable to get default values on clicking a gantt cell for creating new record. Also in planning user is getting wrong dates on clicking a cell for creating new record. Steps to reproduce: - Open the Gantt view of tasks (or the one of Planning). - Click on a cell from a specific line e.g. the Gantt view is grouped by user and you're creating a task for Marc Demo specifically. - Click on New button. Observed behavior: The new record is not assigned to Marc Demo by default Expected behavior: The new record should be assigned to Marc Demo by default After this commit user will be able to get default values on clicking a gantt cell for creating new record. Also in planning user will get correct dates on clicking a cell for creating new record. Task-3575768
This fix prevents an error from occurring when users try to send a point-of-sale receipt via WhatsApp if the WhatsApp template has been deleted. Previously, deleting the POS Receipt template would cause the system to crash when attempting to send receipts. Now the system handles this gracefully without disrupting the user experience.
Original PR description
This issue occur when the user tries to create an order, and when the order is successfully placed at the point of sale and sent via WhatsApp to receive the order to the user, an error will be…
This issue occur when the user tries to create an order, and when the order is successfully placed at the point of sale and sent via WhatsApp to receive the order to the user, an error will be generated due to WhatsApp template was deleted.
step to reproduce:
- Install the `WhatsApp-POS` module.
- Open the `WhatsApp`.
- Configuration Menu > WhatsApp Business Accounts > create the account.
- After the complete Configuration of account > delete the `POS Receipt` record.
- Open the `Point Of Sale`.
- Go to Dashboard > Shop (New session).
- Open session > create the one order.
- Enter the number in WhatsApp Receipt > click on WhatsApp symbol.
- The error will be generated.
sentry traceback-
```
ValueError: not enough values to unpack (expected 1, got 0)
File "odoo/models.py", line 5457, in ensure_one
_id, = self._ids
ValueError: Expected singleton: whatsapp.template()
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/saas-16.4/whatsapp_pos/models/pos_order.py", line 31, in action_sent_receipt_on_whatsapp
whatsapp_composer._send_whatsapp_template()
File "home/odoo/src/enterprise/saas-16.4/whatsapp/wizard/whatsapp_composer.py", line 228, in _send_whatsapp_template
body = self._get_html_preview_whatsapp(rec=rec)
File "home/odoo/src/enterprise/saas-16.4/whatsapp/wizard/whatsapp_composer.py", line 281, in _get_html_preview_whatsapp
return self.wa_template_id._get_formatted_body(variable_values=template_variables_value)
File "home/odoo/src/enterprise/saas-16.4/whatsapp/models/whatsapp_template.py", line 733, in _get_formatted_body
self.ensure_one()
File "odoo/models.py", line 5460, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
If the user deletes the WhatsApp template after this commit, it will prevent the
traceback while sending the receipt through WhatsApp.
sentry-4583290175
Forward-Port-Of: odoo/enterprise#49817When a subscription is closed, the end date is now always set to today's date instead of being preserved from the original value. This prevents subscriptions from showing end dates in the future, ensuring accurate subscription status tracking and reporting.
Original PR description
This commit, when the SO was closed with a reason, the end_date was kept. This commit makes sure that the end_date is always equal to today to avoid end_date in the future. taskid: 3635467 Forward-Port-Of: odoo/enterprise#52588
This fix resolves a problem where the Mexico POS EDI module was trying to use a field that only exists in the accounting EDI module. Since the dependency between these modules was removed in version 16.4, the code has been updated to work independently. This ensures the Mexico localization features work correctly without requiring the accounting EDI module.
Original PR description
The field edi_format_ids is only part of the module account_edi. The dependency between l10n_mx_edi and account_edi has been removed in 16.4. Linked to runbot error 52360 Forward-Port-Of: odoo/enterprise#52606
This fix improves the bank reconciliation process when dealing with foreign currency transactions. Users can now remove exchange differences during reconciliation, eliminating the need to create additional write-off entries and exchange difference records. This streamlines the reconciliation workflow and reduces manual accounting adjustments.
Original PR description
In case the foreign currency is missing on the bank transaction, a partial could be suggested to the user with an exchange difference. This commit allows the user to remove the exchange difference to…
In case the foreign currency is missing on the bank transaction, a partial could be suggested to the user with an exchange difference. This commit allows the user to remove the exchange difference to spare the generation of an exchange difference entry and the creation of a write-off line on the bank reco widget. Suppose: 1200.0 comp_curr = 2400.0 foreign_curr in 2017 (rate 1:2) 1200.0 comp_curr = 3600.0 foreign_curr in 2016 (rate 1:3) a statement line of 1200 comp_curr and an invoice of 3600.0 foreign_curr. | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -2400.0 | -800.0 | | exch diff | | -400.0 | ...creating a partial reconcile on the invoice. After removing the partial, you are forced to create a write-off: | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -3600.0 | -1200.0 | | exch diff | | -600.0 | | write-off | | 600.0 | After this commit, you are able to remove the exchange difference: | Line | foreign_curr | comp_curr | | -----------| ------------ | --------- | | liquidity | | 1200.0 | | new_aml | -3600.0 | -1200.0 | ...allowing to fully reconcile the invoice without any additional exchange difference entry. task: 3628473 Forward-Port-Of: odoo/enterprise#52645 Forward-Port-Of: odoo/enterprise#52228
Fixed an issue in the bank reconciliation widget where the suggested account for auto-balance lines was not correctly using partner information when the partner wasn't directly set on the statement line. Now when a partner is identified through alternative methods (like partner name or bank account details), the system properly suggests the correct account associated with that partner, improving reconciliation accuracy.
Original PR description
When the partner is not set on the statement line but retrieved in another way (partner's name, bank account etc), the suggested account on the auto_balance line should be the ones coming from the retrieved partner. Forward-Port-Of: odoo/enterprise#52894 Forward-Port-Of: odoo/enterprise#52691
This fix resolves a server error that occurred when portal users tried to view shared tasks in the Field Service module. The issue was caused by template code that referenced fields not properly defined in the module. The fix moves this code to the correct location, allowing portal users to access their assigned tasks without errors.
Original PR description
To reproduce ============ - create task in Fields service and share it with portal user - portal user gets server error when opening the task Problem ======= the template `portal_my_task` in `industry_fsm` uses some fields that are not defined in `industry_fsm` a feature was reverted in `industry_fsm` and this code part was inadvertently left in wrong place, and this commit corrects that oversight. See https://github.com/odoo/enterprise/pull/44632 opw-3630553