Wednesday, December 6, 2023
93 changes · master
Enhancements to existing features
This update prevents users from logging or linking timesheets to down payment sales lines, helping avoid incorrect billing records. It also makes overrun tasks easier to spot by showing progress above 100% consistently in red across task views and reports.
Original PR description
Before this commit: - project.task form view > it makes no sense to timesheet on a down payment as this is not the service that was sold to the customer. - users are not alerted that there are no remaining hours on the task as the information can be a bit hidden under the timesheets notebook After this commit: - project.task form view > it's not possible to select an SOL linked to a down payment for projects, tasks, timesheets and tickets. - project.task form view > the progress is displayed in red if > 100%. task-3476795 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
List view columns now resize more predictably when users adjust their width. Instead of changing the overall table width, the adjustment is balanced with a neighboring column, making list views easier to work with and less visually disruptive.
Original PR description
Impacted Version: - 16.4 or above This commit improve below features: - Improve list view resizing behaviour Originally resizing list view column will result in whole table width change. With this update, the width change on one column will resize the sibling th element width instead. 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
Bank statement demo data now uses today’s date for most transactions instead of setting everything to January 1. This makes demo and test scenarios, such as tax reporting checks, more representative across different reporting periods while keeping a small amount of start-of-year sample data.
Original PR description
Problem --------- The transaction dates of bank transactions in the demo data are all set to the 1st of January of the current year. In the scope of tests, that can be annoying. Let's say I want to check if the VAT on my bank fees has been included in the tax report: we won't find it depending on the tax report period. Objective --------- To keep some variety, keep 2 transactions and one statement on the 1st day of the year and set the other dates to today. Solution --------- Remove the date key in the demo data for the statements so that the current day is used by default (as described in account move). task-3607891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Indian companies can now choose whether to enable the audit trail feature instead of having it applied automatically. This gives businesses more control over compliance settings at the company level while keeping the option available when needed.
Original PR description
Before This Commit: Currently, the Audit trail feature is applied to all Indian companies. After This Commit: The audit trail feature is optional now. it can be enabled in the company. Task - 3614528
Customer follow-up reports now exclude miscellaneous journal entries by default, since these entries often do not reflect a customer's actual payment status. Users can still choose to include them manually when needed, helping teams focus follow-up activity on the most relevant outstanding items.
Original PR description
Miscellaneous entries are very often not relevant to the client "status" internally. This commits excludes these entries from the follow-up report by default. They can still be included manually. task-3604569 enterprise PR: https://github.com/odoo/enterprise/pull/52101
Demo data now leaves the Customer Addresses option turned off in Accounting settings. This keeps the demo experience cleaner and easier to navigate for users evaluating the system.
Original PR description
Addresses the issue where the Customer Addresses option in the Accounting settings complicates the user interface in demo mode. By unchecking this option in the demo data, the UI is simplified. task-3599641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Calendar events created by clicking directly in the calendar now respect the configured default event duration, instead of always using the standard one-hour length. This makes event creation more consistent for users and reduces manual adjustment when a business has set a preferred default duration.
Original PR description
Before this commit, when a default event duration was defined in ir.default, it was taken into acocunt in new form but not when the calendar view was clicked to create a new event. This commit allows to use this functionnality. By default the event duration is still 1 hour. taskid 3508596 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The time off accrual plan screens now use clearer labels and tooltips to help users understand how accrual rules work. This reduces confusion when configuring leave policies and makes the setup process easier for HR teams.
Original PR description
Several improvements can be made to the labels and tootips in accrual plan to improve the comprehension. task: 3594144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web editor now uses the current user's name already stored in the session instead of making an extra server request. This reduces unnecessary background work and can make collaboration features feel slightly more responsive.
Original PR description
There is no need for an rpc when the user name is already available in the session. task-3572119
Twitter/X social replies can include user mentions again after earlier restrictions were removed. The related anti-spam workaround and leftover cleanup code were removed, simplifying the Social and Twitter social integration while restoring expected reply behavior.
Original PR description
Purpose ======= In odoo/enterprise/pull/51752 , we remove the anti-spam system and we re-activated the mentions. This commit clean the methods / code that couldn't be removed in stable. Task-3615860
The website editor now better handles helpdesk ticket forms by letting the page template manage which helpdesk team is selected. This makes it clearer for editors which team’s form is being used and avoids showing unnecessary technical form details.
Original PR description
Before this commit, the editor on the website's help page did not display the name of the team whose ticket form was selected. This commit hides the form action data in the website editor since the template could manage itself the team to use in that form. task-3506482
The appointment module’s automated test was adjusted to match the default calendar duration. This helps keep internal quality checks aligned with current scheduling behavior, reducing false test failures without changing user-facing functionality.
Original PR description
taskid: 3508596
Follow-up reminders can now automatically add selected users as followers on the customer record when a configured follow-up step is run. This helps accountants and other responsible staff see replies in the customer chatter and avoid missing important payment-related responses.
Original PR description
Follow-up emails only appear in the partner chatter (since follow-ups are not their own dedicated model). The same holds for the (potential) reply of the partner to the email. If the accountant does not follow this chatter they may miss the reply. This commit adds a new option to the follow-up levels that allow adding users as followers of the partner chatter (when the follow-up level on which the option is set is executed). task-3604569 community PR: https://github.com/odoo/odoo/pull/144945
Grouped planning rows now use colors to show whether scheduled hours are below, matching, or above a resource’s available working time. This helps managers quickly spot underuse or overbooking while accounting for flexible hours, time off, and non-human resources.
Original PR description
In this commit, we add different colorings to the group rows (in the grouped gantt view) to indicate whether the planned hours are more (red), less (orange), or equal (green)to the resource's working hours for that day. task-3071699
Odoo Studio’s interface has been reorganized to reuse common visual components and remove duplicated or unused styling. This makes areas such as app creation, icon editing, sidebars, and search configuration more consistent and easier to maintain, with no major workflow changes expected for users.
Original PR description
Some css was not used anymore by components, and other styling rules were present in multiple locations, without using a consistent layout. Since the rewrite of Studio, the stylesheets were not modified and improved to match the component oriented paradigm. Scss mixins have been removed from the main 'mixins.scss' file. Some were not used, while others were only used once. Those rules have been moved directly to the desired stylesheet. This commit concerns mostly the App + Icon editors, the Sidebar and 'Add ... button hooks'. Many small other improvements can be seen in general in the studio app. The style should be more consistent accross similar elements, and inline css was moved to bootstrap classes as well. Tests affected by those changes have been adapted as well to match the latest classnames and remove some assertions no longer required since we now use less custom elements that could be replaced by components (e.g. Dropdown behaviors). task-3572251
This update makes time logging actions clearer, prevents users from recording timesheets against down payment sales lines, and improves guidance for field service invoicing. These changes reduce billing mistakes and make service-related workflows easier to understand.
Original PR description
Before this commit: - confirm time spent wizard: the implication of each button from the is not explicit. - it makes no sense to timesheet on a down payment as this is not the service that was sold to the customer. - the employee/SOL mapping tip is not accurate in field service as the behavior is a bit different there. After this commit: - confirm time spent wizard: buttons changed: save -> log time discard -> resume timer delete -> fa-trash icon 'discard' and 'delete' buttons are switched - it's not possible to select an SOL linked to a down payment for projects, tasks, timesheets, - project.project form view > invoicing notebook > the tip is different for fsm projects. task-3476795
When a spreadsheet is added to a dashboard, the original file in Documents is now automatically moved to trash. Users also receive a clear notification, reducing duplicate files and keeping Documents cleaner.
Original PR description
When the user clicks on "Add to dashboard", we should send the original spreadsheet to the trash in Documents and notify him that "The original spreadsheet has been sent to trash." TaskID: [3602669](https://www.odoo.com/web#id=3602669&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Resolved issues and error corrections
This fixes a recent regression that stopped users from creating sales order lines directly while working with project tasks. Restoring this option helps teams keep project work and customer billing details connected without extra steps.
Original PR description
The ability to create SOLs on the fly was mistakenly removed in a recent commit. This commit readds it.
Features or functions removed from Odoo
This removes older workaround code that is no longer needed after the website header redesign. It keeps the codebase simpler and reduces the chance of outdated fixes affecting future website behavior.
Original PR description
Commits [1] and [2] introduced separate fixes that are useless after the headers redesign in [3]. We remove the unneeded code in this commit. [1]: https://github.com/odoo/odoo/commit/e10913d [2]: https://github.com/odoo/odoo/commit/ce9b350 [3]: https://github.com/odoo/odoo/pull/119650 task-3576046
Miscellaneous changes
To make the module more accessible in its target country, add translations to the module. This mostly concerns error messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144942
Original PR description
To make the module more accessible in its target country, add translations to the module. This mostly concerns error messages. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144942
The web interface now correctly rejects malformed expressions like "[]a" instead of treating them as valid empty values. This helps prevent users from saving or using invalid filter/domain rules that could cause confusion or incorrect configuration.
Original PR description
Before this commit, py_js would parse successfully "[]a" and would return the ast corresponding to "[]". This would lead the domain selector (for instance) to recognize "[]a" as a valid domain.
The timesheet grid now correctly shows the add line button for each employee section again. This lets administrators add timesheet entries from the all timesheets view without a missing action blocking normal work.
Original PR description
Steps to reproduce: - Connect as an Admin - Go to all timesheets - Add line btn for each employee section is not displayed. Source: - By mistake, commit 2821b74 removed the return line if displayAddLine method. X-original-commit: 2821b74
Fixed an issue that caused an error when opening the Documents activity view in debug mode. Users can now access the activity view without interruption, improving reliability for document activity management.
Original PR description
Before this commit, When we try to open the activity view in debug mode it gives a traceback. Reason, After this [commit](https://github.com/odoo-dev/enterprise/commit/127f512b1a72957eb23c41103ecab44e1fdce0e7#diff-78d9f8faf609f35072d4b2617a9e13b3f137a679efb2c46c84acf29da4edfe46R67) the static props `fields` was added to the `DocumentsInspector` but the value is not passed from the `DocumentsActivityRenderer` which causes an issue. After this commit, The activity view will be open without any issue. task:- 3491723
Steps: - Open Appraisals - Go to Skills - Add new skill - Progress-bar was left-aligned in both rtl and ltr mode Issue: - progress-bar should always aligned to the right (it should be to the left only in rtl mode) in list view.In rtl mode, white space coming before progress-bar. Cause: - the progress bar alignment was inconsistent, especially when dealing with RTL languages . Fix: - By justifying the content of progress-bar to flex-end and of rtl mode to flex-start and by alignin
Original PR description
Steps: - Open Appraisals - Go to Skills - Add new skill - Progress-bar was left-aligned in both rtl and ltr mode Issue: - progress-bar should always aligned to the right (it should be to the left only in rtl mode) in list view.In rtl mode, white space coming before progress-bar. Cause: - the progress bar alignment was inconsistent, especially when dealing with RTL languages . Fix: - By justifying the content of progress-bar to flex-end and of rtl mode to flex-start and by aligning the progressbar-cell to start. Task: 3470978 Forward-Port-Of: odoo/odoo#134109
This traceback arises when the user tries to post multiple expense sheets of different employees. To reproduce this issue: 1) Install `hr_expense` 2) Open `Expenses/Expense Reports` 3) Select multiple expense sheets of different employees in list view 4) Make sure the selected recordsets status is `Approved` 5) Now click on the `Posted Entries` button Error:- ``` ValueError: too many values to unpack (expected 1) File "odoo/models.py", line 5457, in ensure_one _id, = s
Original PR description
This traceback arises when the user tries to post multiple expense sheets of different employees. To reproduce this issue: 1) Install `hr_expense` 2) Open `Expenses/Expense Reports` 3) Select…
This traceback arises when the user tries to post multiple expense sheets of different employees.
To reproduce this issue:
1) Install `hr_expense`
2) Open `Expenses/Expense Reports`
3) Select multiple expense sheets of different employees in list view
4) Make sure the selected recordsets status is `Approved`
5) Now click on the `Posted Entries` button
Error:-
```
ValueError: too many values to unpack (expected 1)
File "odoo/models.py", line 5457, in ensure_one
_id, = self._ids
ValueError: Expected singleton: hr.employee(10, 7, 15, 11, 6, 17, 13, 4)
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/saas-16.4/hr_expense_extract/models/hr_expense.py", line 224, in action_sheet_move_create
return super().action_sheet_move_create()
File "addons/hr_expense/models/hr_expense.py", line 1387, in action_sheet_move_create
self._check_can_create_move()
File "addons/hr_expense/models/hr_expense.py", line 1474, in _check_can_create_move
if not self.employee_id.work_email:
File "odoo/fields.py", line 1153, in __get__
record.ensure_one()
File "odoo/models.py", line 5460, in ensure_one
raise ValueError("Expected singleton: %s" % self)
```
https://github.com/odoo/odoo/blob/655c408d319a14cc9b972d4f49816c91fb502b22/addons/hr_expense/models/hr_expense.py#L1474-L1475
After applying this commit will resolve the issue by looping the recordset.
sentry-4595012933
Forward-Port-Of: odoo/odoo#144137
Forward-Port-Of: odoo/odoo#140906## Steps to reproduce: 1. Create a BoM with a component of 1 quantity 2. Create a manufacturing order with this BoM 3. Set the quantity to produce to 5 and confirm 4. Set the producing quantity to 3.1 5. Set the quantity done for the raw material to 3.09 6. Mark the MO as done and create a backorder 7. Click 'Unreserve' on the backorder 8. 'It is not possible to unreserve more products of ...' ## Before this commit: `_compute_quantity` is called with the default rounding method, roun
Original PR description
## Steps to reproduce: 1. Create a BoM with a component of 1 quantity 2. Create a manufacturing order with this BoM 3. Set the quantity to produce to 5 and confirm 4. Set the producing quantity to 3.1 5. Set the quantity done for the raw material to 3.09 6. Mark the MO as done and create a backorder 7. Click 'Unreserve' on the backorder 8. 'It is not possible to unreserve more products of ...' ## Before this commit: `_compute_quantity` is called with the default rounding method, rounding quantity UP, which introduces reservation inconsistencies. ## After this commit: `_compute_quantity` rounds with the HALF-UP method, preventing rounding errors. Also, use the correct UoM in float comparisons. opw-3601737 Forward-Port-Of: odoo/odoo#144620 Forward-Port-Of: odoo/odoo#144176
On a company with branches, you can move an amount from a branch company account to a parent company account using "Move to Account" action. This will create a new entry with both accounts. If this entry is created on the parent company, it will trigger an error since parent company does not have access to branch company accounts. Steps to reproduce - Have a company with a branch company - Create an account belonging to the branch company - Create an entry with this account - Select paren
Original PR description
On a company with branches, you can move an amount from a branch company account to a parent company account using "Move to Account" action. This will create a new entry with both accounts. If this entry is created on the parent company, it will trigger an error since parent company does not have access to branch company accounts. Steps to reproduce - Have a company with a branch company - Create an account belonging to the branch company - Create an entry with this account - Select parent company and go to journal item list - Select one item with the account created above and use the action "Move to Account" - Try to move to an account of parent company => Company access error Now we create the entry on the lowest child company. opw-3554088 Forward-Port-Of: odoo/odoo#144508
# Issue: The name_search performance was highly inefficient with a high number of records. # Analyze: The bottleneck came from the NOT IN search on the product_template. # Fix: As a NOT IN is not efficient, an not exists must be used. # Note: The ORM has to be bypassed has no "not exists" feature has been implemented yet. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 182386 | 15+ min | ~100
Original PR description
# Issue: The name_search performance was highly inefficient with a high number of records. # Analyze: The bottleneck came from the NOT IN search on the product_template. # Fix: As a NOT IN is not efficient, an not exists must be used. # Note: The ORM has to be bypassed has no "not exists" feature has been implemented yet. # Benchmark: | # Input data | Before PR | After PR | |:-------------:|:----------:|:---------:| | 182386 | 15+ min | ~100 ms | | 29 | ~29 ms | ~28 ms | # Related task: opw-3554133 Forward-Port-Of: odoo/odoo#145004 Forward-Port-Of: odoo/odoo#143543
-According VietNam Circular , Receivable account we should use for POS is 131 account, not 132 see https://thuvienphapluat.vn/van-ban/Doanh-nghiep/Thong-tu-200-2014-TT-BTC-huong-dan-Che-do-ke-toan-Doanh-nghiep-263599.aspx , select English version - Section 'Short-term receivables from customers' to read it and we will see 132 account is not appropriate  --- I confirm I have signed the CLA a
Original PR description
-According VietNam Circular , Receivable account we should use for POS is 131 account, not 132 see https://thuvienphapluat.vn/van-ban/Doanh-nghiep/Thong-tu-200-2014-TT-BTC-huong-dan-Che-do-ke-toan-Doanh-nghiep-263599.aspx , select English version - Section 'Short-term receivables from customers' to read it and we will see 132 account is not appropriate  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144974 Forward-Port-Of: odoo/odoo#144115
This commit allows the navigation inside the Control Panel to fill all the container height. Prior to this commit, the navigation arrows inside the control panel were not taking the whole height of the container, which would cause a weird visual render where everything would have exactly the same height except these elements. To fix the issue, we adapt some of the flex properties used in the layout, ensuring everything is well aligned. task-3580216 Forward-Port-Of: odoo/odoo#140670
Original PR description
This commit allows the navigation inside the Control Panel to fill all the container height. Prior to this commit, the navigation arrows inside the control panel were not taking the whole height of the container, which would cause a weird visual render where everything would have exactly the same height except these elements. To fix the issue, we adapt some of the flex properties used in the layout, ensuring everything is well aligned. task-3580216 Forward-Port-Of: odoo/odoo#140670
In [1], jQueryUI drag and drop was removed and replace by an in-house solution. This version introduced a difficulty when dragging and dropping content when the dropzones are overlapping. This commit tries to mitigate that by always choosing the dropzone that is the closest to the helper element displayed when dragging. [1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76 task-3577109 Forward-Port-Of: odoo/odoo#143167
Original PR description
In [1], jQueryUI drag and drop was removed and replace by an in-house solution. This version introduced a difficulty when dragging and dropping content when the dropzones are overlapping. This commit tries to mitigate that by always choosing the dropzone that is the closest to the helper element displayed when dragging. [1]: https://github.com/odoo/odoo/commit/7594d71ca8610d5947e80f325ccb57abc23c2c76 task-3577109 Forward-Port-Of: odoo/odoo#143167
When dragging a snippet inside an iframe, after the snippet has been dropped, all events are still being captured by the iframe. This leads to option previews not being displayed and the user having to click outside the iframe to be able to interact with the options. This seems to be a bug in Firefox related to how it handles pointerevents. This does not happen when the events are "mousedown" and "mouseup" instead of "pointerdown" and "pointerup". So this commit checks if we're on firefox des
Original PR description
When dragging a snippet inside an iframe, after the snippet has been dropped, all events are still being captured by the iframe. This leads to option previews not being displayed and the user having to click outside the iframe to be able to interact with the options. This seems to be a bug in Firefox related to how it handles pointerevents. This does not happen when the events are "mousedown" and "mouseup" instead of "pointerdown" and "pointerup". So this commit checks if we're on firefox desktop and if its the case, uses mousedown and mouseup. Steps to reproduce: - On Firefox, go to the Website App and drop a banner snippet - Click on one of the images in the snippet - Drag the image - Hover over the options => The options are not previewed task-3607685 Forward-Port-Of: odoo/odoo#143343
runbot-46626 Forward-Port-Of: odoo/odoo#144901
Original PR description
runbot-46626 Forward-Port-Of: odoo/odoo#144901
The payment method line set on the expense sheet isn't the one used on the payment. The 'print check' payment method test, requiring the 'account_check_printing' installation and that module not being in hr_expense dependencies would fail if both weren't installed. A new and more method-agnostic test replaces it Task-3498991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145017 Forward-Port-Of: odoo/odoo#1419
Original PR description
The payment method line set on the expense sheet isn't the one used on the payment. The 'print check' payment method test, requiring the 'account_check_printing' installation and that module not being in hr_expense dependencies would fail if both weren't installed. A new and more method-agnostic test replaces it Task-3498991 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145017 Forward-Port-Of: odoo/odoo#141946
The clean_attachment was invalidation the cache before 16.4, mainly because if an attachment is in cache of another worker and deleted, this will cause a 404 when this worker serves a page needing this attachment. This was changed because an attachment should be unlink through clean_attachments in two cases: - the code source changed on the server and a cold worker generates a bundle - an ir_asset was modified In the first case, we consider that the server restarted (normally) and all ca
Original PR description
The clean_attachment was invalidation the cache before 16.4, mainly because if an attachment is in cache of another worker and deleted, this will cause a 404 when this worker serves a page needing this attachment. This was changed because an attachment should be unlink through clean_attachments in two cases: - the code source changed on the server and a cold worker generates a bundle - an ir_asset was modified In the first case, we consider that the server restarted (normally) and all caches should be emptied. In the second case, a specific invalidation is made. But when something goes wrong, it is hard to debug, especially because there is no information on when the new attachment was created, and the previous one deleted. This should solve the issue by helping to identify the cause of the deletion. Forward-Port-Of: odoo/odoo#143962 Forward-Port-Of: odoo/odoo#143765
This commit increase the receipt size on the receipt screen and shrink the new order button to fit the new size. Old:  New:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143292
Original PR description
This commit increase the receipt size on the receipt screen and shrink the new order button to fit the new size. Old:  New:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#143292
When a dropdown open a dialog and on the dialog there is a new dropdown, before this commit, when clicking on the second dropdown, the first one will close. This is an issue with closing the first dropdown, is if the dialog is opened using useOwnedDialogs, the dialog will also close. Also, if the dialog is open to throw a "find more" of a x2many field, even if the dialog is not close, as the dropdown will close, the original field will also be destroyed and it will raise an error. Now,
Original PR description
When a dropdown open a dialog and on the dialog there is a new dropdown, before this commit, when clicking on the second dropdown, the first one will close. This is an issue with closing the first dropdown, is if the dialog is opened using useOwnedDialogs, the dialog will also close. Also, if the dialog is open to throw a "find more" of a x2many field, even if the dialog is not close, as the dropdown will close, the original field will also be destroyed and it will raise an error. Now, we avoid closing dropdown's, when opening new dropdowns that there are not on the same active element. opw-3464528 Forward-Port-Of: odoo/odoo#144238 Forward-Port-Of: odoo/odoo#144119
Change the category count display in the order button. From:  To:  Forward-Port-Of: odoo/odoo#143298
Original PR description
Change the category count display in the order button. From:  To:  Forward-Port-Of: odoo/odoo#143298
In v17.0, the test TestUiPublisher.test_course_publisher_elearning_manager of website_slides fails randomly at the step: "eLearning: check uploaded pdf presence and perform comparison" with the error: "Cannot read properties of null (reading 'getAttribute')" How to reproduce it ? Locally, TestUiPublisher.test_course_publisher_elearning_manager of website_slides runs without errors but when executing it in the browser we get the same error as the runbot systematically: – Install website_slid
Original PR description
In v17.0, the test TestUiPublisher.test_course_publisher_elearning_manager of website_slides fails randomly at the step: "eLearning: check uploaded pdf presence and perform comparison" with the…
In v17.0, the test TestUiPublisher.test_course_publisher_elearning_manager of website_slides fails randomly at the step: "eLearning: check uploaded pdf presence and perform comparison" with the error: "Cannot read properties of null (reading 'getAttribute')"
How to reproduce it ?
Locally, TestUiPublisher.test_course_publisher_elearning_manager of website_slides runs without errors but when executing it in the browser we get the same error as the runbot systematically:
– Install website_slides
– Go to shell mode and execute the setup of the test – (Backup DB if you want to run the test multiple time) – Launch in normal mode and connect with demo user – Go to URL: /web?debug=assets%2Ctests
– Type “odoo.startTour('course_publisher_standard');” in the console – An error happens at step “eLearning: check uploaded pdf presence and perform comparison”: Cannot read properties of null (reading 'getAttribute') (to avoid to wait too long, you can shorten the test by keeping mostly “addPdfToSection”)
The problem occurs because the rendering of the iframe o_wslides_iframe_viewer is not always completed when the check is triggered. We solve this problem by waiting for the rendering to finish before performing the test (using "await contains"). For safety, we do the same for another check as this might cause a similar problem in the future.
Although the test has been introduced in 16.2 (see odoo/odoo#117293) but the error happens only in 17.0 (tested only in 16.4 the way described above), we publish only the correction in 17.0 and further to avoid different correction in various version.
Task-3623736
Forward-Port-Of: odoo/odoo#144719Steps to reproduce the bug: - Create a consumable product: - Create a BoM - Attempt to access the BoM overview Problem: An error is triggered: "Caused by: TypeError: value.toFixed is not a function" This error occurs when attempting to format the float value of the available quantity for a consumable product, where the function is called with `value: False`: https://github.com/odoo/odoo/blob/054ca0a19aaf297f420a1b478b93ae26f1b943b8/addons/web/static/src/core/utils/numbers.j
Original PR description
Steps to reproduce the bug:
- Create a consumable product:
- Create a BoM
- Attempt to access the BoM overview
Problem:
An error is triggered:
"Caused by: TypeError: value.toFixed is not a function"
This error occurs when attempting to format the float value of the
available quantity for a consumable product, where the function is
called with `value: False`:
https://github.com/odoo/odoo/blob/054ca0a19aaf297f420a1b478b93ae26f1b943b8/addons/web/static/src/core/utils/numbers.js#L192
opw-[3622251](https://www.odoo.com/web#id=3622251&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#144988Purpose ======= If we buy a course without being logged in, we are redirected to a page with a button "Start Learning". That button redirects to the course we just purchased. Instead, we want to redirect the user to the login page, and after he login to the course page. Task-3544591 Forward-Port-Of: odoo/odoo#138377
Original PR description
Purpose ======= If we buy a course without being logged in, we are redirected to a page with a button "Start Learning". That button redirects to the course we just purchased. Instead, we want to redirect the user to the login page, and after he login to the course page. Task-3544591 Forward-Port-Of: odoo/odoo#138377
Steps to reproduce: - create a bill - add a product line - add a payment reference - save it - change the payment ref - confirm - register a payment Issue: The memo is not the updated payment reference Cause: The memo is computed by taking in priority the `line.name` https://github.com/odoo/odoo/blob/a39050e15195eb095b3480899cedb5cb458fa6cc/addons/account/wizard/account_payment_register.py#L139-L145 And whenever we change the payment reference, the line.name is not recomputed
Original PR description
Steps to reproduce: - create a bill - add a product line - add a payment reference - save it - change the payment ref - confirm - register a payment Issue: The memo is not the updated payment reference Cause: The memo is computed by taking in priority the `line.name` https://github.com/odoo/odoo/blob/a39050e15195eb095b3480899cedb5cb458fa6cc/addons/account/wizard/account_payment_register.py#L139-L145 And whenever we change the payment reference, the line.name is not recomputed if it has already been set opw-3476835 Forward-Port-Of: odoo/odoo#144362 Forward-Port-Of: odoo/odoo#135923
Before this commit, when a record is in draft, the chatter message "Creating a new record..." shown no author. The intended showing is to display current user as author of this message. Persona model requires `id` and `type`, the latter to determine whether the persona is a guest or partner. Only the id of current user was provided, so it was not enough to determine the appropriate `Persona`. Forward-Port-Of: odoo/odoo#144864
Original PR description
Before this commit, when a record is in draft, the chatter message "Creating a new record..." shown no author. The intended showing is to display current user as author of this message. Persona model requires `id` and `type`, the latter to determine whether the persona is a guest or partner. Only the id of current user was provided, so it was not enough to determine the appropriate `Persona`. Forward-Port-Of: odoo/odoo#144864
1. [REF] mail: field.onAdd/Delete & record.delete at end of update cycle 2. [FIX] mail: insert data in relational field 3. [FIX] mail: lazy fields not properly recomputed 4. [FIX] mail: invoke onAdd/onDelete hooks on inverse relational field Forward-Port-Of: odoo/odoo#144999
Original PR description
1. [REF] mail: field.onAdd/Delete & record.delete at end of update cycle 2. [FIX] mail: insert data in relational field 3. [FIX] mail: lazy fields not properly recomputed 4. [FIX] mail: invoke onAdd/onDelete hooks on inverse relational field Forward-Port-Of: odoo/odoo#144999
Before this commit, pasting html content that had been copied from the the Editor failed to paste any content when inside an iframe. This happened because the DOMPurify library was not configured to use the iframe's window for Node prototypes, which led `instanceof` checks to fail, removing nodes a result. Additionally, commit [1] did not do the job completely: while the document for creating the document fragment became the one received as parameter, the DOMParser constructor remained the
Original PR description
Before this commit, pasting html content that had been copied from the the Editor failed to paste any content when inside an iframe. This happened because the DOMPurify library was not configured to use the iframe's window for Node prototypes, which led `instanceof` checks to fail, removing nodes a result. Additionally, commit [1] did not do the job completely: while the document for creating the document fragment became the one received as parameter, the DOMParser constructor remained the one from the window in which the JS code is executed, which might be different from the received document's window. This mismatch happens in particularly when the editable is inside an iframe. task-3575496 [1]: https://github.com/odoo/odoo/commit/c74d01279e49fadc5f509cfc3f6baf43d2b532d1 Forward-Port-Of: odoo/odoo#144744
Issue: ====== When we use the website in a language different the the partner lang , it will always display `Free product` in the partner language. Steps to reproduce: =================== - Create a loyalty program that gives a free product - Install another lang (FR for example) apply it for website too - Go to website and change lang to FR - Added the product which gives the free product promotion - Go to cart Origin of the issue: ==================== The lang was forced as pa
Original PR description
Issue: ====== When we use the website in a language different the the partner lang , it will always display `Free product` in the partner language. Steps to reproduce: =================== - Create a loyalty program that gives a free product - Install another lang (FR for example) apply it for website too - Go to website and change lang to FR - Added the product which gives the free product promotion - Go to cart Origin of the issue: ==================== The lang was forced as partner language in displaying the free product name. Solution: ========= For frontend request related to ecommerce orders, keep the request lang to have the cart content in the website language, not in the partner one. opw-3593505 Forward-Port-Of: odoo/odoo#145122 Forward-Port-Of: odoo/odoo#143364
The `noCheck` param of the `_computeSelectorFunctions` function should permit to ignore the (not)editable environment. However, since [this first commit] the `o_editable_media` class alter the behavior despite the `noCheck` param which is not what we want. Even worse, [this second commit] check the `o_not_editable` class and the contenteditable attribute despite the `noCheck` param. This commit fixes that by restoring the original behavior of the `noCheck` param. --- In the past, it
Original PR description
The `noCheck` param of the `_computeSelectorFunctions` function should permit to ignore the (not)editable environment. However, since [this first commit] the `o_editable_media` class alter the…
The `noCheck` param of the `_computeSelectorFunctions` function should permit to ignore the (not)editable environment. However, since [this first commit] the `o_editable_media` class alter the behavior despite the `noCheck` param which is not what we want. Even worse, [this second commit] check the `o_not_editable` class and the contenteditable attribute despite the `noCheck` param. This commit fixes that by restoring the original behavior of the `noCheck` param. --- In the past, it was possible to drop elements in non-editable areas. Commit [1] fixed the issue but then commit [2] added a solution to be able to edit a media element that is in a `o_not_editable` environment. Unfortunately, the solution makes it possible to drop elements next to the `o_editable_media` elements ignoring the editable context (ignoring the first fix). Steps to reproduce the issue: - Enter website edit mode - Drop a Team block in a page => The user is able to drop a "Text highlight" block next to the team member pictures. This commit - reverts the commit [1] because in the meantime, the commit [3] fixed the issue. - fixes the Team block issue. - fixes the filterFunc for the drop-in. - adds a test to ensure the issue doesn't come back. opw-3536227 [1]: https://github.com/odoo/odoo/commit/67924648676b37898aedd86bc32868299aee542c [2]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904 [3]: https://github.com/odoo/odoo/commit/ae7452f18dbd6ed56dbf883ae8495382b336aa78 [this first commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904 [this second commit]: https://github.com/odoo/odoo/commit/56e75ed063b0ae98b9824c0ba00633e529701242 Forward-Port-Of: odoo/odoo#144806 Forward-Port-Of: odoo/odoo#141962
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his address, `payment_term_id` is set to `partner_id.property_payment_term_id` because [onchange_partner_id][2] is triggered. This means that `payment_term_id` is computed differently if the user edits his address before confirming the order or not. (Resulting in it being `False` most of the time).
Original PR description
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his…
__Current behavior before commit:__ When a sale order is created when a website user adds an product in his cart, `payment_term_id` is set by [sale_get_payment_term][1]. But when the user sets his address, `payment_term_id` is set to `partner_id.property_payment_term_id` because [onchange_partner_id][2] is triggered. This means that `payment_term_id` is computed differently if the user edits his address before confirming the order or not. (Resulting in it being `False` most of the time). __Description of the fix:__ Inherit [onchange_partner_id][2] to set `payment_term_id` using [sale_get_payment_term][1] from the **website_sale** module. __Steps to reproduce the issue on runbot:__ - Add a product to the cart through the website. → A new sale order will be created with payment terms set. - Proceed to checkout and edit the address on the website → The sale order payment terms will be removed opw-3492868 [1]: https://github.com/odoo/odoo/blob/96b0939554101be2e93d88787d3978929b23e67c/addons/website_sale/models/website.py#L202 [2]: https://github.com/odoo/odoo/blob/96b0939554101be2e93d88787d3978929b23e67c/addons/sale/models/sale.py#L413 Forward-Port-Of: odoo/odoo#145023 Forward-Port-Of: odoo/odoo#136311
Before this commit, to be sure to wait for all the RPC are finished before continue, the clickbot, patched the ORM class and saved in a waiting list the model and method called, and removed when finished. The issue with this, is that when calling an ORM with a protected RPC service (as is the case for the BatcherORM), if the caller component is destroyed before the return of the RPC, as the RPC service is protected it will return an always pending promise, and the RPC will never be remo
Original PR description
Before this commit, to be sure to wait for all the RPC are finished before continue, the clickbot, patched the ORM class and saved in a waiting list the model and method called, and removed when finished. The issue with this, is that when calling an ORM with a protected RPC service (as is the case for the BatcherORM), if the caller component is destroyed before the return of the RPC, as the RPC service is protected it will return an always pending promise, and the RPC will never be removed from the waiting list and the clickbot will wait indefinitely. Now, we use the RPC event directly, so even if the component is destroyed, we know that the RPC was finished, and is removed from the waiting list. Note that, this commit doesn't have a test, making a test for this case is quite difficult, and some of the causes of the issue will be removed in future versions. Forward-Port-Of: odoo/odoo#145081 Forward-Port-Of: odoo/odoo#144788
Problem -------- In ver 16, field payment_state of model hr_expense_sheet use _fields[] to get item selection field payment_state of account_move. This causes the file translation of this module to not accept the description item of field payment_state This commit ------ Use the PAYMENT_STATE_SELECTION of account_move as the selection value of payment_state (hr_expense_sheet) ### Please help me with this or is there any other way to translate the descriptiom item of fields payment_sta
Original PR description
Problem -------- In ver 16, field payment_state of model hr_expense_sheet use _fields[] to get item selection field payment_state of account_move. This causes the file translation of this module to not accept the description item of field payment_state This commit ------ Use the PAYMENT_STATE_SELECTION of account_move as the selection value of payment_state (hr_expense_sheet) ### Please help me with this or is there any other way to translate the descriptiom item of fields payment_state, Thanks a lot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144861 Forward-Port-Of: odoo/odoo#142458
This PR fixes small issues when there is not selectedLine in some cases. We also add the price_without_discount for the printing because of some localisation issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144323
Original PR description
This PR fixes small issues when there is not selectedLine in some cases. We also add the price_without_discount for the printing because of some localisation issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144323
Multi-currency setup. On a bill, if the bill date and the accounting date are not the same, there will be some errors in the stock valuation. To reproduce the issue: (Company in USD) 1. Enable EUR, with specific rates: - Today: 100 EUR = 150 USD - One day ago: 100 EUR = 130 USD - Two days ago: 100 EUR = 125 USD 2. Create an auto-avco storable product P 3. Confirm a PO with 1 x P at 100 EUR 4. Receive the product 5. Bill it: - Bill date: two days ago - Accounting da
Original PR description
Multi-currency setup. On a bill, if the bill date and the accounting date are not the same, there will be some errors in the stock valuation. To reproduce the issue: (Company in USD) 1. Enable EUR, with specific rates: - Today: 100 EUR = 150 USD - One day ago: 100 EUR = 130 USD - Two days ago: 100 EUR = 125 USD 2. Create an auto-avco storable product P 3. Confirm a PO with 1 x P at 100 EUR 4. Receive the product 5. Bill it: - Bill date: two days ago - Accounting date: one day ago 6. Open the inventory valuation Error: a price diff layer has been created, which makes sense, but its value is incorrect: -20 USD. It should be -25 USD. When computing the price difference, we use the bill value at accounting date (130 USD). This is incorrect, it should be based on the bill date (125 USD). OPW-3544318 Forward-Port-Of: odoo/odoo#144649 Forward-Port-Of: odoo/odoo#144500
-16.0 ----- step to produce : --------- - go to project - click on any project in the Kanban view - click on the quick create button - notice caret at assignees dropdown issue: ----- - at the assignees dropdown the caret position is at the far right and not aligned with the discard/trash button Cause: ------ - changes which happened in task-2944742 added left margin for user_ids field , which then moved the position of caret. Solution: ----- - changed css to just apply th
Original PR description
-16.0 ----- step to produce : --------- - go to project - click on any project in the Kanban view - click on the quick create button - notice caret at assignees dropdown issue: ----- - at the assignees dropdown the caret position is at the far right and not aligned with the discard/trash button Cause: ------ - changes which happened in task-2944742 added left margin for user_ids field , which then moved the position of caret. Solution: ----- - changed css to just apply the margin at bottom right for M2M avatar at kanban and stopped it from affecting user_ids field in quick create task. task-3506482 Forward-Port-Of: odoo/odoo#144842 Forward-Port-Of: odoo/odoo#141191
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Expense Report'. --- **Issue:** - When viewing the department's expense in the employee module, all data of state wiith submit and approved is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request inf
Original PR description
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Expense Report'. --- **Issue:** - When viewing the department's expense in the employee module, all data of state wiith submit and approved is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/odoo#138993
Simplify the workflow in Spanish PoS regarding simplified invoices. - Setup a default journal for simplified invoices. - Label of Simple Invoice Journal was displayed even on non-spanish companies. - Adds an error if you try to create an order without invoice when the amount is too high. - Enforce our conventions on the compute names and file format. - Add translation files. task-id: 3598884 Forward-Port-Of: odoo/odoo#142345
Original PR description
Simplify the workflow in Spanish PoS regarding simplified invoices. - Setup a default journal for simplified invoices. - Label of Simple Invoice Journal was displayed even on non-spanish companies. - Adds an error if you try to create an order without invoice when the amount is too high. - Enforce our conventions on the compute names and file format. - Add translation files. task-id: 3598884 Forward-Port-Of: odoo/odoo#142345
**Before this commit:** If you select more than one trigger field on base.automation: ``` File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in _compute_trg_field_ref__model_and_display_names relation = automation.trigger_field_ids.relation File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1146, in __get__ record.ensure_one() File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5819, in ensure_one raise ValueError("Expected singleton: %s" % self
Original PR description
**Before this commit:** If you select more than one trigger field on base.automation: ``` File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in…
**Before this commit:**
If you select more than one trigger field on base.automation:
```
File "/home/odoo/src/odoo/17.0/addons/base_automation/models/base_automation.py", line 302, in _compute_trg_field_ref__model_and_display_names relation = automation.trigger_field_ids.relation
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1146, in __get__ record.ensure_one()
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5819, in ensure_one raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.model.fields(<NewId origin=3241>, <NewId origin=3238>)
```
**After this commit:**
`trg_field_ref_model_name` and `trg_field_ref_display_name` are only used for the `base_automation_trigger_reference` widget, which is only used when `trigger in ['on_stage_set', 'on_tag_set']`. We only need to compute them in this case, which will be OK since they use only one trigger field.
opw-3607314
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#144810Before this commit, when restarting the synchronization, recurrence outliers were blocking the synchronization restarting because they were being considered as complete recurrences, although they must be treated as single events. Additionaly, when resetting the Outlook account, choosing to delete events in Odoo should not be allowed since recurrence outliers must be treated as single events. After this commit, this issue is now solved by adding the 'dont_notify' param in the context to skip t
Original PR description
Before this commit, when restarting the synchronization, recurrence outliers were blocking the synchronization restarting because they were being considered as complete recurrences, although they must be treated as single events. Additionaly, when resetting the Outlook account, choosing to delete events in Odoo should not be allowed since recurrence outliers must be treated as single events. After this commit, this issue is now solved by adding the 'dont_notify' param in the context to skip the validation of single events when restarting the sync. Additionaly, when resetting the Outlook account, the forbiddance of deleting events in Odoo is not a blocking point anymore. Task-id: 3617978 Forward-Port-Of: odoo/odoo#144928 Forward-Port-Of: odoo/odoo#144320
Forward-Port-Of: odoo/odoo#145012
Original PR description
Forward-Port-Of: odoo/odoo#145012
Somehow the module disappeared from the file between versions 16.0 and saas-16.1 even though the .po files exist (up to + including saas-16.2). Further investigation/fixing will occur later on to check overall consistency correctly, this commit is only a quick fix to get the translations working properly for this specific module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145044 Forward-Port-Of: odoo/odoo#14442
Original PR description
Somehow the module disappeared from the file between versions 16.0 and saas-16.1 even though the .po files exist (up to + including saas-16.2). Further investigation/fixing will occur later on to check overall consistency correctly, this commit is only a quick fix to get the translations working properly for this specific module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145044 Forward-Port-Of: odoo/odoo#144420
### Issue : When calling get_work_duration_data on a calendar that contains adjacent calendar attendances, we get a traceback in the method `_get_attendance_intervals_days_data.` This is due to the fact that adjacent attendances (like 09:00 -> 13:00, 13:00 -> 17:00) will get merged into one single interval. Which will generate an attendance interval with multiple `resource.calendar.attendance` records associated with it. ### Steps to reproduce : 1) Create a Calendar 2) Create for a same da
Original PR description
### Issue : When calling get_work_duration_data on a calendar that contains adjacent calendar attendances, we get a traceback in the method `_get_attendance_intervals_days_data.` This is due to the…
### Issue : When calling get_work_duration_data on a calendar that contains adjacent calendar attendances, we get a traceback in the method `_get_attendance_intervals_days_data.` This is due to the fact that adjacent attendances (like 09:00 -> 13:00, 13:00 -> 17:00) will get merged into one single interval. Which will generate an attendance interval with multiple `resource.calendar.attendance` records associated with it. ### Steps to reproduce : 1) Create a Calendar 2) Create for a same day 2 attendances going from 09:00 to 13:00 and another going from 13:00 to 17:00 3) Try creating a time-off for that day 3) Associate that calendar with an employee 4) Try creating a time off on the day where we have adjacent attendances ### Fix: Adapt `_get_attendance_intervals_days_data` to handle attendance intervals associated with multiple resource.calendar.attendance task-3615723 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#144036
### Steps to reproduce: 1. install Employee app 2. install HR Gamification module (not an app) 3. Go to Employees app 4. Go to Configuration > Challenges > Challenges 5. Create a new challenge with goals and participants 6. Go to Configuration > Challenges > Goals History 7. Open up a group 8. The word "Completeness" and the progress bar is not aligned correctly, the bar is supposed to be directly underneath the label. ### Investigation - The styling of the progress bar inside tabl
Original PR description
### Steps to reproduce: 1. install Employee app 2. install HR Gamification module (not an app) 3. Go to Employees app 4. Go to Configuration > Challenges > Challenges 5. Create a new challenge with goals and participants 6. Go to Configuration > Challenges > Goals History 7. Open up a group 8. The word "Completeness" and the progress bar is not aligned correctly, the bar is supposed to be directly underneath the label. ### Investigation - The styling of the progress bar inside table cells https://github.com/odoo/odoo/blob/1f12670a8061a4eb3fd57abca238d8daf7ef574d/addons/web/static/src/views/fields/progress_bar/progress_bar_field.scss#L27-L32 was missing to align the progress bar to the end of the containing flex box opw-3599052 Forward-Port-Of: odoo/odoo#145102 Forward-Port-Of: odoo/odoo#143290
The digits of the accounts of Lithuania's COA go up to 6. It's currently defined to 1, which makes no sense. We will change it to 6. 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#143986
Original PR description
The digits of the accounts of Lithuania's COA go up to 6. It's currently defined to 1, which makes no sense. We will change it to 6. 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#143986
Same as what was done: - in 2019 for favicon.ico at [1]. - in 2018 for sitemap.xml at [2]. - in 2015 for many controllers at [3]. Note that it's not about crawlers/robots, because those won't go through the lang redirect (see `is_a_bot()`). It's just to avoid a redirect which has no meaning/sense when requested by real users. /robots.txt is not language dependent. [1]: https://github.com/odoo/odoo/commit/94bcbc92e5e5a6fd3de7267e3c01f8c11fb045f4 [2]: https://github.com/odoo/odoo/co
Original PR description
Same as what was done: - in 2019 for favicon.ico at [1]. - in 2018 for sitemap.xml at [2]. - in 2015 for many controllers at [3]. Note that it's not about crawlers/robots, because those won't go through the lang redirect (see `is_a_bot()`). It's just to avoid a redirect which has no meaning/sense when requested by real users. /robots.txt is not language dependent. [1]: https://github.com/odoo/odoo/commit/94bcbc92e5e5a6fd3de7267e3c01f8c11fb045f4 [2]: https://github.com/odoo/odoo/commit/708ad186d52aff9270ea73888326370ada2fbc71 [3]: https://github.com/odoo/odoo/commit/a696913364ffc4d5f1ce0675bc9be82f84f3ff93 Forward-Port-Of: odoo/odoo#145018
Create a vendor bill Input any value in the "payment reference field" > save Payment line name will be set to the payment reference Remove the value > save Issue: Payment line name will be unchanged Register payment In the payment wizard, the "memo" field will be filled with the old payment reference. opw-3596003 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
Original PR description
Create a vendor bill Input any value in the "payment reference field" > save Payment line name will be set to the payment reference Remove the value > save Issue: Payment line name will be unchanged Register payment In the payment wizard, the "memo" field will be filled with the old payment reference. opw-3596003 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#145054 Forward-Port-Of: odoo/odoo#143511
When the user creates a new customer and enters "." in Identification Number, a traceback will appear. Steps to reproduce the error: - Install "l10n_cl" module - Switch to Chile Company - Go to Invoicing > Customers > Create New Customer > Enter Name > Select 'Chile' in Country > Enter "." in Identification Number > Save Traceback: ``` IndexError: string index out of range File "odoo/http.py", line 2139, in __call__ response = request._serve_db() File "odoo/http.py", li
Original PR description
When the user creates a new customer and enters "." in Identification Number, a traceback will appear. Steps to reproduce the error: - Install "l10n_cl" module - Switch to Chile Company - Go to…
When the user creates a new customer and enters "." in Identification Number,
a traceback will appear.
Steps to reproduce the error:
- Install "l10n_cl" module
- Switch to Chile Company
- Go to Invoicing > Customers > Create New Customer > Enter Name >
Select 'Chile' in Country > Enter "." in Identification Number > Save
Traceback:
```
IndexError: string index out of range
File "odoo/http.py", line 2139, in __call__
response = request._serve_db()
File "odoo/http.py", line 1715, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1742, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1943, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 717, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 30, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 26, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 464, in call_kw
result = _call_kw_model_create(method, model, args, kwargs)
File "odoo/api.py", line 444, in _call_kw_model_create
result = method(recs, *args, **kwargs)
File "<decorator-gen-490>", line 2, in create
File "odoo/api.py", line 414, in _model_create_multi
return create(self, [arg])
File "addons/l10n_cl/models/res_partner.py", line 55, in create
vals['vat'] = self._format_vat_cl(vals)
File "addons/l10n_cl/models/res_partner.py", line 41, in _format_vat_cl
return stdnum.util.get_cc_module('cl', 'vat').format(values['vat']).replace('.', '').replace(
File "stdnum/cl/rut.py", line 90, in format
number[-4:-1] + '-' + number[-1])
```
code reference:
https://github.com/odoo/odoo/blob/276972f96d2eb1a65686e7319f601ed435b57b88/addons/l10n_cl/models/res_partner.py#L40
Here, when user enters "." in Identification Number
then values['vat'] will be ".",
So when it will try to .format(),
It will lead to above traceback.
sentry-4593791704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#140862Since the early versions of the homeworking modules, we were showing incorrect colors for the homeworking icons if the partner_id was too large. This comes from the fact that we were not using the getColor helper from calendar to decide which color to render. Since we have a limited amount of colors, we should not use the partner id to define the color, but actually cycle through all the possible colors, which is done by the getColor method. Also, when getting the homeworking data, it was pos
Original PR description
Since the early versions of the homeworking modules, we were showing incorrect colors for the homeworking icons if the partner_id was too large. This comes from the fact that we were not using the getColor helper from calendar to decide which color to render. Since we have a limited amount of colors, we should not use the partner id to define the color, but actually cycle through all the possible colors, which is done by the getColor method. Also, when getting the homeworking data, it was possible to get partner_id as false when the employee had no related user. This commit also changes this to fallback on the work_contact_id if no user is set. task-3561678 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#139167
The migration script for taxes was forward-ported without changes from 15.0 to master. However, it should be done differently since saas-16.2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145243
Original PR description
The migration script for taxes was forward-ported without changes from 15.0 to master. However, it should be done differently since saas-16.2. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145243
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference, triggering lots of unwanted spam for attendees on Microsoft side when it shouldn't happen. Additionaly, when restarting the synchronization with Microsoft, the setting parameter `range_days` was being used to update all events in Odoo with `{'need_sync_m': True}`, which also triggered updates in old even
Original PR description
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference,…
Before this commit, there were situations that old events in Odoo which shared the same state with Microsoft got updated (without changes) in Odoo due to a few seconds of update time difference, triggering lots of unwanted spam for attendees on Microsoft side when it shouldn't happen. Additionaly, when restarting the synchronization with Microsoft, the setting parameter `range_days` was being used to update all events in Odoo with `{'need_sync_m': True}`, which also triggered updates in old events and future events on Microsoft side. If `range_days` was too big, lots of events were 'updated' and triggered spam, and if it was too small, only events within the `range_days` range were synchronized with Outlook.
After this commit, using system parameters, old events in Odoo which update time difference between Microsoft and Odoo is too small are not updated in Odoo anymore, thus not triggering unwanted spam for attendees in these situations. Also, one system parameter `lower_bound_range` was added to be used for selecting the range of old events in Odoo that will be synchronized (and send emails).
Task-id: 3601306
Forward-Port-Of: odoo/odoo#145117
Forward-Port-Of: odoo/odoo#142521This commit adds the missing neutralisation necessary for the `pos_pricer` module introduced in [1] The purpose of the standard neutralisation framework is to allow us to create database copies that will not interract with external systems in ways that could impact the production database (or if it is not possible to prevent the interractions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly use
Original PR description
This commit adds the missing neutralisation necessary for the `pos_pricer` module introduced in [1] The purpose of the standard neutralisation framework is to allow us to create database copies that will not interract with external systems in ways that could impact the production database (or if it is not possible to prevent the interractions, make sure that they are benign or wont result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/enterprise/pull/50368 Forward-Port-Of: odoo/enterprise#52217
Steps: ------------ - Open Projects - Go to Tasks - Open Map View - Group By Status - In left-side panel ,the technical name of the state is displayed instead of its label Issue: ------------ - When using the selection field in map view, the technical name is being displayed instead of the label. Cause: ------------ - The issue arises because the code lacks proper handling for the "selection" field type. Fix: --------- - With this fix,the code now correctly handle
Original PR description
Steps: ------------ - Open Projects - Go to Tasks - Open Map View - Group By Status - In left-side panel ,the technical name of the state is displayed instead of its label Issue: ------------ - When using the selection field in map view, the technical name is being displayed instead of the label. Cause: ------------ - The issue arises because the code lacks proper handling for the "selection" field type. Fix: --------- - With this fix,the code now correctly handles "selection" fields and ensures that the label associated with the selected value is used for grouping records. task: 3552597 Forward-Port-Of: odoo/enterprise#52147 Forward-Port-Of: odoo/enterprise#49964
With the introduction of the 'section' implementation, it's now possible to print multiple reports in a single batch. However, a problem arises when one of the reports requires a landscape format (e.g., GL) while the others should remain in portrait orientation. This pull request addresses this issue by ensuring that the landscape format is applied only to the report that specifically requires it. For example, the Balance Sheet (BS), Profit and Loss (P&L), and Trial Balance (TB) reports will
Original PR description
With the introduction of the 'section' implementation, it's now possible to print multiple reports in a single batch. However, a problem arises when one of the reports requires a landscape format…
With the introduction of the 'section' implementation, it's now possible to print multiple reports in a single batch. However, a problem arises when one of the reports requires a landscape format (e.g., GL) while the others should remain in portrait orientation. This pull request addresses this issue by ensuring that the landscape format is applied only to the report that specifically requires it. For example, the Balance Sheet (BS), Profit and Loss (P&L), and Trial Balance (TB) reports will be printed in portrait, but the General Ledger (GL) report will be printed in landscape. Here's what has been done: For each report, we execute wkhtmltopdf and create a stream for that bytes pdf. We create a list of these streams and utilize the 'merge_pdfs' function to create a single stream containing all the PDFs. By passing this combined stream in the 'file_content' parameter, we achieve the desired outcome of printing a single PDF file with the correct format for each report. task: 3566920 Forward-Port-Of: odoo/enterprise#49482
Steps to reproduce: ------------------- - create a payslip with multiple "Other inputs"; - click on the compute sheet button. Issue: ------ A traceback appears. Cause: ------ We're trying to access an item in a dictionary by a way that doesn't work. opw-3620353 Forward-Port-Of: odoo/enterprise#52124
Original PR description
Steps to reproduce: ------------------- - create a payslip with multiple "Other inputs"; - click on the compute sheet button. Issue: ------ A traceback appears. Cause: ------ We're trying to access an item in a dictionary by a way that doesn't work. opw-3620353 Forward-Port-Of: odoo/enterprise#52124
- Verify that options is different to None to avoid errors when trying to get 'toolbar' when creating payslip Form in unit tests. Forward-Port-Of: odoo/enterprise#52097
Original PR description
- Verify that options is different to None to avoid errors when trying to get 'toolbar' when creating payslip Form in unit tests. Forward-Port-Of: odoo/enterprise#52097
Allow a user to import his data with SAF-T. We allow import of taxes/partners/accounts/journals/moves. Added specifities for DK, LT and RO in specific modules We consider: - a partner to be unique per name + VAT number. - an account to be unique with his code. - a tax to per name + amount_type + amount The journal and moves are always created the first time, and then, we use the ID defined in the SAF-T to avoid recreating them (especially important for journals). We create opening b
Original PR description
Allow a user to import his data with SAF-T. We allow import of taxes/partners/accounts/journals/moves. Added specifities for DK, LT and RO in specific modules We consider: - a partner to be unique per name + VAT number. - an account to be unique with his code. - a tax to per name + amount_type + amount The journal and moves are always created the first time, and then, we use the ID defined in the SAF-T to avoid recreating them (especially important for journals). We create opening balances for accounts if the user checked the option. task-3593719 Forward-Port-Of: odoo/enterprise#51661
`next_invoice_date` field is not required field and was using on computation of `display_late` field and used `order.next_invoice_date < today` without checking if order.next_invoice_date. so for some record we found NULL value for next_invoice_date and will get traceback from that line during upgrade ``` File "/home/odoo/src/enterprise/17.0/sale_subscription/models/sale_order.py", line 502, in _compute_display_late order.display_late = order.subscription_state in SUBSCRIPTION_PROGRE
Original PR description
`next_invoice_date` field is not required field and was using on computation of `display_late` field and used
`order.next_invoice_date < today` without checking if order.next_invoice_date. so for some record
we found NULL value for next_invoice_date and will get traceback from that line during upgrade
```
File "/home/odoo/src/enterprise/17.0/sale_subscription/models/sale_order.py", line 502, in _compute_display_late
order.display_late = order.subscription_state in SUBSCRIPTION_PROGRESS_STATE and order.next_invoice_date < today
TypeError: '<' not supported between instances of 'bool' and 'datetime.date'
```
Forward-Port-Of: odoo/enterprise#52148The issue: Having a recurring plan with billing period set to 0, a traceback raised when you try to confirm the order The fix: converting the value to a valid datedelta object opw-3606819 Forward-Port-Of: odoo/enterprise#51669
Original PR description
The issue: Having a recurring plan with billing period set to 0, a traceback raised when you try to confirm the order The fix: converting the value to a valid datedelta object opw-3606819 Forward-Port-Of: odoo/enterprise#51669
Forward-Port-Of: odoo/enterprise#52141
Original PR description
Forward-Port-Of: odoo/enterprise#52141
Steps to reproduce: 1. Set up FedEx International shipping method 2. Add insurance percentage (any number above zero) 3. Make a sale order for a customer in another country 3. Add a product and use a currency other than that of company currency 4. Validate the shipment FedEx error: ```All Currency Types in the Requested Shipment must match.``` To fix this, we need to use the currency used in the sale order instead of currency of the company. opw-3557669 Forward-Port-Of: odoo/ent
Original PR description
Steps to reproduce: 1. Set up FedEx International shipping method 2. Add insurance percentage (any number above zero) 3. Make a sale order for a customer in another country 3. Add a product and use a currency other than that of company currency 4. Validate the shipment FedEx error: ```All Currency Types in the Requested Shipment must match.``` To fix this, we need to use the currency used in the sale order instead of currency of the company. opw-3557669 Forward-Port-Of: odoo/enterprise#49564
Steps to reproduce: 1. set up FedEx shipping method, choose `REGIONAL_ECONOMY` service type 2. make a sale order from EU to UK, add FedEx shipping 3. confirm the sale order, validate the delivery Error: `2033: Customs Value is required.` FedEx requires customs info for `REGIONAL_ECONOMY` service type, so it should be included accordingly. opw-3527006 Forward-Port-Of: odoo/enterprise#51890 Forward-Port-Of: odoo/enterprise#50371
Original PR description
Steps to reproduce: 1. set up FedEx shipping method, choose `REGIONAL_ECONOMY` service type 2. make a sale order from EU to UK, add FedEx shipping 3. confirm the sale order, validate the delivery Error: `2033: Customs Value is required.` FedEx requires customs info for `REGIONAL_ECONOMY` service type, so it should be included accordingly. opw-3527006 Forward-Port-Of: odoo/enterprise#51890 Forward-Port-Of: odoo/enterprise#50371
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Appraisals'. --- **Issue:** - When viewing the department's appraisal in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358
Original PR description
**Steps to reproduce:** - open kanban view of department in employee module. - click on 'Appraisals'. --- **Issue:** - When viewing the department's appraisal in the employee module, all department data is displayed, regardless of the department selection. --- **Solution:** - The issue is resolved by correcting the domain, ensuring that only data related to the selected department is displayed. This adjustment results in accurate department-specific request information. Task-3541358 Forward-Port-Of: odoo/enterprise#49093
Before this commit: Once a payment have been validated by Worldline payment terminal the PoS cashier would be forced to wait 5 seconds before receiving the validation on the PoS side. This delay was added to fix: https://github.com/odoo/enterprise/pull/46684 But the delay could be added in a "smarter" way: Rather than force sleeping at the end of the transaction (before code), we would sleep on incoming requests only if the previous transaction was done "too recently" After this c
Original PR description
Before this commit: Once a payment have been validated by Worldline payment terminal the PoS cashier would be forced to wait 5 seconds before receiving the validation on the PoS side. This delay was added to fix: https://github.com/odoo/enterprise/pull/46684 But the delay could be added in a "smarter" way: Rather than force sleeping at the end of the transaction (before code), we would sleep on incoming requests only if the previous transaction was done "too recently" After this commit: The result of the terminal (validation, cancellation, ...) is executed right away. But new transactions/interaction might be delayed if it is too close in time with the previous one. Also added the logger and some logs for troubleshooting future cases. opw-3462147 Forward-Port-Of: odoo/enterprise#51855 Forward-Port-Of: odoo/enterprise#49449
In order to be certified, few changes has to be done in v17. We fix deletion of the product that was not working. The cash rounding was not set. the check was commented and we remove the comment. Forward-Port-Of: odoo/enterprise#51768
Original PR description
In order to be certified, few changes has to be done in v17. We fix deletion of the product that was not working. The cash rounding was not set. the check was commented and we remove the comment. Forward-Port-Of: odoo/enterprise#51768
To reproduce: - Create an asset last month, with duration monthly - Confirm it, then cancel it => The message in the chatter contains the \<br> in plain text. Following ac0bfab08e1c7e14c815cb33ed2a5c081668b0f8, we should Markup to render html Forward-Port-Of: odoo/enterprise#51032
Original PR description
To reproduce: - Create an asset last month, with duration monthly - Confirm it, then cancel it => The message in the chatter contains the \<br> in plain text. Following ac0bfab08e1c7e14c815cb33ed2a5c081668b0f8, we should Markup to render html Forward-Port-Of: odoo/enterprise#51032
Balance Sheet: - Lines 101. Assets (or disposal groups) held for sale, and 301. Liabilities of disposal groups held for sale should be added to the totals of Assets and Liabilities, respectively. - The sign of account 51 should be + not - since it's an Equity account. Profit & Loss: - I've changed the sign of the accounts used for each report line, so that lines that expect to be expenses are positive on debit, and lines that expect to be income are positive on credit. Source: offici
Original PR description
Balance Sheet: - Lines 101. Assets (or disposal groups) held for sale, and 301. Liabilities of disposal groups held for sale should be added to the totals of Assets and Liabilities, respectively. - The sign of account 51 should be + not - since it's an Equity account. Profit & Loss: - I've changed the sign of the accounts used for each report line, so that lines that expect to be expenses are positive on debit, and lines that expect to be income are positive on credit. Source: official financial statements, found at https://adilet.zan.kz/rus/docs/V1700015384 This is part of the wider task of re-balancing the Balance Sheets. I've checked that with these changes, the Balance Sheet is always balanced. (Checked using the TestBalanceSheetBalanced test from https://github.com/odoo/enterprise/pull/47602) taskid:3060790 Forward-Port-Of: odoo/enterprise#51993 Forward-Port-Of: odoo/enterprise#47604
According to the Balance Sheet diagnosis tool in #36838, accounts 2250 and 2370 were not being referenced in the Balance Sheet, causing an imbalance between Assets and Liabilities/Equity. Referencing them solves the issue of the unbalanced Balance Sheet. The same issue is present in master and will be solved by this fix. taskid: 3060790 Forward-Port-Of: odoo/enterprise#51953
Original PR description
According to the Balance Sheet diagnosis tool in #36838, accounts 2250 and 2370 were not being referenced in the Balance Sheet, causing an imbalance between Assets and Liabilities/Equity. Referencing them solves the issue of the unbalanced Balance Sheet. The same issue is present in master and will be solved by this fix. taskid: 3060790 Forward-Port-Of: odoo/enterprise#51953
…firmed Currently, if you create a SO without subscription products and confirm it, the recurrence field will still be editable. Therefore allowing to change a confirmed SO to a subscription. This is an undesired behavior and should not be possible. This commit fixes that by hiding the recurrence field in confirmed SO without subscription products. task-3600687 Forward-Port-Of: odoo/enterprise#52088 Forward-Port-Of: odoo/enterprise#50860
Original PR description
…firmed Currently, if you create a SO without subscription products and confirm it, the recurrence field will still be editable. Therefore allowing to change a confirmed SO to a subscription. This is an undesired behavior and should not be possible. This commit fixes that by hiding the recurrence field in confirmed SO without subscription products. task-3600687 Forward-Port-Of: odoo/enterprise#52088 Forward-Port-Of: odoo/enterprise#50860
According to the Balance Sheet diagnosis tool in #36838, the Balance Sheet was unbalanced. On closer inspection, this was seen to be caused by an incorrect cross-report to the Profit and Loss in the Current Year Earnings and Retained Earnings sections. The same issue is present all the way to master. This commit fixes the cross-report references. We also take the opportunity to remove all the redundant `date_scope=normal` data. Since Balance Sheet reports work with a single (end) date, the
Original PR description
According to the Balance Sheet diagnosis tool in #36838, the Balance Sheet was unbalanced. On closer inspection, this was seen to be caused by an incorrect cross-report to the Profit and Loss in the Current Year Earnings and Retained Earnings sections. The same issue is present all the way to master. This commit fixes the cross-report references. We also take the opportunity to remove all the redundant `date_scope=normal` data. Since Balance Sheet reports work with a single (end) date, the normal date_scope works exactly the same as the strict_range date_scope, which is the default. taskid: 3060790 Forward-Port-Of: odoo/enterprise#51970
Forward-Port-Of: odoo/enterprise#51891
Original PR description
Forward-Port-Of: odoo/enterprise#51891
This traceback occurs when `stock.move.line` record is created with `qty_done`. To reproduce this issue: 1) Install `mrp_workorder` 2) Create two products `(A, B)` 3) Create a new `bill of material` with component as product `B` and product as `A` 4) Add an `operation` and from the `operation` click on `show instruction` button 5) Create a new `quality.point` record with type as `Register Consumed Materials` 6) give `component_id` value as product `B` 7) Now create a new `Manufac
Original PR description
This traceback occurs when `stock.move.line` record is created with `qty_done`. To reproduce this issue: 1) Install `mrp_workorder` 2) Create two products `(A, B)` 3) Create a new `bill of material`…
This traceback occurs when `stock.move.line` record is created with `qty_done`.
To reproduce this issue:
1) Install `mrp_workorder`
2) Create two products `(A, B)`
3) Create a new `bill of material` with component as product `B`
and product as `A`
4) Add an `operation` and from the `operation` click on `show instruction` button
5) Create a new `quality.point` record with type as `Register Consumed Materials`
6) give `component_id` value as product `B`
7) Now create a new `Manufacturing Order` with the above created `BOM`
8) Conform the record and click on `Open shop Floor` button from `work order`
9) Click on the `Quality Point` record and click `Continue Consumption` button
Sentry Traceback:-
```
ValueError: Invalid field 'qty_done' on model 'stock.move.line'
File "odoo/http.py", line 2157, in __call__
response = request._serve_db()
File "odoo/http.py", line 1732, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 133, in retrying
result = func()
File "odoo/http.py", line 1759, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1960, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "addons/website/models/ir_http.py", line 235, in _dispatch
response = super()._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 722, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 24, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 20, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 466, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 453, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "home/odoo/src/enterprise/17.0/mrp_workorder/models/quality.py", line 351, in action_next
return self._next()
File "home/odoo/src/enterprise/17.0/quality_mrp_workorder/models/quality.py", line 38, in _next
result = super()._next(continue_production=continue_production)
File "home/odoo/src/enterprise/17.0/mrp_workorder/models/quality.py", line 510, in _next
line = self.env['stock.move.line'].create(self._create_extra_move_lines())
File "<decorator-gen-412>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "home/odoo/src/enterprise/17.0/quality_control/models/stock_move_line.py", line 30, in create
lines = super().create(vals_list)
File "<decorator-gen-248>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/stock_account/models/stock_move_line.py", line 17, in create
move_lines = super(StockMoveLine, self).create(vals_list)
File "<decorator-gen-387>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/mrp/models/stock_move.py", line 43, in create
res = super(StockMoveLine, self).create(values)
File "<decorator-gen-225>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "addons/stock/models/stock_move_line.py", line 305, in create
mls = super().create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "odoo/models.py", line 4538, in create
raise ValueError("Invalid field %r on model %r" % (key, self._name))
```
From this PR (https://github.com/odoo/odoo/pull/137864) `qty_done` field is removed from `stock.move.line` model.
When a record is being created with the `qty_done` field a traceback occurs.
After applying this commit will resolve the issue by replacing `qty_done` with
`quantity` field.
sentry-4636904734
Forward-Port-Of: odoo/enterprise#51012This PR adds a new module "pricer" It allows integration of Odoo with Pricer. Users can now associate their products in Odoo to Pricer electronic price tags, which allow them to display product information and price Every 12 hours in a cron we check if the products with Pricer tags linked to them were modified and if so, we call Pricer API to modify the displayed product information. (this can also be done manually) task-3414052 Forward-Port-Of: odoo/enterprise#50368
Original PR description
This PR adds a new module "pricer" It allows integration of Odoo with Pricer. Users can now associate their products in Odoo to Pricer electronic price tags, which allow them to display product information and price Every 12 hours in a cron we check if the products with Pricer tags linked to them were modified and if so, we call Pricer API to modify the displayed product information. (this can also be done manually) task-3414052 Forward-Port-Of: odoo/enterprise#50368
Before this commit, the pop-up when testing the avatax connection was very unclear for user. Indeed, we displayed a dictionary of information without really telling the user that the connection was successful or not. Now, when testing the connection we clearly indicate if the authentication was a success or not, and we display all the information as a list. task: 3614808 Forward-Port-Of: odoo/enterprise#51743
Original PR description
Before this commit, the pop-up when testing the avatax connection was very unclear for user. Indeed, we displayed a dictionary of information without really telling the user that the connection was successful or not. Now, when testing the connection we clearly indicate if the authentication was a success or not, and we display all the information as a list. task: 3614808 Forward-Port-Of: odoo/enterprise#51743
In the Shop Floor, on a workorder, 'Mark as Done' do not check for its prerequisites before fading out, giving you for example no chance to fill the missing lot/serial for the final product. Moveover, on the last workorder, you have no way to 'Close Production'. Forward-Port-Of: odoo/enterprise#52018
Original PR description
In the Shop Floor, on a workorder, 'Mark as Done' do not check for its prerequisites before fading out, giving you for example no chance to fill the missing lot/serial for the final product. Moveover, on the last workorder, you have no way to 'Close Production'. Forward-Port-Of: odoo/enterprise#52018
Forward-Port-Of: odoo/enterprise#51937
Original PR description
Forward-Port-Of: odoo/enterprise#51937