Navigate
Branch
Friday, August 16, 2024
46 changes
15 changes
Resolved issues and error corrections
This fix prevents an error dialog from appearing when a logged-in user edits a website page and then uses the browser back button. It makes the website editor cleanup more reliable, reducing disruption for users managing website content.
Original PR description
Since [1] when routing was changed to path-based, the website service's `pageDocument` can be reset before the wysiwyg adapter is destroyed. Because of this, the `destroy` might fail - leading to further errors. Steps to reproduce: - Be logged in. - Access the visitor view of the Home page. - Click on the "Editor" link to reach the back-end view. - Click on "Edit". - Click on the back button of the browser. => An error dialog appears. [1]: https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f opw-4074988
This fix ensures Odoo saves valid default values for gevent worker memory settings when configuration files are generated. It prevents later startup or configuration parsing errors caused by invalid empty values, improving reliability for deployments using saved configs.
Original PR description
Since [1], the memory limit for the gevent workers can be configured with the `limit_memory_*_gevent` options. However, defaults are missing. As a result, when the `--save` option is used, the config file contains `None` values for those options. Parsing this file later on will result in an error since `None` cannot be parsed as an integer value. This PR fixes this issue by providing `False` as a default value. This value was chosen over 0 because it clearly indicates the intent to ignore this option and aligns with other option defaults. [1]: https://github.com/odoo/odoo/pull/172604
This fixes a rare timing issue where Chrome could still send a screen recording frame after recording had been stopped. The change prevents unnecessary test crashes and helps keep automated validation results more reliable.
Original PR description
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered…
It's not common, but apparently it's possible for Chrome to send a screencast frame after it's been told to stop. I assume because screencasting is asynchronous so if a frame capture is triggered before the command to stop reaches the browser, that frame capture may complete and be dispatched.
Locally this seems to occur in about 3.5% of calls to `test_screencasts` (7 out of 200 runs). In those cases, the event sequence looks like this:
T + 0.0000s _save_screencast()
sends `Page.stopScreencast`
T + 0.0002s stop
send `Page.stopScreencast`, unsets `screencasts_dir`
T + 0.0100s _handle_screencast_frame
accesses screencasts_frames_dir
`screencasts_frames_dir` then proceed to access `screencasts_dir`, not handle it being `None`, and break.
To fix, just make `screencasts_frame_dir` return `None` if `screencasts_dir` is `None`. This makes `_handle_screencast_frame` properly no-op on the incoming frame. And remove the redundant check on `screencasts_dir` after having ack'd the frame.
Note that this issue has *not* been reported upstream for consideration, as it would require creating a bespoke test case and I can't be arsed. A search on both the tracker and the internet at large doesn't reveal anything relevant.
Example stagings failed due to this:
- https://runbot.odoo.com/runbot/build/66915127
- https://runbot.odoo.com/runbot/build/66915510
And because it's a "traceback found in the logs" it doesn't seem like the runbot is able to see / track it.This fixes a missing setting in the project customer portal so billable project information is handled correctly. It restores expected behavior that had been accidentally omitted in an earlier change, helping sales and project workflows remain consistent for portal users.
Original PR description
It was missed in 481bfa74a89595df7434a9523e0afc1813b8a774 but added back in master
Miscellaneous changes
[FIX] l10n_bd: fix loading account template The issue is that I put the account tags templates in the manifest to load into demo section which cause issues when user try to load the package without demo data as It will not going to load Solution: moving the account tags template/states to the data section task-id#3974212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176845
Original PR description
[FIX] l10n_bd: fix loading account template The issue is that I put the account tags templates in the manifest to load into demo section which cause issues when user try to load the package without demo data as It will not going to load Solution: moving the account tags template/states to the data section task-id#3974212 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176845
There's a single change in this minor version of owl: we no longer call console.warn when a willStart/willUpdateProps callback takes more than 3s (in dev/test mode only anyway). Instead, we use console.log. The reason is that some willStart/willUpdateProps may sometimes take more than 3s (because they lazyload bundles for instance). When this happens, if a warning is logged, the runbot will be yellow and the build will fail. In master, it happenned a lot recently, in tours involving the We
Original PR description
There's a single change in this minor version of owl: we no longer call console.warn when a willStart/willUpdateProps callback takes more than 3s (in dev/test mode only anyway). Instead, we use console.log. The reason is that some willStart/willUpdateProps may sometimes take more than 3s (because they lazyload bundles for instance). When this happens, if a warning is logged, the runbot will be yellow and the build will fail. In master, it happenned a lot recently, in tours involving the WebsiteEditorComponent, which loads the wysiwyg bundle, and since recently, jquery [1]. For that reason, we decided to log instead of warn, at least temporarily, s.t. the skipped tours can be unskipped. [1] odoo/odoo#174213 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#176783
Steps to reproduce: - Create 2 products and publish 1 - Website > Edit > Add a "Products" block - Configure it to filter for recently sold products - Configuration > Payment Providers > Enable Demo - Configuration > Shipping methods > New - Set delivery product to your unpublished product - Publish the shipping method - From Shop buy your published product - Cart > Checkout > Use your shipping method - Validate then return to your products block The delivery products appears in
Original PR description
Steps to reproduce: - Create 2 products and publish 1 - Website > Edit > Add a "Products" block - Configure it to filter for recently sold products - Configuration > Payment Providers > Enable Demo - Configuration > Shipping methods > New - Set delivery product to your unpublished product - Publish the shipping method - From Shop buy your published product - Cart > Checkout > Use your shipping method - Validate then return to your products block The delivery products appears in recently sold, even as a portal user despite never being published and not being directly available to buy. Having unpublished products on the portal should not be possible when logged in as a portal user, much less a delivery product which is insubstantial to the user. opw-4075261 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175817
Steps to reproduce: - Enable storage locations - Inventory > Internal Transfers - Gear Icon > Import records - Try to import a file containing picking type Picking type cannot be imported because it is a readonly field, this is even more problematic since picking_type_id is a required field, thus preventing the import of any other data. Previously, the field picking_type_id used to have a state attribute to make it editable when in draft, but this is no longer the case in 17.0. https:/
Original PR description
Steps to reproduce: - Enable storage locations - Inventory > Internal Transfers - Gear Icon > Import records - Try to import a file containing picking type Picking type cannot be imported because it is a readonly field, this is even more problematic since picking_type_id is a required field, thus preventing the import of any other data. Previously, the field picking_type_id used to have a state attribute to make it editable when in draft, but this is no longer the case in 17.0. https://github.com/odoo/odoo/pull/104741 opw-4074746 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175845
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably
Original PR description
Steps to reproduce ================== - Edit a kanban view so that the default_group_by is a date field - Go to that view - Open studio => Granularity not set on a date(time) field Cause of the issue ================== `web_read_group` is called with a limit of 1 First a call to `read_group` is made Then in order to return the total number of groups when the limit is reached, a call to _read_group is made. Inside `read_group`, there is a compatibility layer that notably add a default month granularity to date(time) fields. This isn't the case inside `_read_group`, which causes a crash Solution ======== Extract the compatibility layer related to the groupby from `read_group` and use that for both methods opw-4051657 Forward-Port-Of: odoo/odoo#176672 Forward-Port-Of: odoo/odoo#174396
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#176524 Forward-Port-Of: odoo/odoo#176012
Original PR description
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#176524 Forward-Port-Of: odoo/odoo#176012
Steps to reproduce: - Time off > Calendar view > Double click on a day - Sick leave > Attach document > Save - View the leave from calendar The attachment preview window overlaps the leave modal information, making it unreadable. The preview is only displayed above large media breakpoints (> 1550px) so make sure to fullscreen. In 16.0 we used a custom element to render the preview which is no longer available https://github.com/odoo/odoo/commit/824024f8aaa4a5419646d4eec7f529277869ceac#
Original PR description
Steps to reproduce: - Time off > Calendar view > Double click on a day - Sick leave > Attach document > Save - View the leave from calendar The attachment preview window overlaps the leave modal information, making it unreadable. The preview is only displayed above large media breakpoints (> 1550px) so make sure to fullscreen. In 16.0 we used a custom element to render the preview which is no longer available https://github.com/odoo/odoo/commit/824024f8aaa4a5419646d4eec7f529277869ceac#diff-a5f278935504f8e1b287b52fbb88f6e58dedc727ec2c7f1a6a04a67202f18fdaR63. opw-4088218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176598
Therefore there's nothing especially wrong in styling it like a button e.g. in the statusbar. Forward-Port-Of: odoo/odoo#176616
Original PR description
Therefore there's nothing especially wrong in styling it like a button e.g. in the statusbar. Forward-Port-Of: odoo/odoo#176616
Backport of: a9be2e45d8db5011cfcbef8f5d81ce4127d5d151 Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed e
Original PR description
Backport of: a9be2e45d8db5011cfcbef8f5d81ce4127d5d151 Steps to reproduce: - Planning > Configuration > Shift Templates > Create - Configure the Shift so that it ends 1 minute into the next day. ==> "(2 days span)" is not displayed in the shift template name. What happens: The rounding precision on the number of days computation only goes up to a 16th of a day, any less was rounded down and show up as 1 day (i.e 1-14 minutes assuming 40h work weeks, ...). This 16th rounding was removed entirely. opw-3911429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176742 Forward-Port-Of: odoo/odoo#173645
IoT image was missing `xinput` dependency. Required by: [https://github.com/odoo/odoo/pull/174009](https://github.com/odoo/odoo/pull/174009) Forward-Port-Of: odoo/odoo#176751
Original PR description
IoT image was missing `xinput` dependency. Required by: [https://github.com/odoo/odoo/pull/174009](https://github.com/odoo/odoo/pull/174009) Forward-Port-Of: odoo/odoo#176751
Steps to reproduce the bug: - Create a subcontracted product “P1”: - the valuation: AVCO automated - BoM: - component: C1 ($15) - Go back to the product form for “P1.” - Click on "Compute from BoM" -> Result: P1 = $15. - Create a Purchase order: - 1 unit of P1 - Confirm the PO and receive P1 - Return the received quantity: - Location: “Partner/lcoation” **Problem:** A traceback is triggered: ``` File "/home/odoo/src/odoo/addons/mrp_subcontracting_purchase
Original PR description
Steps to reproduce the bug: - Create a subcontracted product “P1”: - the valuation: AVCO automated - BoM: - component: C1 ($15) - Go back to the product form for “P1.” - Click on "Compute from BoM"…
Steps to reproduce the bug:
- Create a subcontracted product “P1”:
- the valuation: AVCO automated
- BoM:
- component: C1 ($15)
- Go back to the product form for “P1.”
- Click on "Compute from BoM" -> Result: P1 = $15.
- Create a Purchase order:
- 1 unit of P1
- Confirm the PO and receive P1
- Return the received quantity:
- Location: “Partner/lcoation”
**Problem:**
A traceback is triggered:
```
File "/home/odoo/src/odoo/addons/mrp_subcontracting_purchase/models/stock_valuation_layer.py", line 21, in _get_layer_price_unit
return super()._get_layer_price_unit() + components_price
File "/home/odoo/src/odoo/addons/purchase_stock/models/stock_valuation_layer.py", line 12, in _get_layer_price_unit
return self.value / self.quantity
ZeroDivisionError: float division by zero
```
When validating the return, the `_account_entry_move` function is called to verify if the returned value of the product is different from the purchased one. In this case, we need to clear the `stock_in` account with the difference. To do this, we retrieve the layer associated with the origin move of the return. However, since this move is an internal one (from the subcontracting location to WH/stock), the `_should_be_valued` function returns `False`, and no layer is created for this move:
https://github.com/odoo/odoo/blob/7afd9294338dd18c3351afd2017648931fdb9ee3/addons/stock_account/models/stock_location.py#L25-L30
Because we do not check if a layer exists for this move and directly call the `_get_layer_price_unit` function, a traceback is triggered as we have division by zero
**Solution:**
In case there is no layer associated with the original move, we can consider the difference as 0.
For example, in our case, the layer of the returned move has a value of 30 (15 for P1 and 15 for C1). Therefore, even if we return P1 to the subcontractor, we will not return the value of C1 because it has already been delivered and used.
opw-4053362
Forward-Port-Of: odoo/odoo#17651528 changes
New functionality added to Odoo
Businesses can now upload bank statements as PDFs or images and have them automatically digitized using OCR, reducing manual data entry. The bank statement screens were also improved to make reviewing and managing statements easier.
Original PR description
Contains two commits, one to add the possibility to digitise bank statements from PDFs and images, and another commit with some UI improvements for the bank statement list and form views. task-4061457
Enhancements to existing features
Mobile users now access the app navigation from a dedicated left-side Apps Menu instead of the existing right-side burger menu. This makes mobile navigation more clearly separated, though reaching the Home Menu now requires one additional tap.
Original PR description
Before this commit, the navigation app menu was in the burger menu (in the right panel). Now, it's moved on the left in a new panel named "AppsMenu". We are aware that it adds a second click to access to the "Home Menu" on mobile. task-3336242
This change disables automatic retries for a Field Service UI test that was producing misleading follow-up errors after an initial failure. It helps teams identify the real cause of test failures more quickly, improving maintenance of the testing pipeline without affecting end users.
Original PR description
FSM does really strange stuff, as a result when the tour fails the retry tends to completely lose its shit and generate a different and useless error. See [runbot build 66859325] as an example, the actual failure is the step "Switch to kanban view" not finding its kanban button, but the retries try to re-run with a dynamically generated table which has likely been rolled back (?). Disable retry on the test_ui tour for now, maybe there's a team in charge of FSM which could handle this situation properly tho... [runbot build 66859325]: https://runbot.odoo.com/runbot/build/66859325
Vehicle demo data and related Belgian payroll examples have been updated to match the current fleet records. This keeps salary and payroll demonstrations reliable after older vehicle examples were removed.
Resolved issues and error corrections
When an online food delivery order is edited and then accepted, its status now refreshes correctly instead of briefly showing outdated information. This helps staff see the current order state immediately and reduces confusion during order handling.
Original PR description
Steps to reproduce: ==== - Place an online food delivery order. - Edit the order. - Now accept the order - Order status will not get updated immediately. Issue: ==== - Order were synced again during accept order so old status was taken into consideration. Fix: ==== - Order is been fetched again with updated status.
This fixes an issue in the Philippine SLSP report where monthly lines displayed blank columns instead of the relevant report option information. Businesses using this report should now see more complete and accurate monthly report details.
Original PR description
Month lines were using empty columns when they should have been using columns with the options information.
Fixed a configuration issue in the accounting lock date wizard so a warning setting is treated as a simple yes/no value. This helps the wizard behave more reliably when showing draft entry warnings.
Original PR description
The field `show_draft_entries_warning` has type `Text` but it should be a `Boolean`. This is fixed in this commit.
Fixes an issue where users could receive an access error when requesting an OTP for Indian GST authentication from the configuration screen. The request now includes the GSTIN, allowing the authentication flow to proceed correctly for affected businesses.
Original PR description
- Before this commit: An Access error is raised while clicking on send OTP for Indian GST on Configuration. - After this commit: That error is fixed by providing GSTIN in the parameter while requesting OTP. issue produced in : https://github.com/odoo/enterprise/commit/61e5101081c87082de4b6d938fbe7ccdb329e7b6
Miscellaneous changes
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#68177 Forward-Port-Of: odoo/enterprise#63822
Original PR description
As negative invoice lines, aka global discounts, are not accepted by the Ecuador government, we transform them into discounts of the positives lines for the e-invoice. task-3752009 Forward-Port-Of: odoo/enterprise#68177 Forward-Port-Of: odoo/enterprise#63822
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
Original PR description
The PR hides the M2O external button in the "Add to Dashboard" dialog by passing the 'no_open' option to the widget. Task: [4066519](https://www.odoo.com/odoo/project/2328/tasks/4066519?cids=2) Forward-Port-Of: odoo/enterprise#67804
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619 Forward-Port-Of: odoo/enterprise#68374
Original PR description
[FIX] l10n_in_asset: fix check_depreciation func dependencies `_check_depreciations` function is only called at creation and not afterwards We need to have it raised afterwards too task-id#3909619 Forward-Port-Of: odoo/enterprise#68374
Before this commit: Having a printer P saved in the browser cache as the printer for a report R. If the printer P is removed from the IoT device, a pop-up error will raise when R tried to be printed with an unclear "iot.device(X) is missing". After this commit: The missing device is detected on the server side, and the cache is automatically cleaned for this report so that on the next attempt, the printer choice pop-up appear. Also took the opportunity to clean the JS code on the modified
Original PR description
Before this commit: Having a printer P saved in the browser cache as the printer for a report R. If the printer P is removed from the IoT device, a pop-up error will raise when R tried to be printed with an unclear "iot.device(X) is missing". After this commit: The missing device is detected on the server side, and the cache is automatically cleaned for this report so that on the next attempt, the printer choice pop-up appear. Also took the opportunity to clean the JS code on the modified functions :) opw-3965623 opw-4017201 Forward-Port-Of: odoo/enterprise#67658 Forward-Port-Of: odoo/enterprise#65743
The Issue: Prior to this commit, starting a tour on Thursday and setting the end date to Saturday or Sunday would cause a traceback error. This occurred because renting was not allowed on weekends, leading to the tour's failure. The Fix: The fix involved enabling availability for renting on Saturdays and Sundays. runbot-72624 Forward-Port-Of: odoo/enterprise#68350
Original PR description
The Issue: Prior to this commit, starting a tour on Thursday and setting the end date to Saturday or Sunday would cause a traceback error. This occurred because renting was not allowed on weekends, leading to the tour's failure. The Fix: The fix involved enabling availability for renting on Saturdays and Sundays. runbot-72624 Forward-Port-Of: odoo/enterprise#68350
In the community counterpart of this PR, a debounce is added to the addition of bus channels in order to batch them as much as possible. The room module uses the `waitForSubscribe` bus helper but never awaits it which trigger errors in other tests. This PR fixes this issue. community: https://github.com/odoo/odoo/pull/175972 Forward-Port-Of: odoo/enterprise#68099
Original PR description
In the community counterpart of this PR, a debounce is added to the addition of bus channels in order to batch them as much as possible. The room module uses the `waitForSubscribe` bus helper but never awaits it which trigger errors in other tests. This PR fixes this issue. community: https://github.com/odoo/odoo/pull/175972 Forward-Port-Of: odoo/enterprise#68099
Edit channel name (or description) might be prevented on the header in discuss, even though it's possible from the form view (config page). If the ACL permits, it should be possible to edit from header too. task-4100348 https://github.com/odoo/odoo/pull/175886 Forward-Port-Of: odoo/enterprise#68140
Original PR description
Edit channel name (or description) might be prevented on the header in discuss, even though it's possible from the form view (config page). If the ACL permits, it should be possible to edit from header too. task-4100348 https://github.com/odoo/odoo/pull/175886 Forward-Port-Of: odoo/enterprise#68140
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financie
Original PR description
The Ecuadorian law requires the unit price on the XML invoice and on the PDF to be the same, this is currently not the case with taxes included in the price. ### Steps to reproduce: - Install the 'l10n_ec' module and switch to an Ecuadorian company - Change the 'IVA 15% (411, Servicios)' Tax to be included - In Accounting create a new Customer Invoice - Select 'Instituto Ecuatoriano' as Customer - Add a line with the included tax set before - Select 'Sin utilization del sistema financiero' as Payment Method - Confirm - On the blue popup at the top of the page, click 'process now' to get the XML in the chatter - Click preview to get the PDF - The unit prices are not the same ### Cause: Usually on the PDF the unit price with included taxes is displayed. ### Solution: Create a xpath to compute the unit price in the same way as the XML. opw-4078177 Forward-Port-Of: odoo/enterprise#67721
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of
Original PR description
Problem: When the user duplicates a rental order from a list view in the rental app, the order lines of the rental order were not getting computed to True for field is_rental during compute_is_rental. The compute method was checking if the 'in_rental_app' was passed into the line's context, which is not the case during the duplication. Solution: If a line has rentable products and it is from a rental order, then the line should be considered is_rental, rather than basing it on the context of the method being called from the Rental app. Steps to Reproduce on Runbot: 1. Install Rental app 2. View the rental orders in list view 3. Select a rental order with a status and duplicate 4. Observe that duped rental order has no rental_status when you confirm it opw-4055493 Forward-Port-Of: odoo/enterprise#67670
if their is nothing to read in attachment file related spreadsheet. So, it will bring empty byte [``b''``](https://github.com/odoo/odoo/blob/9bba9f8246a0a046a631fb849846109131e74750/odoo/addons/base/models/ir_attachment.py#L234) that is here and when it go for [decode](https://github.com/odoo/enterprise/blob/c072e9e104a4ed24d345062f66a44d84aaeb074b/spreadsheet_edition/models/spreadsheet_mixin.py#L233) it will raise this traceback ``` Traceback (most recent call last): File "/tmp/tmp3fwx3zd
Original PR description
if their is nothing to read in attachment file related spreadsheet. So, it will bring empty byte…
if their is nothing to read in attachment file related spreadsheet. So, it will bring empty byte [``b''``](https://github.com/odoo/odoo/blob/9bba9f8246a0a046a631fb849846109131e74750/odoo/addons/base/models/ir_attachment.py#L234) that is here and when it go for [decode](https://github.com/odoo/enterprise/blob/c072e9e104a4ed24d345062f66a44d84aaeb074b/spreadsheet_edition/models/spreadsheet_mixin.py#L233) it will raise this traceback
```
Traceback (most recent call last):
File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 256, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 429, in mock_action
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 532, in mock_view_kanban
self.mock_web_search_read(model, view, [domain], fields_list)
File "/tmp/tmp3fwx3zdj/migrations/base/tests/test_mock_crawl.py", line 591, in mock_web_search_read
data = model.search_read(domain=domain, fields=fields_list, limit=80)
File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 5847, in search_read
return records._read_format(fnames=fields, **read_kwargs)
File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 3902, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 6727, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 1263, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 1445, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/saas-17.4/addons/mail/models/mail_thread.py", line 428, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/saas-17.4/odoo/models.py", line 5037, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/saas-17.4/odoo/fields.py", line 101, in determine
return needle(*args)
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 44, in _compute_current_revision_uuid
snapshot = spreadsheet._get_spreadsheet_snapshot()
File "/home/odoo/src/enterprise/saas-17.4/spreadsheet_edition/models/spreadsheet_mixin.py", line 233, in _get_spreadsheet_snapshot
return json.loads(base64.decodebytes(snapshot))
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
for preventing this added a condition to return false because their is no meaning at all decoding this data
This taceback is raising during upgrade why field data is empty byte ``b''`` due to that above tracbeack is raised
why as this field introduced in kanban [view](https://github.com/odoo/enterprise/commit/a055dfeb84abc34015b269422264534d97a83d8f) on computing it blocking the upgrade process during read call
Forward-Port-Of: odoo/enterprise#68285Have a company with currency CUR1 setup Activate currency CUR2 In Point of Sale setup change: - Payment methods journal currency to CUR2 - Default journal for Orders currency to CUR2 - Add default pricelist in CUR2 Open POS session Issue: POS session loading will be stuck Backend is in error: "TypeError: list indices must be integers or slices, not str" This occurs because we look for a not existing key opw-4093540 Forward-Port-Of: odoo/enterprise#68254
Original PR description
Have a company with currency CUR1 setup Activate currency CUR2 In Point of Sale setup change: - Payment methods journal currency to CUR2 - Default journal for Orders currency to CUR2 - Add default pricelist in CUR2 Open POS session Issue: POS session loading will be stuck Backend is in error: "TypeError: list indices must be integers or slices, not str" This occurs because we look for a not existing key opw-4093540 Forward-Port-Of: odoo/enterprise#68254
Description of the issue this commit addresses: When trying to export a report in .xlsx format, if some annotations have been added to the report, and no growth comparison is set, a traceback appears. --- Steps to reproduce: 1. Install Accounting 2. Go to any report 3. Add an annotation on any line 4. Export the report in .xlsx format 5. A traceback appears --- Desired behavior after this commit is merged: Doing the same steps after this fix should result in the export's
Original PR description
Description of the issue this commit addresses: When trying to export a report in .xlsx format, if some annotations have been added to the report, and no growth comparison is set, a traceback…
Description of the issue this commit addresses: When trying to export a report in .xlsx format, if some annotations have been added to the report, and no growth comparison is set, a traceback appears. --- Steps to reproduce: 1. Install Accounting 2. Go to any report 3. Add an annotation on any line 4. Export the report in .xlsx format 5. A traceback appears --- Desired behavior after this commit is merged: Doing the same steps after this fix should result in the export's success and the possibility for the user to open the file in which the annotations are. --- Note on the fix: During investigation, it was noticed that the offset has a discordant computation behavior. After completing a subheader column, the offset is incremented by the colspan but not after an option column is completed. This means that the condition that was computing the annotations' column offset would not have been required if the offset was correct in the first place. Correcting that computation makes the whole system clearer. --- opw-4095385 Forward-Port-Of: odoo/enterprise#68007
To reproduce the issue, on a fresh db with nothing else: 1) Create a new accounting report from srcatch, so that: - it has 2 columns - it has 1 line, with two expressions: - the expression going in column 1 is a domain, doing [('debit', '>', 0)] - the expression going in column 2 is also a domain, doing [('balance', '>', 0)] - it has analytics groupby enabled 2) Create a vendor bill, with only 1 line of 100€. Assign it an analytic distribution of 100% into
Original PR description
To reproduce the issue, on a fresh db with nothing else: 1) Create a new accounting report from srcatch, so that: - it has 2 columns - it has 1 line, with two expressions: - the expression going in…
To reproduce the issue, on a fresh db with nothing else:
1) Create a new accounting report from srcatch, so that:
- it has 2 columns
- it has 1 line, with two expressions:
- the expression going in column 1 is a domain, doing [('debit', '>', 0)]
- the expression going in column 2 is also a domain, doing [('balance', '>', 0)]
- it has analytics groupby enabled
2) Create a vendor bill, with only 1 line of 100€. Assign it an analytic distribution of 100% into some analytic account.
3) Open your report, activate the analytic groupby on the analytic account used in point 2).
====> The column considering the balance shows 100€, while the one considering the debit shows 0. This is wrong; both columns should show 100€.
This is due to the fact the sign of the debit is inverted in the SQL shadowing of the move lines made to handle analytics in the report engine. Instead of 100, it sees -100 here, which does not match the domain.
Forward-Port-Of: odoo/enterprise#68326
Forward-Port-Of: odoo/enterprise#67018Instead of using the `bg-white` class from boostrap, which is translated to black in dark-mode, make use of the color-scheme from odoo. This avoids having a mismatch between light and dark mode. Before (Dark / Light):  After (Dark / Light):  Forward-Port-Of: odoo/enterprise#68231
Original PR description
Instead of using the `bg-white` class from boostrap, which is translated to black in dark-mode, make use of the color-scheme from odoo. This avoids having a mismatch between light and dark mode. Before (Dark / Light):  After (Dark / Light):  Forward-Port-Of: odoo/enterprise#68231
When the public users access the `/knowledge/home` route, the system will open the first accessible, visible and published article using a domain involving different search compute methods. In the `_search_is_article_visible` search method, the system will fetch the members associated to the current user. However, the public users do not have access to that model. As a result, the public user will get an access error and the server will display the 403 error page. Steps to reproduce the er
Original PR description
When the public users access the `/knowledge/home` route, the system will open the first accessible, visible and published article using a domain involving different search compute methods. In the…
When the public users access the `/knowledge/home` route, the system will open the first accessible, visible and published article using a domain involving different search compute methods. In the `_search_is_article_visible` search method, the system will fetch the members associated to the current user. However, the public users do not have access to that model. As a result, the public user will get an access error and the server will display the 403 error page. Steps to reproduce the error: 1. Install `website_helpdesk_knowledge` module. 2. On the Odoo homepage, click on the helpdesk icon. 3. On the helpdesk overview, click on the vertical dots of the "Customer Care" team card. 4. On the dropdown menu, click on the "Settings" option. 5. On the "Help Center" section, click on the "Knowledge" option. 6. On the "Visibility & Assignment" section, click on "Invited portal users and all internal users" option. 7. Save the changes. 8. Open a new browser in incognito and go on your website. 9. Click on the "Customer Care" navbar link of your website. 10. Click on the "Browse articles" button 11. You should get a 403 error page => TO BE: You shouldn't get a 403 error page. Since the public users cannot be added to the article members list, we will skip the members fetching for those users and return an empty domain. The condition will then be ignored and the search method will not raise any exception. task-3980714 Forward-Port-Of: odoo/enterprise#64377
## Issue: - A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.' ## Steps To Reproduce: - Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`. - in settings: - enable the `Lock Timesheets` option. - set the invoicing polic
Original PR description
## Issue: - A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period,…
## Issue:
- A user with sufficient access rights to timesheet, ('User: all timesheets' or 'User: own timesheets only') cannot create an invoice for a sales order within a specific timesheet period, receiving the error: 'Timesheets before [PERIOD] are validated and cannot be modified.'
## Steps To Reproduce:
- Edit `Create on Order` of the `Service on Timesheets` product to be `Project & Task`.
- in settings:
- enable the `Lock Timesheets` option.
- set the invoicing policy for Timesheets to `validated timesheets only` .
- set the invoicing policy for Sales to 'invoice what is delivered'.
- Update the timesheet access for `Marc Demo` and set it as 'User: all timesheets'.
- Create a SO with `Service on Timesheets` as a product.
- On the related Task create a timesheet for period 01 May to 31 May and validate it.
- With Marc Demo click on Create an Invoice on the SO, for the same period notice The Access Error.
## Solution:
- in `check_if_allowed` I modified the condition to check if the current user is not a superuser.
opw-3965532
Forward-Port-Of: odoo/enterprise#68250
Forward-Port-Of: odoo/enterprise#65435before this commit, on opening general ledger report shows traceback for the user  introduced in this commit: https://github.com/odoo/enterprise/commit/402ed134269db6b82679c32d21eb1122bbda7cfe after this commit, the report will be opened without any issues Forward-Port-Of: odoo/enterprise#68287
Original PR description
before this commit, on opening general ledger report shows traceback for the user  introduced in this commit: https://github.com/odoo/enterprise/commit/402ed134269db6b82679c32d21eb1122bbda7cfe after this commit, the report will be opened without any issues Forward-Port-Of: odoo/enterprise#68287
It's really unintuitive and non-Odoo to have to close the filter box to be able to apply a filter on reports. Let's change that. We now delay let user click on filters while it's loading. We then delay filters that make a rpc call by 500 ms. The goal being that we don't do 5 calls if the user wants to select 5 journals. It implies several difficulties, including a reloading of the data or the options that were done when clicking. For that, we use loadingCallHash (to know if the options sent
Original PR description
It's really unintuitive and non-Odoo to have to close the filter box to be able to apply a filter on reports. Let's change that. We now delay let user click on filters while it's loading. We then delay filters that make a rpc call by 500 ms. The goal being that we don't do 5 calls if the user wants to select 5 journals. It implies several difficulties, including a reloading of the data or the options that were done when clicking. For that, we use loadingCallHash (to know if the options sent by the python are the ones needed to be reloaded). task-3912381 Forward-Port-Of: odoo/enterprise#68273 Forward-Port-Of: odoo/enterprise#67192
When the user accesses an article via a shared link (`/knowledge/article/42`), the internal users will be redirected to the backend view of Knowledge using the legacy route (i.e: `/web#id=...&model=...`). When loading the page, the router will transform that url to a more friendly one (i.e: `/odoo/knowledge/...`). To avoid updating the url many times, we will directly redirect the user to the new route. task-3975577 Forward-Port-Of: odoo/enterprise#68312
Original PR description
When the user accesses an article via a shared link (`/knowledge/article/42`), the internal users will be redirected to the backend view of Knowledge using the legacy route (i.e: `/web#id=...&model=...`). When loading the page, the router will transform that url to a more friendly one (i.e: `/odoo/knowledge/...`). To avoid updating the url many times, we will directly redirect the user to the new route. task-3975577 Forward-Port-Of: odoo/enterprise#68312
Current behaviour: --- When settings the user's language as hebrew, the user cannot open any documents Steps to reproduce: --- 1. My profile > Language > Hebrew 2. Go to Documents 3. Open any documents 4. Traceback Cause of the issue: --- file_extension would be literally translated Fix: --- Setting t-translation as off opw-3938083 Forward-Port-Of: odoo/enterprise#68131 Forward-Port-Of: odoo/enterprise#66688
Original PR description
Current behaviour: --- When settings the user's language as hebrew, the user cannot open any documents Steps to reproduce: --- 1. My profile > Language > Hebrew 2. Go to Documents 3. Open any documents 4. Traceback Cause of the issue: --- file_extension would be literally translated Fix: --- Setting t-translation as off opw-3938083 Forward-Port-Of: odoo/enterprise#68131 Forward-Port-Of: odoo/enterprise#66688
3 changes
Enhancements to existing features
The print dialog now automatically closes after users confirm their print job, eliminating the extra step of manually closing it. This improvement makes the printing process faster and more intuitive, reducing unnecessary clicks and improving overall user experience.
Original PR description
Automatically close the print dialog after the user confirms the print job. This enhancement improves user experience by eliminating the need for users to manually close the dialog, streamlining the printing process. Initially, we considered keeping the modal open until all print operations completed successfully. If any printer encountered an error, the modal would remain open. However, this approach doesn't assist users in resolving the issue, as they would still need to close the modal to correct the problem. Therefore, it is more user-friendly to automatically close the modal after user confirmation. https://github.com/user-attachments/assets/659d971e-25c8-487f-8c02-cf0f5461a920 Forward-Port-Of: odoo/enterprise#68195
Resolved issues and error corrections
This fix resolves a system error that occurred when marking items as failed during quality checks on manufacturing orders with backorders. The issue happened because the system was trying to assign multiple inventory lines to a single quality check record. By properly ordering failed items first during the backorder split process, the system now correctly identifies which specific inventory line corresponds to each quality check, preventing the error and allowing quality failures to be properly recorded.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1” with BoM: - Component: C1 - Create a quality point: - Product: P1 - Operation: Manufacturing - Control per: Quantity - Control Frequency:…
Steps to reproduce the bug:
- Create a storable product “P1” with BoM:
- Component: C1
- Create a quality point:
- Product: P1
- Operation: Manufacturing
- Control per: Quantity
- Control Frequency: All
- Create a manufacturing order:
- Product: P1
- Quantity: 20
- Confirm the MO
- Set the qty producing 12
- click on the quality check:
- Button Fail
- Quantity: 5
- Valide the Mo and create a backorder
- click on the quality check:
- Button Fail
- Quantity: 1
Problem:
A traceback is triggered:
```
File "/home/odoo/odoo V16/enterprise/quality_control/models/quality.py", line 370, in _move_line_to_failure_location
if not check._can_move_line_to_failure_location():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/enterprise/quality_mrp/models/quality.py", line 49, in _can_move_line_to_failure_location
self.move_line_id = self.production_id.finished_move_line_ids.filtered(
^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 1321, in __set__
write_value = self.convert_to_write(value, records)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 3118, in convert_to_write
return value.id
^^^^^^^^
File "/home/odoo/odoo V16/odoo/odoo/fields.py", line 5154, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.move.line(96, 98)
```
When we validate the MO to create the backorder, the `_split_productions`
function is called. This results in two move lines:
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1837
The first one has a quantity of 15, which is the remaining quantity
to be processed, and the second line has a quantity of 5, which is the
quantity that has definitely failed. However, these two move lines are
supposed to be ordered first by the failed ones and then by the others.
Because, in the current situation, we take the move line with the
quantity of 15, reduce it by the 12 units processed in this MO,
leaving 3. As a result, we will have two remaining move lines:
3 + 5 (already failed), and both will be used in the backorder.
But if they were ordered by the failed ones first, we would subtract
12 from 5, resulting in -7, and then reduce the line with 15 - 7 = 8
in the move line that will be used in the backorder."
https://github.com/odoo/odoo/blob/4be8cac644c9471f98bf16e82825af0e9439e697/addons/mrp/models/mrp_production.py#L1848-L1858
opw-4064656This fix corrects how financial reports handle the display of columns with zero values and text-based data. Previously, a change caused text columns (like customer names) to disappear when they should have been visible. The fix refines the logic so that text values are properly treated when deciding whether to hide or show report lines, while ensuring numeric columns like percentages are correctly evaluated.
Original PR description
Partial revert of https://github.com/odoo/enterprise/commit/318ae33da2e36036e1a74028a36d02ad4fa5964e (we keep the test and revert the fix). The reverted commit intended to soluve issues with hide_if_zero, and had it consider the string values as 0. However, in 17.2+, this caused issues with the blank_if_zero columns, which then never showed such string values. We revert the original fix and take a new approach in this commit ; we do that in 17.0 instead of 17.2 just for homogeneity of the code base, and ease of maintenance on longer term. The new strategy is bacisally to consider non-number values as 0 only when handling the hide_if_zero option, without touching to the computation of the is_zero key of column dicts. Also, this commit explicitly adds the 'percentage' figure_type to the ones checked by the 'is_zero' key in column dicts: percentages are numeric values; ignoring them there was wrong.