Thursday, December 5, 2024
33 changes · 18.0
Enhancements to existing features
The web tour recorder now saves the current recording progress in the browser so users can continue after refreshing the page. This reduces lost work when creating or editing guided tours and makes the recording experience more reliable.
Original PR description
Wrapper around localStorage for persistence of the current recording. Useful for resuming recording when the page refreshed. TASK-ID: 4378081 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale sessions now include an indicator when they are connected to an Italian company. This helps related localization features apply the right Italian compliance behavior without requiring users to manually identify the company context.
Original PR description
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/enterprise/pull/75147
The Point of Sale now records when a session belongs to an Italian company. This helps Italian localization rules apply only where relevant, reducing unnecessary checks and supporting more reliable compliance behavior.
Original PR description
added a session key to indicate if the current session is connected to an Italian company. Related: https://github.com/odoo/odoo/pull/189610
Resolved issues and error corrections
The chat window’s conversation name and avatar are now easier to click because a small unresponsive area beside them was removed. This keeps the same visual spacing while making the more-actions interaction feel more reliable for users.
Original PR description
When mouse-hovering more actions (the conversation name & avatar), the clickable zone had a small dead zone on the left. This comes from `mx-1`, which put good spacing but had the unintentional deadzone spacing. This commit replaces the `mx-1` by equivalent extra padding, thus removing the deadzone while keeping the overall same spacing. Before / After <img width="391" alt="Screenshot 2024-12-04 at 16 50 52" src="https://github.com/user-attachments/assets/323d8ece-2965-49c3-acc6-d2e4590c1fb2"> <img width="390" alt="Screenshot 2024-12-04 at 16 50 38" src="https://github.com/user-attachments/assets/97ba506d-8fa4-4825-957a-5f22be9910fe"> Difference (red) <img width="1911" alt="Screenshot 2024-12-05 at 12 44 00" src="https://github.com/user-attachments/assets/aa7c9079-f2b4-467d-8e1f-58f2ce9b8da1">
Miscellaneous changes
Commit [1] allowed to pass the env to overlays, as a prop. However, when doing so, the env was inserted in a reactive array (`overlays`) which thus made it reactive as well. That reactive env was then used as childEnv for the overlay items. Having a reactive env isn't a good idea, relying on this isn't either. Indeed, changes in the "non reactive" env wouldn't be taken into account. Moreover, it can lead to unexpected excessive re-renderings, or even to crashes (a reactive object is a proxy,
Original PR description
Commit [1] allowed to pass the env to overlays, as a prop. However, when doing so, the env was inserted in a reactive array (`overlays`) which thus made it reactive as well. That reactive env was then used as childEnv for the overlay items. Having a reactive env isn't a good idea, relying on this isn't either. Indeed, changes in the "non reactive" env wouldn't be taken into account. Moreover, it can lead to unexpected excessive re-renderings, or even to crashes (a reactive object is a proxy, and for instance, calling `difference` on a Set wrapped in a proxy crashes). [1] odoo/odoo@7851d85f26c525a90fdb1131c5e4d51a6b140c13 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#189764
Opening a shared project task no longer automatically focuses the chatter area. This prevents unwanted scrolling, especially on mobile, so portal users land on the task details as expected.
Original PR description
… sharing The objective is to remove the focus on the chatter whenever a task is opened in project sharing. This aimed initially to avoid the automatic scroll to the bottom in mobile view. As a note: the Chatter component in project_sharing refers to the mail/chatter, however as project module also includes the portal/static/src/chatter/core/chatter_patch.js, Chatter template in project is overrided leading to autofocus triggering. To replicate: 1. Share a project with tasks to a user with Edit permission. 2. login with portal user and open the project portal view 3. Open a task. The focus should no longer be set on the Chatter automatically. 3-b. Also on Mobile, when opening a task the sreen should not scroll to the chatter. task: 4353290 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Messages that are not grouped together now show both the day and time, such as "Today at 10:00" or "Yesterday at 08:00". This makes busy conversations easier to follow when many messages were posted on the same day.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/188665 PR above changed "X days ago" on messages by time, so that the exact time can be viewed without requiring mouse-hovering. Indeed, after some…
Follow-up of https://github.com/odoo/odoo/pull/188665 PR above changed "X days ago" on messages by time, so that the exact time can be viewed without requiring mouse-hovering. Indeed, after some time, the rounding of the relative time tend to show relative day when message was posted but the datetime was lacking. However, by only showing time, when many messages are posted the same day, this becomes unclear to know the day the messages were posted, as the date sections do not have any sticky behaviour on viewport. Putting sticky behaviour on date section require more style change, which may probably be reserved for future improvements. This commit fixes the issue by showing the date of non-squashed messages, e.g. "Today at 10:00", "Yesterday at 08:00", "Dec 2 at 20:00", etc. Before / After <img width="194" alt="Screenshot 2024-12-05 at 11 42 33" src="https://github.com/user-attachments/assets/1c9cd1c9-d8d8-4700-88d1-2dba239c87c4"> <img width="265" alt="Screenshot 2024-12-05 at 11 42 18" src="https://github.com/user-attachments/assets/359a308c-a380-49af-986f-ab13839f013b">
The livechat window buttons now adapt their hover color to the customized chat header color instead of using a fixed white or dark style. This keeps actions visible and easier to use across default, white, dark, and customized livechat themes.
Original PR description
Chat window action mouse hover effect was hardcoded for white and dark theme. In livechat, the header color can be customised. With the default colors (purple background and white text), the hover…
Chat window action mouse hover effect was hardcoded for white and dark theme. In livechat, the header color can be customised. With the default colors (purple background and white text), the hover effect had white background, which made the action not visible. This commit fixes the issue by using a slight color invert when mouse hovering the action of a chat window, so that the color is slightly different from header color while keeping icon color distinguishable. Before / After <img width="390" alt="Screenshot 2024-12-04 at 17 10 23" src="https://github.com/user-attachments/assets/f4993b05-5f69-4de6-8423-fc69f7b2bdd7"> <img width="393" alt="Screenshot 2024-12-04 at 17 09 37" src="https://github.com/user-attachments/assets/1c867d1a-8df8-46e3-ae04-e68154e169a5"> White and dark theme are more catchy as a result: Before / After (white theme) <img width="394" alt="Screenshot 2024-12-04 at 17 11 16" src="https://github.com/user-attachments/assets/e29578ca-8b15-45d9-828a-aa65b43a6b23"> <img width="384" alt="Screenshot 2024-12-04 at 17 11 40" src="https://github.com/user-attachments/assets/025b2145-b783-4ab0-bf94-44fe24d32d81"> Before / After (dark theme) <img width="389" alt="Screenshot 2024-12-04 at 17 11 05" src="https://github.com/user-attachments/assets/be50f34d-7468-415b-b365-734fed3e9001"> <img width="387" alt="Screenshot 2024-12-04 at 17 11 59" src="https://github.com/user-attachments/assets/8a0a8c09-c179-4e1e-befe-0fcdff3a181c">
The automated tour for Knowledge article commands has been updated to work with the current editor behavior. This helps ensure the Knowledge app remains properly tested and reduces the risk of unnoticed issues reaching users.
Original PR description
In this commit, we fix knowledge_article_commands_tour by adapting the steps that concern the odoo editor in order to reactivate this tour.
This fix ensures key document-related automation is restored correctly when upgrading to version 18.0 if customers previously removed related document tags. It also prevents those restored records from being recreated again on later updates, reducing unexpected changes after the upgrade.
Original PR description
server actions that use document tag should be noupdate as well because document tag records are noupdate, and they could be deleted by clients. possible steps to reproduce: 1) make a database 17.0 2) delete document tags 3) upgrade the database to 18.0 Document tags and server actions should be recreated in upgrade scripts when upgrading to 18.0 if they are missing. Setting the noupdate=1, makes sure that they are not recreated on subsequent updates or upgrades after reaching 18.0. odoo/upgrade#6803
The Documents app now correctly copies shareable links when users select files from the list view. This prevents blank or missing links, making it easier for users to share documents reliably.
Original PR description
In list view, the "Copy links" [action](https://github.com/odoo/enterprise/blob/0c2b8ab5c0675485a8dbde3371e347f43250a66e/documents/static/src/views/search/documents_control_panel.xml#L42) was returning empty string (or undefined), since we haven't added the field `access_url` to the list view, so accessing it on the `record.data` [from JS](https://github.com/odoo/enterprise/blob/7a65d1e776ea486538cfc9762cb482fd71bf9dc1/documents/static/src/views/search/documents_control_panel.js#L262) returned `undefined`. Now, we add `access_url` field as a hidden field in the list view. opw-4309365
This fix ensures projects linked to shared documents are visible to portal users when needed. It keeps document access working as expected after related access rules changed, preventing failures for external users or automated checks.
Original PR description
Before this commit, the test fails due to the changes made in community to avoid having an access token if the project visibility is private. This commit makes sure the project visibility is `portal` to be able to set an access token as before. opw-4104804 task-4354145
The document deletion test tour has been adjusted to avoid timing-related failures caused by an error dialog appearing during automated checks. This helps keep validation runs more stable and faster, reducing false alarms for teams relying on test results.
Original PR description
In this commit, we fix the tour documents_delete_tours in which there is an error message that said: " Record does not exist or has been deleted. " As there is a modal in DOM, the next step could not be passed (depends on time the modal appears).
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/odoo#189198
Forward-Port-Of: odoo/odoo#188854Since odoo/odoo#171869, for inbox notification, we check if the mentioned partners have a valid uid, which makes sense. But the query to get recipients in `discuss.channel` doesn't take the `uid` into account, and this leads to not getting an inbox notification when mentioning a partner in a channel. This commit fixes that by including the uid in the recipients computation for channels. Steps to reproduce: - Set the first user's notification settings, e.g. admin, to `Handle in Odoo` - Logi
Original PR description
Since odoo/odoo#171869, for inbox notification, we check if the mentioned partners have a valid uid, which makes sense. But the query to get recipients in `discuss.channel` doesn't take the `uid` into account, and this leads to not getting an inbox notification when mentioning a partner in a channel. This commit fixes that by including the uid in the recipients computation for channels. Steps to reproduce: - Set the first user's notification settings, e.g. admin, to `Handle in Odoo` - Login as another user (e.g. demo) and send a message with mentioning the first user - The message will not appear in the first user's inbox until the page is refreshed Forward-Port-Of: odoo/odoo#189484
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "
Original PR description
Since commit [1], a new option was added to set the text color of the navbar in "over the content" mode. However, this option also affects the text color of the "mobile navbar", which it should not. This commit fixes the issue by stopping the "over the content" text color from applying to the mobile navbar. Steps to reproduce: - Enter "Website" edit mode. - Click on the "header". - Set the "Header Position" option to "Over The Content". - Select a "red" color in the colorpicker of the "Navbar" option. - Click the "Mobile Preview" button. - Click the "Hamburger menu" button to open the mobile navbar. - Bug: The text color is not "red". [1]: https://github.com/odoo/odoo/commit/1e30600d9e0e12e43fcbca60760a64f2551e3c8f opw-4364765 Forward-Port-Of: odoo/odoo#189417
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the homepage. Enterprise PR: [https://github.com/odoo/enterprise/pull/75074](https://github.com/odoo/enterprise/pull/75074) Task: 4345731 Forward-Port-Of: odoo/odoo#189644 Forward-Port-Of: odoo/odoo#189467
Steps to Reproduce - Go to Surveys - Select a survey > Options Tab > Check the "Require Login" box - Save > Share the survey > Check the "Send by Email" box > Select any partner > "Send" - Go to Settings > Technical > Emails - Open the Email sent to the selected partner in step 3 - Try to open the link in an incognito browser instance (Not logged in) Current behaviour: Visiting the Survey Invite link throws "500: Internal Server Error" to the user. Expected behaviour: Redirect to t
Original PR description
Steps to Reproduce - Go to Surveys - Select a survey > Options Tab > Check the "Require Login" box - Save > Share the survey > Check the "Send by Email" box > Select any partner > "Send" - Go to Settings > Technical > Emails - Open the Email sent to the selected partner in step 3 - Try to open the link in an incognito browser instance (Not logged in) Current behaviour: Visiting the Survey Invite link throws "500: Internal Server Error" to the user. Expected behaviour: Redirect to the login page. Cause: The signature of `signup_prepare` changed in 94b969b035da3d4200, but `survey` code was not adapted. Fixes #189332 Forward-Port-Of: odoo/odoo#189381
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneo
Original PR description
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure…
Before this commit, when an error happens on a serial device, the serial driver on the IoT box permanently sets its status to ERROR. This in turn leads to the user-facing app returning a failure status back to the user, even for sucessful subsequent operations. This is particularly problematic, for example in the special case of BlackBox BE, where some points of sales have multiple checkouts using the same POS session and the same IoT Box + BlackBox. If at any point, a cashier sent an erroneous message to the IoT Box or to the Blackbox, all checkouts would become blocked, with the only alternative being to reload the handlers or restart the IoT Box. Furthermore, the subsequent actions appearing as refused may have executed successfully. Which means there would be a mismatch between the data stored in Odoo (multiple failed transactions) and the data sent to the SPF (one failed transaction, then many successful ones). After this commit, the driver status is reset after being sent once. That way, when a new action is sent from the client to the IoT box, it's the status of the execution of this action and not the previous one that gets sent back to the client. opw-4313538 opw-4182434 opw-4293988 Forward-Port-Of: odoo/odoo#189506 Forward-Port-Of: odoo/odoo#186735
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException> Traceback (most recent call last): File "concurrent/futures/_base.py", line 340, in _invoke_callbacks callback(self) File "odoo/odoo/tests/common.py", line 1532, in handler
Original PR description
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of concurrent.futures: exception calling…
Currently, if trying to take a screenshot results in an error the reporting is iffy: we end up with an uninformative and unexpected traceback along the lines of
concurrent.futures: exception calling callback for <Future at 0x7f212c073110 state=finished raised ChromeBrowserException>
Traceback (most recent call last):
File "concurrent/futures/_base.py", line 340, in _invoke_callbacks
callback(self)
File "odoo/odoo/tests/common.py", line 1532, in handler
base_png = f.result(timeout=0)['data']
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 449, in result
return self.__get_result()
^^^^^^^^^^^^^^^^^^^
File "concurrent/futures/_base.py", line 401, in __get_result
raise self._exception
odoo.tests.common.ChromeBrowserException: Internal error
As this is mostly unhelpful, handle the thing better, and lower the concern to `RUNBOT`: giving prominence to the screenshot failure is probably less relevant than the actual reason why we tried to take a screenshot in the first place?
Forward-Port-Of: odoo/odoo#189585Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have sig
Original PR description
Before this commit: - The `::before` pseudo-element had `width: -webkit-fill-available` and `width: -moz-available`, causing it to span the entire width of its container. - Its `z-index: 100` made it overlap with other elements, preventing interaction with underlying elements. After this commit: - `pointer-events: none` was applied to the pseudo-element. - This allows interactions with underlying elements while retaining the visual styling. task-4313526 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187915
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/
Original PR description
In commit [1], we introduced a "data-forced-size" attribute on "image shapes" SVGs to adjust SVGs height to ensure the image fits properly within it (e.g. for "devices" shapes). However, the "image_shape" route was not updated to match this change, preventing the use of predefined building blocks containing an image shape with a "forced-size" attribute. This commit updates the "image_shape" route to support the "data-forced-size" attribute. [1]: https://github.com/odoo/odoo/commit/63cf8a693a5262600d465d70f0383229464d71e7 task-4094393 Forward-Port-Of: odoo/odoo#189156
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when impo
Original PR description
In odoo#130825, we prevented the import of records that are given an XMLid that belongs to an Odoo module, because such records would be unlinked when the module is updated. However, if the XMLid has noupdate set to True, then the record will not get unlinked anyway when the module is updated, so we should not block it from being creataed. This is useful because there are cases where during an import, `_load_records` is called again by the business code. For example, in 17.0+, when importing a chart of accounts on a new company, the import of the opening balances causes a new 'Unaffected Earnings' account to be created via `_load_records`, with `noupdate=True`.[^1] [^1]: https://github.com/odoo/odoo/blob/a73e45ff9459ffdc0128327fac47962c6fe27af7/addons/account/models/company.py#L473 task-none runbot-108001 Forward-Port-Of: odoo/odoo#189449 Forward-Port-Of: odoo/odoo#185030
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be
Original PR description
Previously, it was still possible to access a project with an access_token even if that project is no longer in privacy="portal". This was not consistant with the front-end that disable the access to the portal share wizard when privacy is set to anything else than 'portal'. This change remove the token when the privacy is changed at the time of the write() This change is done in the project module because it depends on "portal", and not the other way around. This change can also be used as an invalidation mecanism in case of a token leak. Changing the privacy to 'private' then to 'portal' will allow for an invalidation of the previous token and the creation of new one. opw-4104804 task-4354145 Closes #176177 Forward-Port-Of: odoo/odoo#189314 Forward-Port-Of: odoo/odoo#188264
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop a form inside the existing form. - Save the changes. - Re-enter edit mode. - Click on any field within the newly added form. - A traceback is triggered. HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in bro
Original PR description
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop…
Steps to reproduce: - Navigate to Website - Open the user dropdown menu and select "My Account". - On the right-hand side of the page, click on "Edit information". - Enter edit mode. - Drag and drop a form inside the existing form. - Save the changes. - Re-enter edit mode. - Click on any field within the newly added form. - A traceback is triggered. HTML5, as defined by the W3C, prohibits the use of nested \<form\> elements, as they are invalid and lead to undefined behavior in browsers. To address this, the website_form snippet has been updated to prevent it from being dropped inside another form. This fix ensures compliance with HTML5 specifications and prevents invalid document structures from being created within the website builder. Due to this commit [1], buttons were added as inline building blocks. As a result, you could insert blocks either directly before or after the button. Since this wasn't the case before, we never encountered any issues in forms, as nothing could be inserted there. [1]: https://github.com/odoo/odoo/commit/507b80a12574c opw-4305352 Forward-Port-Of: odoo/odoo#189420 Forward-Port-Of: odoo/odoo#188028
**Steps to reproduce the bug:** - Create a storable product: - "Finished Product" with the following BoM: - Component: 1 unit of "C1" - Byproducts: - 1 unit of "By-product 1" - 1 unit of "By-product 2" - Create a manufacturing order to produce 5 units of the finished product. - Confirm the MO. - Set the quantity produced to 5 units. - Set the quantity of byproducts to: - By-product 1: 4 units - By-product 2: 3 units - Validate the MO. - Print
Original PR description
**Steps to reproduce the bug:**
- Create a storable product:
- "Finished Product" with the following BoM:
- Component: 1 unit of "C1"
- Byproducts:
- 1 unit of "By-product 1"
- 1 unit of "By-product 2"
- Create a manufacturing order to produce 5 units of the finished product.
- Confirm the MO.
- Set the quantity produced to 5 units.
- Set the quantity of byproducts to:
- By-product 1: 4 units
- By-product 2: 3 units
- Validate the MO.
- Print the cost analysis.
**Problem:**
The reported quantity does not show the actual quantity produced but
instead shows the "to produce" quantity.
opw-4312292
Forward-Port-Of: odoo/enterprise#74917
Forward-Port-Of: odoo/enterprise#73666LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
Original PR description
LNE Certification (scales certification) requires not to be able to reboot the IoT Box with a simple button. We removed it from the IoT Box form view. Community PR: [https://github.com/odoo/odoo/pull/189467](https://github.com/odoo/odoo/pull/189467) Task: 4345731 Forward-Port-Of: odoo/enterprise#75161 Forward-Port-Of: odoo/enterprise#75074
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already. ======================================= [FIX] account_reports: properly handle groupby in account_co
Original PR description
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior As stated here https://www.postgresql.org/docs/current/queries-limit.html ,…
[FIX] account_reports, l10n_*_reports: add explicit ORDER BY to report engines for consistent LIMIT and OFFSET behavior
As stated here https://www.postgresql.org/docs/current/queries-limit.html , postgresql requires an explicit ORDER by within the query for LIMIT and OFFSET to work properly and consistently between query executions. We hence add one to each engine not having one already.
=======================================
[FIX] account_reports: properly handle groupby in account_codes engine for grouping keys used with multiple accounts
// TO REPRODUCE
1) Create a report with a single line, whose computation uses the account_codes engine, with formula "1". Set "partner_id" as the groupby value for that line. Setup a "load more limit" of 2 on your report.
2) Create 3 accounts, with codes 11, 12, 13
3) Create 3 partners: A, B, and C
4) Create journal entries, with the following lines (all balancing lines must use other accounts as the ones defined in 2) ), in that order:
- on account 11, with partner A, debit=10
- on account 11, with partner A, debit=20
- on account 12, with partner A, debit=25
- on account 11, without partner, debit=30
- on account 11, without partner, debit=40
- on account 12, with partner B, debit=50
- on account 13, with partner C, debit=60
5) Open the report for a period covering all the created journal entries, and have a look at the sublines generated for the groupby.
=> With the limit being 2, you'd expect to see "A", "B", and a "Load more..." line allowing to visualize the rest (namely a line for "C", and "Unknown"). Instead of that, you see no "Load more ...", and line "A"'s amount is wrong.
// EXPLANATION
The SQL query of the account_codes engine is grouping not only by groupby key (here, partner_id), but also by account_id, to be able to process the "C" and "D" suffixes of the formula later on. Because of that, the LIMIT passed by the load_more_limit is applied on that grouping.
With a load_more_limit of 2, we try to load 3 lines. If we manage to load 3, we only display 2, but know we need to display the "Load more..." line. Else, we know there are no more results, so no need for that additional line.
So, with our example, the query runs with a LIMIT of 3, returning
- 30 for A on account 11
- 25 for A on account 12
- 70 for no partner on account 11
Then, another issue happens:
The results returned by the SQL query (hence, by the engine) contain two times the same partner_id. From an engine perspective, the grouping key is only partner_id, not account_id (which is only used for an inner computation, with the SQL query). So that means the same grouping key has two different values. This is not legit, and causes one of them to shadow the other.
The report computation then receives 1 result for A, and 1 for "Unknown", so it renders them, and since there is no third result, it does not display the "Load more ...".
Forward-Port-Of: odoo/enterprise#75024
Forward-Port-Of: odoo/enterprise#74784Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to
Original PR description
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3)…
Currently, a traceback occurs when the user tries to update the planning slot but has no recurrence. To reproduce this issue: 1) Install planning 2) Open any existing Open Shift planning slot 3) Enable the `repeat` and update the start and end date 4) Give the edit value as `All shifts` and make sure the resource be empty 5) Save the record. Error:- ``` IndexError: tuple index out of range ``` Here the `resource` is not required in planning slot. So, when the user tries to update an open shift with the `repeat` enabled and `resource_update` as `all`, it leads to a traceback from the below line. https://github.com/odoo/enterprise/blob/64fc38a80520cfeeb81c0bb329c6b24c3e9454e1/planning/models/planning.py#L866-L871 This is because when there is no `recurrence_slots` in the slot, we get an empty recordset for the `recurrence_slots`, which leads to the above traceback when trying to extract a value from the recurrency_slots. We can resolve this issue by adding an extra check of `recurrence_slots` which makes the code more robust. sentry-6096445646 Forward-Port-Of: odoo/enterprise#75085 Forward-Port-Of: odoo/enterprise#74866
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |------
Original PR description
### Description When opening a report with a lot of data to display, getting some values can be very costly. In this case, for the depreciation schedule, we are retrieving the column expression and currency symbol each time if not found in `_build_column_dict`. To avoid retrieving a value that was already fetched, we can pass the currency and the expression directly. This reduces unnecessary `__get__` calls. ### Benchmark (made in 17.0) | N° of assets | Before | After | |--------------|---------|--------| | 500 | 2 s | 1.55 s | | 7k | 20 s | 19 s | | 17k | 50 s | 41 s | ### Reference opw-4287192 Forward-Port-Of: odoo/enterprise#74997 Forward-Port-Of: odoo/enterprise#74085
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will
Original PR description
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1.…
Before this commit, if the user set a database with two preparation displays, both displaying the same products and orders, duplication of the order could happen. Steps to reproduce the issue: 1. configure a pos_restaurant 2. configure 2 kitchen displays (disp1 and disp2) 3. Open the restaurant and create and order with 3-4 items (items would belong to the same category, ideally) 4. on disp1, proceed to tick/mark as done 2 items 5. on disp1, press on the header of the order -> this will split the order, sending the done items to the next stage. 6. back in the POS, create a new order (any table) 7. on disp2, you will see a wrong duplication of the order the was split at the previous step number 5 The duplication would happen even if the order (and related split) are marked as done on both disp1 and disp2. What that means in the client flow is that you could have completely processed the order at both stations, and have it reappear at one of them. In practice, since inter-station communication is not always possible, it could lead to the staff preparing the same order multiple times. This in turn would incur losses because of the wasted orders and increased delays in processing other legitimate orders. After this commit, the other preparation displays (disp2 in my example above) get notified immediately of the change and update their respective statuses to reflect the order split. opw-4367937 Forward-Port-Of: odoo/enterprise#74816
Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and co
Original PR description
Issue ===== When tracked product setting was disabled, the "Group by products" barcode setting for operation type was ignored. How to reproduce ================ - Install `stock_barcode_picking_batch`; - Ensure "Lots & Serial Numbers" is disabled, to be sure, go in Inventory > Configuration > Settings; - Now, go in Configuration > Operation Type > Receipts > Barcode App, and check "Group batch lines"; - Create a receipt for a product and confirm it; - Duplicate this receipt and confirm it aswell; - Add these two pickings in a batch and open it in the Barcode app -> You can see the lines for the same product are not grouped. Cause ===== The issue was, in the `BarcodeModel` code, we skip the method who group the lines if tracking is disabled. [task-4291149](https://www.odoo.com/odoo/project.task/4353554) Forward-Port-Of: odoo/enterprise#74696
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution:
Original PR description
## Issue: - The Cost Analysis report does not accurately reflect the quantity manufactured of a product or the correct cost per unit. ## Steps to reproduce: - Create a manufactured product and two components with costs and on hand quantities. - Confirm a manufacturing order for the product. - Adjust the manufactured quantity of the manufactured product. - Notice that the cost analysis report does not reflect the correct quantity manufactured or the correct cost per unit. ## Solution: - Updated the calculation of `mo_qty` to sum the 'quantity' field instead of `product_qty`. opw-4118237 Forward-Port-Of: odoo/enterprise#74636 Forward-Port-Of: odoo/enterprise#70727