Wednesday, July 24, 2024
31 changes · master
Enhancements to existing features
The document upload process has been simplified by removing unnecessary error-handling code around file reading. This makes the upload code easier to maintain while keeping any real upload issues visible to users through the normal web interface.
Original PR description
Based on file sources, we have determined that errors will never occur during the file reading process. If it fails, it will be naturally reported to the web client. This PR simplifies the code and eliminates unnecessary exception handling. Task-3973319
Odoo Studio’s report editor now supports adding and removing columns in certain report tables, making report layout customization easier. The update also fixes editable banner content and cleans up unused styling so the editor behaves more reliably.
The payroll account test module now covers a quicker login experience for people sharing the same device. The feature keeps only recent user login names and avatars in the browser, avoiding stored passwords or sessions while making repeated logins easier.
Original PR description
When several users share the same device, the login/logout process can be boring, so we added a quick login feature. For a security propose it doesn't store the session or the password of the user. No data is sent to the server, everything is stored inside the browser localStorage[1] . It only stores the login of the user and the avatar of the user for the last 5 users connected to the device. We also lightly redesign the login screen task-3953707 [1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage
Asset records can now include extra distinguishing information, such as brand or other descriptive properties. This helps teams identify and manage assets more accurately with business-specific details.
Original PR description
People want to be able to add distinctive info on assets (like brand, ..) task-3996633
Mexican companies that rent spaces or land can now store a property registration number on each product. When present, this predial account is included in the invoice XML to support local compliance requirements.
Original PR description
Companies in Mexico whose primary business involves renting out spaces or land must have a "Cuenta predial" in the XML. This is the official registration number of the property with the local authority. The predial account field is added to the product's accounting settings and we have one predial account per product. When a predial account is present, it's displayed in the invoice XML. task-4033975
This update converts field service-related automated tests to a newer testing framework. It improves maintainability and reliability of internal quality checks without changing day-to-day user workflows.
Original PR description
_*= industry_fsm_stock, industry_fsm_sale task-3935514
Resolved issues and error corrections
This fix keeps spreadsheet pivot tables working as expected after an underlying spreadsheet engine update. Users can rename measures and include the same measure more than once without side panel or autocomplete issues.
Original PR description
See https://github.com/odoo/enterprise/pull/67268#issue-2427359270
Miscellaneous changes
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Original PR description
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
This fixes an intermittent timing issue in the Documents deletion test that could cause automated checks to fail even when the product behaved correctly. The change helps keep quality checks stable and reduces false alarms during development.
Original PR description
Sometimes the following sequence happened after the steps in `restoreDocumentSteps` after those in `deleteWorkspaceSteps`: 1. We click on the trash section 2. Its header is re-rendered with the "active" class 3. We select the record 4. The kanban view is reloaded to actually show the trash now 5. We already selected the document, so we're at the step expecting to interact with the inspector. See runbot error 71617
The document deletion test now waits until the expected deleted item is actually loaded before continuing. This prevents false failures under slow network conditions and helps keep automated quality checks stable.
Original PR description
In this tour, there is a step that is supposed to check that the elements in trash are loaded.
.o_search_panel_field header.active:contains("Trash")
However, this is incorrect. If we put the network in slow 3G, we can see that the header has the active class while the trash elements are not yet loaded.
In this commit, we therefore ensure that chouchou is in the loaded elements before selecting it.This fixes an issue in Documents spreadsheets where renamed pivot measures were not properly supported. Business users can now rely on custom measure names appearing correctly, making spreadsheet reports clearer and easier to interpret.
This fixes spreadsheet pivot reports so the same measure can be added more than once, including with custom names, without causing display or interaction issues. Business users get more flexible spreadsheet reporting and more reliable pivot tables when comparing the same metric in different ways.
This fixes a misleading internal field name used to track reversal entries across several accounting-related apps. The change reduces confusion for developers and maintainers without changing how business users work in Odoo.
Original PR description
…rsal_move_ids *: account_asset, account_reports, helpdesk_account, hr_payroll_expense, sale_subscription We introduced this field with a typo, now it causes misunderstanding as it is interpreted as a many2one and not a one2many. Related: https://github.com/odoo/odoo/commit/09a6a4da116059414baeb7e663d8a503c3ae082e task-no
Fixed an error that could occur when selecting or assigning tasks from the Project Gantt view. This keeps project planning workflows stable and avoids interruptions for users managing task schedules.
Original PR description
Steps to Reproduce: 1. Go to the Gantt view in tasks in the Project module. 2. Select a task. 3. Observe the traceback error. Cause: - The `Task.web_gantt_write()` method received an unexpected keyword in the data argument, causing a TypeError. Solution: - Updated the call of the `Task.web_gantt_write()` method to handle the data argument correctly. effected commit-https://github.com/odoo/enterprise/commit/214b52cb7d6d2087d2b18c2ff32a7b59b9b2e21b task-4057377
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
Original PR description
Before this commit, validating an order in the PoS restaurant module with a customer note attached would result in a KeyError. This issue occurred because the customer note was incorrectly processed in the note history, leading to unexpected behavior. Community PR: https://github.com/odoo/odoo/pull/174249 opw-4059220 Forward-Port-Of: odoo/enterprise#67210
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bound
Original PR description
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bounds, we make the item visible again even though the the invalid operation is discarded. task-4037888 Forward-Port-Of: odoo/enterprise#66155
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67235 Forward-Port-Of: odoo/enterprise#62945
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639 Forward-Port-Of: odoo/enterprise#67235 Forward-Port-Of: odoo/enterprise#62945
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: - Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity. - In the barcode app, adjust the inventory by adding the created product and then save the changes. - Click on the small pen icon to modify the product's details. - Observe
Original PR description
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: -…
## Issue: - When adjusting inventory for a product with packages from the barcode app, quantities that are not whole numbers will be rounded to the nearest whole number. ## Steps To Reproduce: - Create a product and include two other products in its packaging, specifying a non-whole number for the contained quantity. - In the barcode app, adjust the inventory by adding the created product and then save the changes. - Click on the small pen icon to modify the product's details. - Observe that when adding the quantities with decimal values, they get rounded up to the nearest whole number. ## Solution: - In the `_increment` function, when the initial `value` is not a decimal (it does not contain a '.'), the fraction variable is not set, and the rounding defaults to 0. It's important to note that this issue does not occur when the `value` is a decimal, as the split function operates correctly. - To resolve this issue, instead of relying on the number of digits after the '.' in the `value`, we set the precision based on what is defined in the 'decimal.precision' model. This approach not only addresses the current issue but also resolves the underlying problem initially discussed in this PR https://github.com/odoo/enterprise/pull/53378 opw-3896929 Forward-Port-Of: odoo/enterprise#67075 Forward-Port-Of: odoo/enterprise#62505
In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. As a consequence, the grid view does not have the style it should have in dark mode. Here we use the newly introduced bundle 'web.assets_backend_lazy_dark' in https://github.com/odoo/odoo/pull/173620 to fix that and make studio use that bundle too in dark mode. In this forward port we also fix the style of the gantt view in dark mode. Forward-Port-Of: odoo/enterpr
Original PR description
In https://github.com/odoo/odoo/commit/f1749d3299957e2949e0b78653266a5397bb213c, we forgot to prepare a bundle for the dark mode. As a consequence, the grid view does not have the style it should have in dark mode. Here we use the newly introduced bundle 'web.assets_backend_lazy_dark' in https://github.com/odoo/odoo/pull/173620 to fix that and make studio use that bundle too in dark mode. In this forward port we also fix the style of the gantt view in dark mode. Forward-Port-Of: odoo/enterprise#66908
Community: https://github.com/odoo/odoo/pull/172269 Upgrade: https://github.com/odoo/upgrade/pull/6227 Task-4014022
Original PR description
Community: https://github.com/odoo/odoo/pull/172269 Upgrade: https://github.com/odoo/upgrade/pull/6227 Task-4014022
This PR fixes a test that was relying on the user being in a certain timezone. This timezone is now set before the test. Task-4038158 Forward-Port-Of: odoo/enterprise#66889
Original PR description
This PR fixes a test that was relying on the user being in a certain timezone. This timezone is now set before the test. Task-4038158 Forward-Port-Of: odoo/enterprise#66889
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
Original PR description
Update legacy tests importing mail/test_utils.js to use HOOT instead of Qunit. Task-3818666 Forward-Port-Of: odoo/enterprise#66751
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59
Original PR description
Previously, we added support for self-withholding taxes, which do not need to be reported in the XML file. Hence, tax lines that contain a tax with a code ZZ (for customer invoices)/ ZZ, 07 (for vendor bills) are filtered out. However, when we compute the total amounts these are not filtered out, leading to a discrepancy in sums. We should filter out such tax lines when computing totals as well. See other commit: https://github.com/odoo/enterprise/commit/af8f364cc1f09cc1f9159b326a7f59c6524380be opw-3958518 Forward-Port-Of: odoo/enterprise#67100 Forward-Port-Of: odoo/enterprise#66918
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#6
Original PR description
Steps to reproduce: - Projects > Field Service > New - Pick a customer but no assignee - Products > Add any product - Back to task > Sale order > Other info tab What happens: No salesperson is set. Expected behavior: salesperson is the first assignee on the task if any, current user if not (first assignee as in the first listed on the task, which sorts them alphabetically). opw-4026074 opw-4015184 (duplicate) Forward-Port-Of: odoo/enterprise#67184 Forward-Port-Of: odoo/enterprise#66404
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe
Original PR description
Before, when the subscription cron create recurring invoices, it might create a credit note in case some already invoiced non recurring product had his ordered quantity set back to zero. The payment transaction created for this credit note will take the absolute total without taking into account the type of the entry process. This leads to a transaction charging the amount to the client instead of refunding him. As we don't want to allow automatic refund because it could lead to catastrophe if a bug occurs, we decide to prevent the payment request if the amount is negative. In that case, we keep the draft invoice and keep the "payment_exception" flag to avoid running the subscription invoice cron again on that contract. opw-3874964 Forward-Port-Of: odoo/enterprise#67103 Forward-Port-Of: odoo/enterprise#64098
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL f
Original PR description
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL from the start of the fiscal year, therefore getting the current year's PnL opw-3957488 Forward-Port-Of: odoo/enterprise#66883
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as
Original PR description
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as ShipmentIdentificationNumber in cancel request. Reference ups documentation: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment Methods > Shipment Methods > Void Shipment opw-3974794 Forward-Port-Of: odoo/enterprise#67158
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the planning module in `year` mode 3) Change the `resource` of any existing slot with `repeat` enabled record 4) Now run the corn job (`generate next recurring shifts`) to produce the issue for instance Error:- ``` ValueError: Expected singleton: hr.employee(2, 8) File "odoo/tools/safe
Original PR description
This traceback occurs when the user changes the `resource` of an existing The `planning slots` record has a `repeat` enabled. To reproduce this issue: 1) Install `planning_contract` 2) Open the…
This traceback occurs when the user changes the `resource` of an existing
The `planning slots` record has a `repeat` enabled.
To reproduce this issue:
1) Install `planning_contract`
2) Open the planning module in `year` mode
3) Change the `resource` of any existing slot with `repeat` enabled record
4) Now run the corn job (`generate next recurring shifts`)
to produce the issue for instance
Error:-
```
ValueError: Expected singleton: hr.employee(2, 8)
File "odoo/tools/safe_eval.py", line 390, in safe_eval
return unsafe_eval(c, globals_dict, locals_dict)
File "ir.actions.server(344,)", line 1, in <module>
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 71, in _cron_schedule_next
recurrencies._repeat_slot(now + delta)
File "home/odoo/src/enterprise/saas-17.2/planning/models/planning_recurrency.py", line 89, in _repeat_slot
misc_recurrence_stop = recurrency._get_misc_recurrence_stop()
File "home/odoo/src/enterprise/saas-17.2/planning_contract/models/planning_recurrency.py", line 15, in _get_misc_recurrence_stop
('employee_id', '=', self.slot_ids.resource_id.employee_id.id),
File "odoo/fields.py", line 5183, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: <class 'ValueError'>: "Expected singleton: hr.employee(2, 8)" while evaluating
'model._cron_schedule_next()'
File "odoo/addons/base/models/ir_cron.py", line 388, in _callback
self.env['ir.actions.server'].browse(server_action_id).run()
File "home/odoo/src/custom/trial/saas_trial/models/sentry.py", line 33, in run
res = super().run()
File "odoo/addons/base/models/ir_actions.py", line 971, in run
res = runner(run_self, eval_context=eval_context)
File "odoo/addons/base/models/ir_actions.py", line 801, in _run_action_code_multi
safe_eval(self.code.strip(), eval_context, mode="exec", nocopy=True, filename=str(self)) # nocopy allows to return 'action'
File "odoo/tools/safe_eval.py", line 404, in safe_eval
raise ValueError('%s: "%s" while evaluating\n%r' % (ustr(type(e)), ustr(e), expr))
```
When the user changes the slot resource, the corn job runs based on recurrence.
Each recurrence may have multiple recordsets of slots which might have multiple resources.
But in the commit[1] a search query was used in which `id` is used instead of ids.
which leads to the traceback from [2].
Commit[1]: https://github.com/odoo/enterprise/pull/64845/commits/ff4cb88199349ac7507f7e526aeb3ed21c114c96
[2]
https://github.com/odoo/enterprise/blob/40711df5a635a9d2fd690ca53b271f0e7890cdb6/planning_contract/models/planning_recurrency.py#L15
After applying this commit, it will resolve this issue by using ids instead of id
sentry-5608817801
Forward-Port-Of: odoo/enterprise#66812Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#67059 Forward-Port-Of: odoo/enterprise#649
Original PR description
Steps to reproduce: - Start the tour and continue till the worksheet step - Click on worksheet stat button in the tour - Click on the worksheet name field Issue: - The tour continues. - An input fields needs to be inputted with something before moving on. Reason: - Incorrect configuration of trigger for this step Fix: - Re-target the trigger on input field and fix the run function task-3709542 Forward-Port-Of: odoo/enterprise#67059 Forward-Port-Of: odoo/enterprise#64956
The button is misaligned in the modal of the planning slot's portal view. This PR will realign it correctly. task-3943384 Forward-Port-Of: odoo/enterprise#63592
Original PR description
The button is misaligned in the modal of the planning slot's portal view. This PR will realign it correctly. task-3943384 Forward-Port-Of: odoo/enterprise#63592
Before this commit: The budget's committed and achieved calculations considered all categories of analytic lines, leading to incorrect calculations of the budget line's committed and achieved amounts. After this commit: - If the budget type is `expense` it will consider only analytic lines with the category vendor_bill. - If the budget type is `revenue` it will consider only analytic lines with the category invoice. - If the budget type is `both` it will consider analytic lines with b
Original PR description
Before this commit: The budget's committed and achieved calculations considered all categories of analytic lines, leading to incorrect calculations of the budget line's committed and achieved amounts. After this commit: - If the budget type is `expense` it will consider only analytic lines with the category vendor_bill. - If the budget type is `revenue` it will consider only analytic lines with the category invoice. - If the budget type is `both` it will consider analytic lines with both categories. Expected result: - Purchase order lines should not be considered in case of revenue budget. - In expense budget, income should not affect this budget at all. - In revenue budget, expense should not affect this budget at all. - In both budget, income and expense both should affect this budget. Task - 4002306 Forward-Port-Of: odoo/enterprise#65205