Monday, December 18, 2023
18 changes · 17.0
Resolved issues and error corrections
The accounting onboarding tour now shows a more relevant instruction when users reach the invoice confirmation step. This helps users understand that they should confirm the invoice once it is ready, reducing confusion during setup or training.
Original PR description
Problem --------- In the accounting tour, during the invoice creating step, the message asking to confirm the invoice was irrelevant. Landed in 17.0 with this commit:cc6f85af2aac31816b51a0b39c9b119049f9954f Objective --------- Change the message into "Once your invoice is ready, confirm it." Solution --------- Change the relevant message in the tour JS file. task-3619638 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how website editor buttons behave when users duplicate a button or insert one between existing buttons. The copied or newly placed button now preserves the expected nearby styling, reducing unexpected design changes while editing pages.
Original PR description
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the…
[FIX] website: fix button snippet The commit [1] of this PR [2] has been merged requesting some changes to be made later, which are fixes to the button that can now be dropped onto the page from the snippet menu. This commit makes the following changes requested: - Before this commit, when we duplicated a button (by clicking on the "duplicate" button), the style of the new button was generated again in Javascript in the "_adaptButtons" function even though it is not necessary since we duplicate the HTML of the copied button. That is why this commit adds the "adaptAppearance" parameter for the "_adaptButtons" function. - Prior to this commit, when a button was dropped between two buttons, the style of the next button was copied as a priority. After this commit , the style of the previous button is now copied as a priority. [1]: https://github.com/odoo/odoo/commit/507b80a12574ce19bcb925d88868fb377b1c4b06 [2]: https://github.com/odoo/odoo/pull/126717 task-3555413
This update corrects how visibility rules are applied in the Public Holidays view. It helps ensure users see the right fields at the right time when managing time off and public holiday settings.
Original PR description
This attribute was not correctly updated with the big attribute revamp. This commit fixes that.
The mail app now avoids an inefficient lookup step when finding message-related records. This should make the experience slightly faster and smoother in areas that rely on mail records, without changing user-facing behavior.
Original PR description
This is a slow process that is better avoided.
The automated Sales Planning walkthrough was adjusted so it no longer keeps the "Shifts planned" filter active. This prevents inherited planning steps from failing and helps ensure the guided test flow remains reliable.
Original PR description
The fact that we let the filter causes issues in sale_planning, where the tour is inheritted.
This update corrects a display issue in financial reports for companies using the Anglo-Saxon accounting method. Previously, totals were automatically shown below sections by default. This change ensures that totals are only displayed when specifically requested, aligning with the requirements of the Anglo-Saxon accounting standard.
Original PR description
`totals_below_sections` should not be `True` by default if the company uses `anglo_saxon_accounting`. task-3612866
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
A merge conflict was incorrectly resolved during a code update, which accidentally changed the default currency exchange rate provider for India. This fix restores xe.com as the default provider for India, ensuring users in that region get the correct currency conversion service they expect.
Original PR description
During the forward-port of [1] to 17.0 [2], I resolved a merge conflict in the `res_config_settings.py` file incorrectly, which made it so that xe.com is not the default provider for India anymore (like in previous versions). This change fixes that and makes it again the default provider for India. [1] 24012f9db268a7722275a508374498bb18bbebdc [2] 40d62fb3ce62a22e455ec98f2fe692286138786e
This fix addresses an issue where subscription payments fail silently without notifying customers. When a payment token is invalid (expired, insufficient limits, or bad data), the system now properly handles the failure and sends notifications to customers instead of leaving transactions in draft state without any communication.
Original PR description
Steps: - Install a payment provider and subscription. - Create a subscription. - Set token on it which has max amount less then amount or expiry in the past or something that in invalid data to create order from provider. Issue: - As we are committing transaction in subscription and it does not processed it stays in draft state also it subscription does not send any failure notification to the customer Cause: - When `_send_payment_request` try to create order or try to create make request for recurring transaction it raise error in logger as values to make requests are invalid but it keeps transition in draft state and do not notify customer about payment failure Fix: WIP This does not seems to write fix for tokenize transaction
This update corrects balance sheet calculations for Romanian companies, fixing issues in both standard and IFRS balance sheets. The changes ensure accurate financial reporting by properly referencing accounts and adjusting how earnings are calculated, which is critical for companies to have correct financial statements.
Original PR description
In Romania, there are two balance sheets: one for general companies and one for companies applying IFRS. This commit aims to fix both. #### 1. Balancing the general balance sheet According to the…
In Romania, there are two balance sheets: one for general companies and one for companies applying IFRS. This commit aims to fix both. #### 1. Balancing the general balance sheet According to the Balance Sheet diagnosis tool in https://github.com/odoo/enterprise/pull/36838, some accounts were not referenced correctly. This is now fixed. We also re-do the Retained Earnings / Current Year Earnings with cross-reports to the P&L. #### 2. Balancing the IFRS balance sheet In addition to the issues encountered with the general balance sheet, the IFRS balance sheet also suffered from the problem that officially it should be used with a CoA dedicated for IFRS, which does not contain some of the accounts of the general CoA. Our solution is to nevertheless add those accounts to the Balance Sheet in appropriate locations. #### 3. Refactor the reports to use 1234D/1234C account code notation When the Romanian reports were first written, we thought that certain lines needed to contain a sum of debits or a sum of credits of AMLs of certain accounts. However, it is now certain that what was intended was the credit or debit balance of those accounts. We therefore remove the domain_formula expressions and replace them with account_codes_formula expressions. #### 4. Adapt the l10n_ro_saft tests to the CoA changes in the community PR Community PR: https://github.com/odoo/odoo/pull/145947 taskid: 3634044 Forward-Port-Of: odoo/enterprise#52823 Forward-Port-Of: odoo/enterprise#52603
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