Monday, July 15, 2024
42 changes · saas-17.3
Resolved issues and error corrections
Users who enter a new password that is shorter than the required minimum now see a clear error message instead of an unexpected system traceback. This improves the password change experience and avoids confusing error screens.
Original PR description
Before this PR: Attempting to change a password to a length shorter than the minimum requirement resulted in a traceback due to a syntax error in the validation message in commit [1]. After this PR: Setting a password shorter than the minimum length now throws a UserError. [1]: https://github.com/odoo/odoo/commit/c1f277a7d04d9d6035413e315556b41a44d0b5b2 task-3930129
This fixes an unreliable automated test in the Point of Sale area by removing a timing-sensitive check that was not needed. The change helps reduce false test failures, making development and releases more stable without changing customer-facing behavior.
Original PR description
The test was failing because it was trying to check if the line is to refund but sometime the test run the check to fast. We remove this check since the "Refund" button is clicked just after. So the check isn't necessary. RB err: 66471
The live chat window no longer shows the unread message banner when a chatbot is handling the conversation. This reduces unnecessary visual clutter because chatbot flows already pause for the visitor's next response.
Original PR description
The unread message banner helps users keep track of which messages they have read in a conversation. However, this does not make sense with the chat bot: the bot waits for the visitor's input at each step, so users do not need to remember where they left off when returning to the discussion. In this case, the banner is just unnecessary visual noise. This PR removes the banner when the chat bot handles the discussion with the visitor.
Features or functions removed from Odoo
An obsolete file left over from a previous change has been removed from Marketing Automation. This cleanup reduces unused code and helps keep the module easier to maintain without changing how users work.
Original PR description
Following #61777 , the action helper is removed to use instead a dialog template picker when using the 'new' button. However, it looks like one of the file should have been cleaned but was not. This commit removes it. Task-4035826
Miscellaneous changes
Problem: The `l10n_gcc_invoice.arabic_english_invoice` report was recently updated to fix (https://github.com/odoo/odoo/pull/169267) an issue related to RTL ordering. However, this fix uses the `_lang_get_direction` method. While fine on theoriginally targeted version, in 17.2 this method was reworked into a new api `_get_data`. FW ports for 17.2+ had this older method still. Purpose: Swap `_lang_get_direction` with new `_get_data` method in report opw-4045879 Forward-Port-Of: odoo/odoo#1
Original PR description
Problem: The `l10n_gcc_invoice.arabic_english_invoice` report was recently updated to fix (https://github.com/odoo/odoo/pull/169267) an issue related to RTL ordering. However, this fix uses the `_lang_get_direction` method. While fine on theoriginally targeted version, in 17.2 this method was reworked into a new api `_get_data`. FW ports for 17.2+ had this older method still. Purpose: Swap `_lang_get_direction` with new `_get_data` method in report opw-4045879 Forward-Port-Of: odoo/odoo#172684
In a call to search_panel_select_multi_range for a many2many with a limit set and expand=False (default), 2 filterings of comodel records (more precisely records in comodel_domain) are done. First only up to L=limit records are fetched, then only those that are in the domain image are used to create values in field_range. The limit check is done after the 2 filterings. Let us write - C for the set of comodel records - F for the set of comodel records obtained by the first filtering -
Original PR description
In a call to search_panel_select_multi_range for a many2many with a limit set and expand=False (default), 2 filterings of comodel records (more precisely records in comodel_domain) are done. First…
In a call to search_panel_select_multi_range for a many2many with a
limit set and expand=False (default), 2 filterings of comodel records
(more precisely records in comodel_domain) are done. First only up to
L=limit records are fetched, then only those that are in the domain
image are used to create values in field_range. The limit check is done
after the 2 filterings.
Let us write
- C for the set of comodel records
- F for the set of comodel records obtained by the first filtering
- I fot the set of comodel records in the domain image
The code to be valid should do the check on C ⋂ I while it
does it on F ⋂ I so that 2 bad things can happen:
- #(F ⋂ I) < L but #(C ⋂ I) = #(F ⋂ I) + #((C ∖ F) ⋂ I) >= L
so that the error_msg is not returned while it should
- #(C ⋂ I) < L and #((C ∖ F) ⋂ I) >= 1
so that some records that should be shown are not
We use the fact that it is possible in 15.0 and after to use many2many
fields in read_group to make a single correct filtering, that is get C ⋂ I
and do the limit check on it.
opw-3827751
Forward-Port-Of: odoo/odoo#172963The recent PR #171722 introduced the use of stdnum and zeep Python libraries in odoo/tools/_monkeypatches.py Now when connecting an iot box to a database Odoo never starts on it as the IoT Box Image 24_01 doesn't have these libraries. This PR adds the try/except around the imports of them and adds a check to make sure that the variables defined through these libraries exist With these try/except the IoT Box works as expected Forward-Port-Of: odoo/odoo#172887 Forward-Port-Of: odoo/odoo#
Original PR description
The recent PR #171722 introduced the use of stdnum and zeep Python libraries in odoo/tools/_monkeypatches.py Now when connecting an iot box to a database Odoo never starts on it as the IoT Box Image 24_01 doesn't have these libraries. This PR adds the try/except around the imports of them and adds a check to make sure that the variables defined through these libraries exist With these try/except the IoT Box works as expected Forward-Port-Of: odoo/odoo#172887 Forward-Port-Of: odoo/odoo#172789
### Steps to reproduce: 1. Create a product - Tracked by serial numbers - Set the weight to 2kg - Update the quantity on hands to 2 (with serials numbers) 2. Create a transfer of 2 quantities of the product 3. Open the detailed operations 5. Set the quantity done on a single line 6. Go back to the transfer and click put in pack 7. Select any package ### Before this commit: The shipping weight is 4 kg instead of 2 kg, as it takes all lines regardless of their picked state.
Original PR description
### Steps to reproduce: 1. Create a product - Tracked by serial numbers - Set the weight to 2kg - Update the quantity on hands to 2 (with serials numbers) 2. Create a transfer of 2 quantities of the product 3. Open the detailed operations 5. Set the quantity done on a single line 6. Go back to the transfer and click put in pack 7. Select any package ### Before this commit: The shipping weight is 4 kg instead of 2 kg, as it takes all lines regardless of their picked state. ### After this commit: Only the picked move lines are used to compute the shipping weight. opw-4028054 Forward-Port-Of: odoo/odoo#172790
Steps to reproduce: - Create a subcontracted bom for a product with: - Flexible consumption (with warning) - One component requiring 1 qty - Create a receipt for 10 for that product from the recorded subcontractor - Click on 'Record Component' and set: - Quantity (subcontracted product) to 3 - Done (component) to 5 - Record Production and validate the warning - Discard the wizard - Validate the picking and select 'No backorder' Issue: Once validated, the subcontracted consu
Original PR description
Steps to reproduce: - Create a subcontracted bom for a product with: - Flexible consumption (with warning) - One component requiring 1 qty - Create a receipt for 10 for that product from the recorded…
Steps to reproduce: - Create a subcontracted bom for a product with: - Flexible consumption (with warning) - One component requiring 1 qty - Create a receipt for 10 for that product from the recorded subcontractor - Click on 'Record Component' and set: - Quantity (subcontracted product) to 3 - Done (component) to 5 - Record Production and validate the warning - Discard the wizard - Validate the picking and select 'No backorder' Issue: Once validated, the subcontracted consumption will be back to 3 instead of 5. During the subcontracted move's `_action_done()`, as the move is incomplete, it will be split in two. After doing the split, the `product_uom_qty` of the initial move will be changed to its done quantity, which will trigger the update of the subcontracted demand. This will end up triggering `change_prod_qty()` of the recorded production, but to change its quantity to the same quantity. However, doing that will reset the consumption of its components to what would be expected from the bom. Instead of doing that, we can simply stop if there is no quantity to remove anymore before calling `change_prod_qty()`. opw-4032052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172243 Forward-Port-Of: odoo/odoo#171078
There is currently an issue with the `report_stock_quantity` SQL view. When there is only 1 `stock_warehouse` in a given database and `pg_stats` for `stock_warehouse` is up-to-date, the query plan for scanning the `all_sm` cte (the `existing_sm` cte is always inlined) becomes extremely bad. That's because postgres somehow expects only 1 row returned by the `all_sm` cte whereas in real databases it can be closer to 500 000. This makes postgres plan a Nested Loop Join that has very bad performance
Original PR description
There is currently an issue with the `report_stock_quantity` SQL view. When there is only 1 `stock_warehouse` in a given database and `pg_stats` for `stock_warehouse` is up-to-date, the query plan…
There is currently an issue with the `report_stock_quantity` SQL view. When there is only 1 `stock_warehouse` in a given database and `pg_stats` for `stock_warehouse` is up-to-date, the query plan for scanning the `all_sm` cte (the `existing_sm` cte is always inlined) becomes extremely bad. That's because postgres somehow expects only 1 row returned by the `all_sm` cte whereas in real databases it can be closer to 500 000. This makes postgres plan a Nested Loop Join that has very bad performances in large databases. Another weird side-effect of this is the production vs staging (duplicate) on Odoo.sh. Because stagings and duplicates don't necessarily have up-to-date statistics, you can have the same query being very slow on the production database and very fast on a staging. That's because in the absence of statistics for the stock_warehouse table, postgres does not make any particular assumption on the number of rows returned by the `all_sm` cte and therefore produces a more efficient plan. This commit tries to change that by introducing a new small CTE that simply does a LEFT JOIN between `stock_location` and `stock_warehouse`. Because this CTE is referenced twice in the `existing_sm` CTE, it will be materialized by postgres, i.e. evaluated first before being saved in memory for further usage. Thanks to that, postgres knows the expected number of rows of the CTE and can better plan the outer query's execution. #### speedup Customer database with 17 000 products, 700 000 stock.moves, 97 locations and 1 stock_warehouse. Doing a simple GROUP BY query on `report_stock_quantity`: 5min -> 1s ##### dalibo To understand the dalibo, currently there is a workaround for this issue. If we add (and archive) a new `stock_warehouse` and then analyze the table, postgres plans an efficient plan. My guess here is that with only 1 record postgres skews the plan, probably because it tries to shortcut parts of the query execution. When there are 2 or more warehouses it cannot do that anymore and simply relies on correct statistics to plan the execution. Another possibility would be that statistics for tables with only 1 row are badly used by postgres. In any case, the point of the new CTE is to match the 2 or more warehouses case when postgres plans the scanning of the `all_sm` CTE. - [1 warehouse, base case](https://explain.dalibo.com/plan/a8fagdgd2d20ae48) - [2 warehouses, base case](https://explain.dalibo.com/plan/2d38fb9ef6df495g) - [1 warehouse, new CTE case](https://explain.dalibo.com/plan/92e41053c9g0ce8d) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169401
This commit fixes a glitch in the animated spinner when running HOOT tests on small/mobile screen. Note: adding flex grow/shrink variants for consistency's sake. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172743
Original PR description
This commit fixes a glitch in the animated spinner when running HOOT tests on small/mobile screen. Note: adding flex grow/shrink variants for consistency's sake. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172743
Steps to reproduce: - Install Calendar and Appointment - Go to Calendar - Create a meeting with a name and click on "+ Odoo Meeting" - Copy this link and keep it on the side - Create the event and edit it - Copy the link Issues: The link doesn't match, this is because we are not sending the access token upon the creation of the meeting to the backend. This causes a new access token to be created which ends up in a new link. opw-3910706 Forward-Port-Of: odoo/odoo#169992
Original PR description
Steps to reproduce: - Install Calendar and Appointment - Go to Calendar - Create a meeting with a name and click on "+ Odoo Meeting" - Copy this link and keep it on the side - Create the event and edit it - Copy the link Issues: The link doesn't match, this is because we are not sending the access token upon the creation of the meeting to the backend. This causes a new access token to be created which ends up in a new link. opw-3910706 Forward-Port-Of: odoo/odoo#169992
Before this commit, when creating a channel from the discuss sidebar, the name of the channel would be transformed to lower case and stripped of accents. This happens because the same cleaned term used for searching gets used to define the name of the new channel. This commit fixes the issue by using the unaltered search term. Before:  After:  After:  Forward-Port-Of: odoo/odoo#172537 Forward-Port-Of: odoo/odoo#172494
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507
Original PR description
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as…
Description of the issue/feature this PR addresses: - In v17.0, the default value of 'analytic plan' (analytic_plan_id) has not been set in setting. - Analytic plan has config_parameter is set as "[analytic.analytic_plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/project/models/res_config_settings.py#L18-L22)" However, the default key was set different "[account.plan_projects](https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/analytic/data/analytic_data.xml#L13)" - And during the migration from v16.0 to v17.0, the default key generated in v16.0 is [removed](https://github.com/odoo/upgrade/blob/20faf7ba48595c61fc028ba1b4cf278d2c44e3cc/migrations/analytic/saas~16.5.1.1/pre-migrate.py#L10-L18) in saas~16.5 and new key will be set which this only "account.plan_projects" . - Because of the incorrect key value of 'analytic plan'(analytic_plan_id) is null. **Steps to reproduce:** - Install project module. - Go to Setting > Projects > got to Analytics section in that Analytic Plan. - Default analytic plan value is not there. **Solution:** - Set the correct key `analytic.project_plan` for the 'analytic_plan_id' field. **Current behavior in 16.0 :**  **Current behavior in 17.0 before pr:**  **Desired behavior after PR is merged:**  task-3941668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172123
Imagine a scenario where Odoo and Google calendars are synced. Then, this happens: 1. User goes to Google and changes one event from a recurrence series. 2. When saving, user chooses to modify "this event and all upcoming". 3. Odoo syncs from Google automatically via cron. <details> ``` 2024-07-04 10:02:21,094 25 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
Original PR description
Imagine a scenario where Odoo and Google calendars are synced. Then, this happens: 1. User goes to Google and changes one event from a recurrence series. 2. When saving, user chooses to modify "this…
Imagine a scenario where Odoo and Google calendars are synced. Then, this happens:
1. User goes to Google and changes one event from a recurrence series.
2. When saving, user chooses to modify "this event and all upcoming".
3. Odoo syncs from Google automatically via cron.
<details>
```
2024-07-04 10:02:21,094 25 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-07-04 10:02:21,568 25 INFO odoo odoo.addons.google_calendar.models.calendar_recurrence_rule: Recurrence #4838 | current rule: FREQ=WEEKLY;WKST=MO;UNTIL=20240620T215959Z;BYDAY=FR | new rule: FREQ=WEEKLY;WKST=MO;UNTIL=20240613T215959Z;BYDAY=FR | remaining: 1 | removed: 1
2024-07-04 10:02:21,583 25 INFO odoo odoo.models.unlink: User #15 deleted calendar.event records with IDs: [1999701]
2024-07-04 10:02:21,586 25 INFO odoo odoo.models.unlink: User #15 deleted mail.followers records with IDs: [3665655, 3665656, 3665657, 3665658, 3665659, 3665660, 3665661, 3665662, 3665768]
2024-07-04 10:02:21,919 25 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(15,)] Calendar Synchro - Exception : Record does not exist or has been deleted.
(Record: calendar.event(1999701,), User: 15) !
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 997, in get
cache_value = field_cache[record._ids[0]]
KeyError: 1999701
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1161, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/[api.py](https://api.py/)", line 1004, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.event(1999701,).write_date'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/[res_users.py](https://res_users.py/)", line 79, in _sync_google_calendar
synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/opt/odoo/auto/addons/google_calendar/models/[google_sync.py](https://google_sync.py/)", line 181, in _sync_google2odoo
odoo_record_write_date = write_dates.get([odoo_record.id](https://odoo_record.id/), odoo_record.write_date)
File "/opt/odoo/custom/src/odoo/odoo/[fields.py](https://fields.py/)", line 1191, in __get__
raise MissingError("\n".join([
odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: calendar.event(1999701,), User: 15)
```
</details>
In such case, due to the way this was handled, Odoo would die with `MissingError`.
Here I contribute a test for such scenario and the fix.
@moduon MT-6287
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#172103Steps to reproduce: - Go to Shop page on website - Enable edit mode - Pick a product and create a new Badge/Ribbon - Change the background color - Bug -> the bg-color is not set. Issue : ribbon bg-color is not set on the product. Cause : The !important attribute has been duplicated in the CSS rule since [1] and [2]. As a result, the background colour CSS rule for the ribbon is broken due to having !important twice. [1]: https://github.com/odoo/odoo/commit/c6f4929f65b899736c556f
Original PR description
Steps to reproduce: - Go to Shop page on website - Enable edit mode - Pick a product and create a new Badge/Ribbon - Change the background color - Bug -> the bg-color is not set. Issue : ribbon bg-color is not set on the product. Cause : The !important attribute has been duplicated in the CSS rule since [1] and [2]. As a result, the background colour CSS rule for the ribbon is broken due to having !important twice. [1]: https://github.com/odoo/odoo/commit/c6f4929f65b899736c556f8f0bb7824883a6d893 [2]: https://github.com/odoo/odoo/commit/9ee115b58342b3e0dbc11081e7ff752c10f8bfa9 fix : After removing the '!important' attribute from the create and write methods, we only encounter the '!important' attribute once. As a result, the ribbon background color is applied to the product. opw-3964071 Forward-Port-Of: odoo/odoo#172431 Forward-Port-Of: odoo/odoo#168265
Issue: In edit mode, the "on click" dropdown remains open even after clicking outside of the dropdown. With this pull request [1], we manually handle the dropdown to keep it open when clicking a dropdown item, but it prevents the dropdown from closing when clicking outside of the menu. Before this commit, we only handled the on-page click event for the HoverableDropdown [2], but not for the clickable dropdown. To maintain the same behavior for both clickable and hoverable dropdowns, this
Original PR description
Issue: In edit mode, the "on click" dropdown remains open even after clicking outside of the dropdown. With this pull request [1], we manually handle the dropdown to keep it open when clicking a dropdown item, but it prevents the dropdown from closing when clicking outside of the menu. Before this commit, we only handled the on-page click event for the HoverableDropdown [2], but not for the clickable dropdown. To maintain the same behavior for both clickable and hoverable dropdowns, this commit binds the onPageClick event once we entered in edit mode. [1]: https://github.com/odoo/odoo/commit/fe67b34f1a03d838df82a1307cf6467f994a8f3b [2]: https://github.com/odoo/odoo/commit/455e03c743d6f1db70fab4e82b2fdbc963bc22ef task-3370847 Forward-Port-Of: odoo/odoo#172677 Forward-Port-Of: odoo/odoo#127529
Open Bank Journal settings In 'Outgoing Payments' tab add a payment method entry: - Type: Manual - Name: [TEST] - Outstanding Payment Account: [ACCOUNT] Create an expense paid by company Create the report, select as payment method [TEST] Approve the expense and post journal entry Check the created payment Issue: Payment line is not using [ACCOUNT], but the account of the first outgoing payment line found in the Bank Journal opw-4015780 Forward-Port-Of: odoo/odoo#171892
Original PR description
Open Bank Journal settings In 'Outgoing Payments' tab add a payment method entry: - Type: Manual - Name: [TEST] - Outstanding Payment Account: [ACCOUNT] Create an expense paid by company Create the report, select as payment method [TEST] Approve the expense and post journal entry Check the created payment Issue: Payment line is not using [ACCOUNT], but the account of the first outgoing payment line found in the Bank Journal opw-4015780 Forward-Port-Of: odoo/odoo#171892
A recent fix forbade the usage of partners from other companies on a SO (see 7be39d0b2157ec53e84c730a210868e4a4a1f8d9, and the comment on the original PR). On the ecommerce, in some advanced multi-company & multi-website configuration, this led some customers to be unable to create a cart (add products to it), because their partner was restricted to another company. It was previously possible, but led to other issues later on, e.g. during the post-processing of payment transactions linked
Original PR description
A recent fix forbade the usage of partners from other companies on a SO (see 7be39d0b2157ec53e84c730a210868e4a4a1f8d9, and the comment on the original PR). On the ecommerce, in some advanced…
A recent fix forbade the usage of partners from other companies on a SO (see 7be39d0b2157ec53e84c730a210868e4a4a1f8d9, and the comment on the original PR). On the ecommerce, in some advanced multi-company & multi-website configuration, this led some customers to be unable to create a cart (add products to it), because their partner was restricted to another company. It was previously possible, but led to other issues later on, e.g. during the post-processing of payment transactions linked to the cart. Therefore, we consider it's still better to show a warning early on, but we prefer to replace the standard multi-company warning by a dedicated error message recommending the customer to have another account, or to contact the website administrator. To solve the issue for a given customer, either he should have a separate account for the given company, or no company (ID) should be set on its partner record, so that it's shared between companies. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172505 Forward-Port-Of: odoo/odoo#172101
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.
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-5588106710
Forward-Port-Of: odoo/odoo#172608Currently the condition on `self.product_id or not self.account_id` is inside the lambda passed to `_conditional_add_to_compute`. `_conditional_add_to_compute` calls the lambda in a filtered so this condition will be evaluated for all the lines in self. As it only depends on self, i.e. not the current line, we can move it outside of the implicit for-loop. #### speedup Customer database. Calling `_inverse_product_id` increasing the cardinality of self. | self size | Before PR | After PR
Original PR description
Currently the condition on `self.product_id or not self.account_id` is inside the lambda passed to `_conditional_add_to_compute`. `_conditional_add_to_compute` calls the lambda in a filtered so this condition will be evaluated for all the lines in self. As it only depends on self, i.e. not the current line, we can move it outside of the implicit for-loop. #### speedup Customer database. Calling `_inverse_product_id` increasing the cardinality of self. | self size | Before PR | After PR | |:----------:|:---------------:|:-----------:| | 10 | 5ms | 5ms | | 100 | 14ms | 11ms | | 1000 | 271ms | 36ms | | 10000 | 28.7s | 300ms | | 50000 | 16min | 1.5s | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170934
Current behavior: --- When printing a Lot/Serial Number, if the product name is too long, the content overlaps. Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/95880f4
Original PR description
Current behavior: --- When printing a Lot/Serial Number, if the product name is too long, the content overlaps. Steps to reproduce: --- 1. Go to Inventory > Products > Lots/Serial Numbers 2. Open one Serial Number > open its product 3. Rename product with long name 4. Go back to Lots/Serial Numbers 5. Select the Serial Number with renamed product 6. Click on Print > PDF 7. Barcode is out of the box Cause of the issue: --- Caused by: https://github.com/odoo/odoo/commit/95880f43c59c061f2a971ba8f41f9912139b798a div was changed to span without changing the css opw-3819349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159137
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#172894 Forward-Port-Of: o
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#172894 Forward-Port-Of: odoo/odoo#171614
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from visitor's perspective. The reason for shadow DOM is to use exactly same style and behaviour of livechat like in Discuss as internal users. The shadow DOM has to sustain its good working by itself, so it also needs to deploy some required main components like overlay container. In website, there's also
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from…
Follow-up of https://github.com/odoo/odoo/pull/154349 PR above allowed to define shadow DOM-specific overlays, which is desirable for apps that need to work in a shadow DOM like livechat from visitor's perspective. The reason for shadow DOM is to use exactly same style and behaviour of livechat like in Discuss as internal users. The shadow DOM has to sustain its good working by itself, so it also needs to deploy some required main components like overlay container. In website, there's also an overlay container, and since they share the same stateful service (overlay_service), we do not want to display the overlay twice. So PR above solved the issue by allowing to make overlay with a provided `rootId`, which when set it contains the `id` attribute of the root node of the overlay that has to manage the overlay. This allows to clearly determine which overlay container is responsible to display the appropriate overlay. Code above was however buggy: it relies on `isVisible(overlay)`, whose computation requires `rootRef.el`. Refs' el are not determined on the 1st rendering of the overlay service. This is not a problem when the overlay container is 1st mounted without any overlay, but if it's being registered with some overlays, mounting the overlay container afterwards results in the non-showing of the overlay. The `rootRef` is important to find out the "global" root node id, i.e. the shadow DOM root id. This commit fixes the issue by rendering again overlay container after mount when there are some pre-registered overlays. Forward-Port-Of: odoo/odoo#169264
**Issue** From v17.2, the website_slides tour is not working because of some changes in the tour library. Commit from where I think the bug is coming https://github.com/odoo/odoo/commit/b334055c82c4350b4122e620ae76179a9fc4eaa2 and later due to the website design change another step was also failing and that should be coming this commit https://github.com/odoo/odoo/commit/80e3f53550b7ed74ac18bb09ea542c9e77c9a61d **Technical** The "Add to content" is loading before our frame is ready due t
Original PR description
**Issue** From v17.2, the website_slides tour is not working because of some changes in the tour library. Commit from where I think the bug is coming https://github.com/odoo/odoo/commit/b334055c82c4350b4122e620ae76179a9fc4eaa2 and later due to the website design change another step was also failing and that should be coming this commit https://github.com/odoo/odoo/commit/80e3f53550b7ed74ac18bb09ea542c9e77c9a61d **Technical** The "Add to content" is loading before our frame is ready due to this the position of the pointer was wrong. Due to the design change tour was not able to point the publish btn **After this PR** Now the tour is working properly. Task-3960962 Forward-Port-Of: odoo/odoo#168182
Steps to reproduce the bug: - Create a storable product P1 with BoM: - Component: Add any component - operation: OP1 - Create a MO with P1: - Confirm it - Start the workorder and mark it as done - Come back to the dashboard > workorders list - Select the finished workorder - Try to start it Problem: The work order can be started while it is in the 'done' state. When the function `button_start` is called, we will check if we need to skip the employee check or n
Original PR description
Steps to reproduce the bug: - Create a storable product P1 with BoM: - Component: Add any component - operation: OP1 - Create a MO with P1: - Confirm it - Start the workorder and mark it as done -…
Steps to reproduce the bug:
- Create a storable product P1 with BoM:
- Component: Add any component
- operation: OP1
- Create a MO with P1:
- Confirm it
- Start the workorder and mark it as done
- Come back to the dashboard > workorders list
- Select the finished workorder
- Try to start it
Problem:
The work order can be started while it is in the 'done' state.
When the function `button_start` is called, we will check if we need to
skip the employee check or not. However, since the current user is also
an employee, we will use them:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L258-L259
The function start_employee will then be called:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L284-L286
The state of the work order will then be updated:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L740"
opw-[4024904](https://www.odoo.com/web#id=4024904&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#172587Steps to reproduce: ------------------- - Install `Task Logs` module - Go to `Timesheets` - Create a timesheet line in the project `Research & Development` and give a description (but set no task) - Go to `Project` and open `Research & Development` project settings - Click on `Actions` button and select `Timesheets` to download report - Open the downloaded report Issue: ------ The `Task` column contains the `Description` of the timesheet, and the `Hours` value is in the `Descript
Original PR description
Steps to reproduce: ------------------- - Install `Task Logs` module - Go to `Timesheets` - Create a timesheet line in the project `Research & Development` and give a description (but set no task) - Go to `Project` and open `Research & Development` project settings - Click on `Actions` button and select `Timesheets` to download report - Open the downloaded report Issue: ------ The `Task` column contains the `Description` of the timesheet, and the `Hours` value is in the `Description` column. Cause: ------ If the timesheet line has no task and generating report only for one project, the cell value will not be created for the timesheet line. Solution: --------- If the column `Task` (or `Project`) exist, create the cell anyway. opw-3984479 Forward-Port-Of: odoo/odoo#172382
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#172834 Forward-Port-Of: odoo/odoo#172756
In This PR: - Set Place of Supply on 'general' journals with POS sessions if the country is India and Place of Supply is not set. - Adjusted state ID computation for account moves with POS sessions. Task Id: 3935317 Forward-Port-Of: odoo/odoo#172377
Original PR description
In This PR: - Set Place of Supply on 'general' journals with POS sessions if the country is India and Place of Supply is not set. - Adjusted state ID computation for account moves with POS sessions. Task Id: 3935317 Forward-Port-Of: odoo/odoo#172377
Description On a 'stock.move' with a lot of move lines (serial numbers), setting the 'stock.move' quantity to 0 could take a few minutes due to the number of unlink calls. Solution: Extract unlink call outside the "for" loop. | Move Lines | Without Fix | With Fix | | --- | --- | ---| | 10 | 321 ms | 102 ms | | 100 | 2.60 s | 108 ms | | 1.000 | 31.71 s | 380 ms | | 10.000 | 20.7 min | 1.41 s | | 100.000 | no idea | 17.47 | --- OPW-4043076 --- I confirm I have signed
Original PR description
Description On a 'stock.move' with a lot of move lines (serial numbers), setting the 'stock.move' quantity to 0 could take a few minutes due to the number of unlink calls. Solution: Extract unlink call outside the "for" loop. | Move Lines | Without Fix | With Fix | | --- | --- | ---| | 10 | 321 ms | 102 ms | | 100 | 2.60 s | 108 ms | | 1.000 | 31.71 s | 380 ms | | 10.000 | 20.7 min | 1.41 s | | 100.000 | no idea | 17.47 | --- OPW-4043076 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172750
To reproduce the bug: - Go to website(eCommerce) - Click on the Shop tab. - Once you are in the store tab, click on the 'Edit' option to edit the website and select Categories: Left and Collapse Categories: enable. - Go to the theme, in the light and dark themes select a darker version like black or gray for the first option. - The drop down appears for categories which are not selected but when selected the up arrow disappears. This problem was due to the superposition of the .accordion
Original PR description
To reproduce the bug: - Go to website(eCommerce) - Click on the Shop tab. - Once you are in the store tab, click on the 'Edit' option to edit the website and select Categories: Left and Collapse Categories: enable. - Go to the theme, in the light and dark themes select a darker version like black or gray for the first option. - The drop down appears for categories which are not selected but when selected the up arrow disappears. This problem was due to the superposition of the .accordion-button and .bg-transparent CSS classes. When the accordion button is clicked, it switches its body and background colors, changing the body color from black to white. However, since the background becomes black, we can still see the button. The issue arises when the background is transparent; in this case, the button becomes invisible. opw-4009051 Forward-Port-Of: odoo/odoo#171009
Before this commit, there was a (xss specific) form view rule preventing the oe_title content to be displayed properly. In the task form view, in mobile, the title is a textarea, and long titles were displayed with words cut in the middle. The removed rule had been introduced a long time ago, for the kanban quick create form view [1], but it was probably a mistake. [1] https://github.com/odoo/odoo/commit/d18d08f01a589053e40c7af1fd4dd59c13aaa625 Task 4045168 Description of the issue/feat
Original PR description
Before this commit, there was a (xss specific) form view rule preventing the oe_title content to be displayed properly. In the task form view, in mobile, the title is a textarea, and long titles were displayed with words cut in the middle. The removed rule had been introduced a long time ago, for the kanban quick create form view [1], but it was probably a mistake. [1] https://github.com/odoo/odoo/commit/d18d08f01a589053e40c7af1fd4dd59c13aaa625 Task 4045168 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172898
Impacted Version: - 15.0 and above This commit improve below features: - Update singapore default taxes opw-3679292 Forward-Port-Of: odoo/odoo#172704
Original PR description
Impacted Version: - 15.0 and above This commit improve below features: - Update singapore default taxes opw-3679292 Forward-Port-Of: odoo/odoo#172704
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#66394 Forward-Port-Of: odoo/enterprise#64670
Original PR description
Before this commit, when dragging documents including one or more locked documents to another workspace, only the unlocked documents are effectiveley moved and no message were shown to alert the user although the code exists but is never triggered. This commit, fix this by displaying the notification alerting the user that the locked files haven't been moved. Task-3992114 Forward-Port-Of: odoo/enterprise#66394 Forward-Port-Of: odoo/enterprise#64670
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in t
Original PR description
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are…
Issue: =============== When a manufacturing order (MO) is created, the default components are automatically reserved and are made visible in the barcode module. However, even if these components are later unreserved, they will continue to be displayed in the barcode module. Resolution: ================ To address this issue, we've taken the step to avoid forcefully re-reserving the components when a component is unreserved. This resolves the persistent display of components in the barcode. Steps to Reproduce: ====================== 1. Create a manufacturing order (MO) and confirm it. 2. Navigate to the barcode module within the manufacturing order. 3. By default, the components are reserved, so they are visible in the barcode module. 4. Go to the form view of the MO in MRP and unreserve the components. 5. Check the barcode module again, and notice that the unreserved components are still visible. Expected Result: ================== After implementing the solution, When we opens the MO in the barcode module only reserved components should be visible. When a component is unreserved, it should no longer be visible in the barcode module for manufacturing order. task-3869731 Forward-Port-Of: odoo/enterprise#63953 Forward-Port-Of: odoo/enterprise#61827
In this commit, we test the feature implemented in this PR: https://github.com/odoo/enterprise/pull/50383 task-3874263 Forward-Port-Of: odoo/enterprise#66070 Forward-Port-Of: odoo/enterprise#61329
Original PR description
In this commit, we test the feature implemented in this PR: https://github.com/odoo/enterprise/pull/50383 task-3874263 Forward-Port-Of: odoo/enterprise#66070 Forward-Port-Of: odoo/enterprise#61329
When opening a message thread on cells, the request fetching the messages is not properly awaited. We didn't find any actual issue with this (in prod or in tests), but this is the kind of things leading to non-deterministic tests. So we prefer to fix it. Forward-Port-Of: odoo/enterprise#66559
Original PR description
When opening a message thread on cells, the request fetching the messages is not properly awaited. We didn't find any actual issue with this (in prod or in tests), but this is the kind of things leading to non-deterministic tests. So we prefer to fix it. Forward-Port-Of: odoo/enterprise#66559
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Component: Add any component - operation: OP1 - Create a MO with P1: - Confirm it - Start the workorder and mark it as done - Come back to the dashboard > workorders list - Select the finished workorder - Try to start it **Problem:** The work order can be started while it is in the 'done' state. When the function `button_start` is called, we will check if we need to skip the employee ch
Original PR description
**Steps to reproduce the bug:** - Create a storable product P1 with BoM: - Component: Add any component - operation: OP1 - Create a MO with P1: - Confirm it - Start the workorder and mark it as done…
**Steps to reproduce the bug:**
- Create a storable product P1 with BoM:
- Component: Add any component
- operation: OP1
- Create a MO with P1:
- Confirm it
- Start the workorder and mark it as done
- Come back to the dashboard > workorders list
- Select the finished workorder
- Try to start it
**Problem:**
The work order can be started while it is in the 'done' state.
When the function `button_start` is called, we will check if we need to
skip the employee check or not. However, since the current user is also
an employee, we will use them:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L258-L259
The function start_employee will then be called:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L284-L286
The state of the work order will then be updated:
https://github.com/odoo/enterprise/blob/c4604d8b398713898b014e6073219d6202c154c3/mrp_workorder/models/mrp_workorder.py#L740"
opw-4024904
Forward-Port-Of: odoo/enterprise#66358task-4004305 Forward-Port-Of: odoo/enterprise#65167
Original PR description
task-4004305 Forward-Port-Of: odoo/enterprise#65167
Updated description when connecting new IoT Box to db, added help buttons redirecting to Odoo documentation. Task: 4021957 Forward-Port-Of: odoo/enterprise#66298
Original PR description
Updated description when connecting new IoT Box to db, added help buttons redirecting to Odoo documentation. Task: 4021957 Forward-Port-Of: odoo/enterprise#66298
In this PR: Steps to reproduce: 1. Create a POS session. 2. Make two orders: one with an invoice and one without. Close the session. 3. Create another session, make an order, and create an invoice for an order from the previous session. Close the session. 4. Create a GST return period and generate the GSTR-1 spreadsheet. Changes made: - Fixed the retrieval of POS line details by move ID. - Added a safe access method using get to prevent key errors during HSN summary generation. Ta
Original PR description
In this PR: Steps to reproduce: 1. Create a POS session. 2. Make two orders: one with an invoice and one without. Close the session. 3. Create another session, make an order, and create an invoice for an order from the previous session. Close the session. 4. Create a GST return period and generate the GSTR-1 spreadsheet. Changes made: - Fixed the retrieval of POS line details by move ID. - Added a safe access method using get to prevent key errors during HSN summary generation. Task ID: 3935317 Forward-Port-Of: odoo/enterprise#66311
**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#65860
Forward-Port-Of: odoo/enterprise#64318