Friday, August 16, 2024
38 changes
14 changes
Resolved issues and error corrections
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
24 changes
Enhancements to existing features
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
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#176515Vehicle 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
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.
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