Monday, October 21, 2024
7 changes · saas-17.4
Resolved issues and error corrections
The chat interface’s “+X” counter now appears in regular text instead of italics. This small visual fix improves consistency and readability in the ChatHub area.
Original PR description
See the +7 that was italics before Before / After <img width="73" alt="Screenshot 2024-10-21 at 20 55 17" src="https://github.com/user-attachments/assets/3754e36b-5ade-4c28-991c-f3f73cc74d2c"> <img width="61" alt="Screenshot 2024-10-21 at 20 52 36" src="https://github.com/user-attachments/assets/3933af74-8e51-4c0e-8309-2ebbca303bda">
Users editing a message can now save or cancel their changes with a single click. This removes a small but frustrating interaction issue in the mail composer, making message editing feel more reliable.
Original PR description
Before this commit, when editing a message, we had to click twice on "Cancel" or "Save" to register the edit message action. This happens because while clicking on these action for the 1st time, composer intercepts a "focusout" event, which re-renders the template and thus the "Cancel" & "Save" buttons too, thus cancelling their action. The 2nd click doesn't trigger this focusout thus it works. This commit fixes the issue by moving code that generates the "Cancel or Save" text in a sub-component. Doing so ensures that the component is only rendered when needed, in this case when Composer.mode or ui.isSmall change. opw-4119283 Before  After 
The website product configuration dialog title now appears in the shopper's selected language. This fixes a missing translation caused by the title coming from a module whose translations were not loaded on website pages, improving localization consistency for online customers.
Original PR description
On the website, the title of the ProductConfigatorDialog is not translated into any language. This is because only "frontend modules" translations are fetched in the context of the website. The title of the dialog is defined in the "sale" module, which is not a frontend module, so the translation is missing. This commit solves the problem by redefining the string to translate in the website_sale module. Task-4182798
Product and combo configurator labels now use the correct translations on the website. This helps customers see consistent language when choosing product options online, reducing confusion during the buying process.
Original PR description
Backend translations are not loaded in the frontend, and since the product/combo configurators are defined in the backend and overridden in the frontend, any translations used both in the backend and the frontend need to be defined in both. opw-4182798
This fixes an intermittent failure affecting batch payment validation by removing a redundant early check that could run at the wrong time. The same business rule is still enforced when validating the batch, so users keep the intended protection while nightly builds become more reliable.
Original PR description
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly…
Since https://github.com/odoo/enterprise/pull/70230, this test https://github.com/odoo/enterprise/blame/saas-17.4/account_batch_payment/tests/test_account_batch_payment.py#L86 was failing on nightly runbot builds (but weirdly not on regular builds, probably due to the timing of stored fields recomputation and constraint validation). Essentially, the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L170 broke. This happened because, when resetting the payment to draft in the test, we triggered this compute function on the account.payment https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_payment.py#L18. This compute function did not reassign the batch_payment_id field, but the ORM still considered it modified, and hence recomputed the payment method of the batch via this compute function https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L69 . Then, this field triggered the constraint here https://github.com/odoo/enterprise/blob/saas-17.4/account_batch_payment/models/account_batch_payment.py#L149. The test raised then just when initializing the assertRaises, when the stored payment_method_id field of the batch got recomputed. It is possible to force it by flushing at that point, otherwise, it's not exactly deterministic. The part of the constraint ensuring a draft payment cannot be added to a batch is the problem. The test tries to set one of the payments in the batch back to draft, and if this happens, the batch will end up in a state that is inconsistent with its own constraint. We fix the issue by simply removing it. This check is done again anyway when validating the batch payment. Doing things this way, we ensure the scenario of the test works in every case, whatever crazy recomputations happen in the ORM.
Restaurant floor table setup now keeps the appointment resource information available when editing tables directly in the list. This prevents booking-related table settings from being lost or inaccessible after the interface change in version 17.4.
Original PR description
Steps to reproduce: - Install Restaurant and Appointments - in PoS's Settings, enable booking - go to PoS -> Configurations -> Floor plans - Select a floor - There is no "Appointment resource" field in the tree view Initially in 17.2, the tree items in the floor page (the tables) were not editable in place, so clicking on a table opened the form view where we could change the "Appointment resource". However, in 17.4, the tree was made editable in place, but we've missed adding the "Appointment resource" field. This PR adds back the field "Appointment resource" (as hidden field) to the floor tables tree view. The changes in this PR were copied from version 18.0, where this bug was already fixed by [this commit](https://github.com/odoo/enterprise/commit/f240b921dd3548b5f91d947354abc85f947f486b#diff-119979c4226bdf057abdfa1b8bb4572112e12e325e3e3461d0a6f258b792e979R19). opw-4237285
This update adjusts an internal performance test limit for subscriptions after a recent change added one database query when all modules are installed. It helps keep automated checks aligned with the current system behavior without changing customer-facing functionality.
Original PR description
File "/data/build/enterprise/sale_subscription/tests/test_performance.py", line 21, in test_recurring_order_creation_perf
with self.assertQueryCount(__system__=2309):
File "/usr/lib/python3.12/contextlib.py", line 144, in __exit__
next(self.gen)
File "/data/build/odoo/odoo/tests/common.py", line 549, in assertQueryCount
self.fail(msg % (login, count, expected, funcname, filename, linenum))
AssertionError: Query count more than expected for user __system__: 2310 > 2309 in test_recurring_order_creation_perf at /data/build/enterprise/sale_subscription/tests/test_performance.py:21
One more query has been added recently when all modules are installed.
runbot error: https://runbot.odoo.com/web#id=102953&view_type=form&model=runbot.build.error&menu_id=405&cids=1