Daily updates from Odoo
Navigate
Branch
Wednesday, August 16, 2023
27 changes
Enhancements to existing features
The Helpdesk app now offers clearer team documentation links, improved ticket views, and additional demo data for service level agreements. Status updates for refunds, returns, and repairs were simplified to reduce noise and make ticket activity easier to follow.
Original PR description
Purpose of the task is to improve the generic UX and usability of the helpdesk app.
so in this commit, did below changes:
- updated the documentation links on team form view
- added some demo data for sla
- improve the ticket form,list view
- removed the following sub-types:
- refund canceled
- return canceled - repair canceled
- renamed follwing subtype: - refund posted -> refund status - return done -> return status - repair done -> repair status
task-2980478This update improves the wording shown around project budgets, making the project app easier to understand for everyday users. The change helps teams interpret budget information more clearly when reviewing project updates.
Original PR description
This PR aims to improve the generic usage of the project app. So, in this PR done following changes: - Changed budget sentence in sale_timesheet_account_budget task-2903637
The Subscriptions app now includes a dedicated customer menu. This makes it easier for users to access and manage customer information directly from the subscription workflow.
Original PR description
before this commit, there is no customer menu in subscription app. after this commit, customer menu is added in subscription app.
Subscription forms now show a clearer tag when a subscription is late and needs renewal. This restores an easier visual cue from earlier versions, helping users quickly identify subscriptions that require action.
Original PR description
From the form view of a subscription it is not 100% clear that it is late and need to be renewed. It was more clear in previous versions with the tag. task-id: 3432150
Resolved issues and error corrections
This fixes display issues in the appointment booking flow after an underlying template technology change. Users should see appointment slot pages render reliably instead of missing content or errors.
Original PR description
Following the removal of qweb in favor of owl at: odoo/odoo@6303a3eacdca012649a2ffda627b65c17a7217f1 There were a few issues with the templates: - 'JSON' is no longer in the rendering context of the templates - 'renderToElement' only returns the first 'root' element of the template, which is not suitable for some cases (replaced with 'renderToFragment') - correctly 'return' before trying to render a template that contains a foreach on an undefined variable (qweb did not mind, OWL is throwing an error) Task-3465533
Field Service product handling now uses the technician's preferred warehouse more reliably and confirms sales orders when products are added, so stock movements are created correctly. The update also fixes quantity, serial/lot tracking, messaging, and access-right issues, reducing errors during field service workflows.
Original PR description
This PR purpose is to address several Field Service Bugs among which: - correctly compute serial_missing - use user's default warehouse - prevent Error when setting product_uom_qty=qty_delivered (due to using stock.move.line in order to set default warehouse) - revert setting the assignee as SO sales rep - prevent unwanted message posts - handle preventing message post in right def - industry_fsm_stock: confirm so when adding products - add ensure_one on `fsm.stock.tracking` This PR also adds tests in order to ensure that the related bug fixes are tested. task-2714003
This update fixes an issue that could cause an error after signing a document when a related contact had been deleted. Users can now complete signing without the suggestion popup interrupting their workflow.
Original PR description
This commit's purpose is to complete its community part task-3251615
Knowledge article menus now show the creator and last editor names again. This restores helpful context that disappeared after a performance-related loading change.
Original PR description
When loading a many-to-one field that is invisible in the arch of the view, the system no longer fetches the display name of those records for performance reasons. It now only fetches the id of the record. In Knowledge, there is an issue induced by that change: The system no longer load (1) the name of the user who create the article and (2) the name of the last user who edit the article. As a result, those values are no longer display in the kebab menu of Knowledge. This PR will fix that issue by adding new field dependencies in the `TopBar` component. The system will now load the display name as it was the case before. task-3452142
The Manufacturing Planning Schedule now identifies the correct company when choosing a default warehouse. This prevents users from seeing errors caused by a missing warehouse and helps planning workflows open reliably.
Original PR description
In [this fix](https://github.com/odoo/enterprise/commit/ef9c696f825e763f450c7f02a239c79f50ead378#diff-774514eeaaf87c6b1c768b97ea72742739012968378e2b17874f2e37893abe5fR22), the company is not retreive properly, which returns an user error in the mps app because the warehouse is not set properly (as in the _default warehouse, the company is not correct => the warehouse is None).
Features or functions removed from Odoo
The Documents app no longer carries an old internal marker used to remember the original user during elevated access. This simplifies the code because the platform now keeps that user information automatically, with no expected change for everyday users.
Original PR description
Formerly, using sudo() on a record had the effect of replacing the current user with the superuser. But sometimes, knowing who the "real user" was was necessary, so we needed to store it somewhere. This is basically why the key `binary_field_real_user` was introduced in the context: to keep track of who the user was before switching to sudo mode. Since odoo/odoo@1e6c3be, however, switching to sudo mode no longer changes the current user; meaning that the `binary_field_real_user` is no longer necessary. This commit removes the remaining occurrences of the now useless `binary_field_real_user` from the code. Community: https://github.com/odoo/odoo/pull/92032
Code cleanup and technical improvements
Several country-specific reporting modules were cleaned up by removing a redundant report display setting. This should not change business workflows, but it helps keep tax and statutory report definitions consistent and easier to maintain.
Original PR description
[[REF] l10n_{ar,au,be,co,de,ee,es,lu,mx,pe,se}_reports, l10n_es_real_estates, l10n_nl_intrastat: remove 'none' figure_type
This commit removes the 'none' figure_type from the account_tax_report
because it is redundant since other figure_types have been added.
Especially 'string' which practically does the same thing.
task ID: 3434197
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSeveral older pop-up dialogs were rebuilt using Odoo’s newer interface framework. This keeps the user experience more consistent across apps and makes future maintenance easier, with little expected change to day-to-day workflows.
Original PR description
[REF] *: convert legacy dialogs The goal of this commit is to convert a bunch of legacy dialogs into owl dialogs. TaskID: 3453920
The charting tool used across several Odoo Enterprise areas has been updated to a newer version. This helps prepare the platform to remove an older date-handling dependency, improving long-term maintainability while preserving existing chart behavior.
Original PR description
Version 4.3 of chart.js no longer uses moment.js. This task is a prerequisite to completely remove the use of moment.js (task 3391739) task-3392075
Miscellaneous changes
There is a new generic SEPA pain format for SEPA credit transfers. New fields are required for the new SEPA pain format: - UETR: payment uuid - LEI: Legal Entity Identifier (not mandatory right now, but will be in the future) Few tags are changing: - BIC tag should now be BICFI - Address should be split into street, postcode, town task-3249329 Forward-Port-Of: odoo/enterprise#45702 Forward-Port-Of: odoo/enterprise#43806
Original PR description
There is a new generic SEPA pain format for SEPA credit transfers. New fields are required for the new SEPA pain format: - UETR: payment uuid - LEI: Legal Entity Identifier (not mandatory right now, but will be in the future) Few tags are changing: - BIC tag should now be BICFI - Address should be split into street, postcode, town task-3249329 Forward-Port-Of: odoo/enterprise#45702 Forward-Port-Of: odoo/enterprise#43806
Prior to this commit the grays that were used in timesheet were too dark, this change makes the view more inline with the listview colors. The grid_view cells were also too big which is why its height is now reduced to 40px with the input taking the full available height. Finally the `btn_timer` is now outline-secondary instead of primary and is displaying a success state on active and hover. Thanks to @edi-odoo task-3340318 Forward-Port-Of: odoo/enterprise#41554
Original PR description
Prior to this commit the grays that were used in timesheet were too dark, this change makes the view more inline with the listview colors. The grid_view cells were also too big which is why its height is now reduced to 40px with the input taking the full available height. Finally the `btn_timer` is now outline-secondary instead of primary and is displaying a success state on active and hover. Thanks to @edi-odoo task-3340318 Forward-Port-Of: odoo/enterprise#41554
When the user tries to create withhold while `invoice_date` is not set traceback will appear Steps to produce: 1. install the `Ecuadorian Accounting EDI` module and switch to its respective company 2. invoice > new > action > create withholds Note: Invoice must be in draft state. ``` AttributeError: 'bool' object has no attribute 'month' File "odoo/http.py", line 2115, in __call__ response = request._serve_db() File "odoo/http.py", line 1698, in _serve_db return servic
Original PR description
When the user tries to create withhold while `invoice_date` is not set traceback will appear Steps to produce: 1. install the `Ecuadorian Accounting EDI` module and switch to its respective company…
When the user tries to create withhold while `invoice_date` is not set traceback will appear
Steps to produce:
1. install the `Ecuadorian Accounting EDI` module and switch to its respective company
2. invoice > new > action > create withholds
Note: Invoice must be in draft state.
```
AttributeError: 'bool' object has no attribute 'month'
File "odoo/http.py", line 2115, in __call__
response = request._serve_db()
File "odoo/http.py", line 1698, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1725, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 1922, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 715, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 28, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 24, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "odoo/models.py", line 6409, in onchange
defaults = self.default_get(missing_names)
File "home/odoo/src/enterprise/saas-16.2/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py", line 94, in default_get
self._validate_invoices_data_on_open(invoices)
File "home/odoo/src/enterprise/saas-16.2/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py", line 300, in _validate_invoices_data_on_open
invoice_months.add((invoice.invoice_date.month, invoice.invoice_date.year))
```
see:https://github.com/odoo/enterprise/blob/adfe654f14fe1cf962e7a8151df6bb47162391be/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L300
In the above use case at the time of creating withhold when the invoice_date field is not set, then the invoice_date field gets a `False` value which led to the attribute error.
(2) When user tries to create withhold while the customer field is not set and
the invoice_date field is set, traceback will appear.
Steps to produce:
1. install the Ecuadorian Accounting EDI module and switch to its respective
company
2. invoice > new > add invoice_date > action > create withholds
Note: Invoice must be in draft state
```
ValueError: not enough values to unpack (expected 1, got 0)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/odoo/odoo/odoo/odoo/http.py", line 1998, in __call__
response = request._serve_db()
File "/home/odoo/odoo/odoo/odoo/http.py", line 1584, in _serve_db
return service_model.retrying(self._serve_ir_http, self.env)
File "/home/odoo/odoo/odoo/odoo/service/model.py", line 133, in retrying
result = func()
File "/home/odoo/odoo/odoo/odoo/http.py", line 1611, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/odoo/odoo/odoo/http.py", line 1815, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/odoo/odoo/odoo/addons/base/models/ir_http.py", line 154, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/odoo/odoo/odoo/http.py", line 697, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/odoo/odoo/addons/web/controllers/dataset.py", line 42, in call_kw
return self._call_kw(model, method, args, kwargs)
File "/home/odoo/odoo/odoo/addons/web/controllers/dataset.py", line 33, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/odoo/odoo/odoo/api.py", line 461, in call_kw
result = _call_kw_multi(method, model, args, kwargs)
File "/home/odoo/odoo/odoo/odoo/api.py", line 448, in _call_kw_multi
result = method(recs, *args, **kwargs)
File "/home/odoo/odoo/odoo/odoo/models.py", line 6383, in onchange
defaults = self.default_get(missing_names)
File "/home/odoo/odoo/enterprise/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py", line 94, in default_get
self._validate_invoices_data_on_open(invoices)
File "/home/odoo/odoo/enterprise/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py", line 328, in _validate_invoices_data_on_open
if invoice.move_type == 'out_invoice' and invoice.commercial_partner_id._l10n_ec_get_identification_type() != 'ruc':
File "/home/odoo/odoo/odoo/addons/l10n_ec/models/res_partner.py", line 102, in _l10n_ec_get_identification_type
self.ensure_one()
File "/home/odoo/odoo/odoo/odoo/models.py", line 5137, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: res.partner()
```
This fix checks, that the invoice must be posted before creating a withhold.
sentry-4211436445
Forward-Port-Of: odoo/enterprise#44031Steps to reproduce ------------------ 1. Install Documents, Project and Sales. 2. Create a project to use as a template for a product, with the "Use documents" feature disabled. 3. Create a service product using the project as a template. 4. Create an SO with that product and confirm it. 5. Go to the documents app in the 'Projects' folder, there will be a new folder for the project of the SO, despite that project having the documents feature disabled. --- The templates with the doc
Original PR description
Steps to reproduce ------------------ 1. Install Documents, Project and Sales. 2. Create a project to use as a template for a product, with the "Use documents" feature disabled. 3. Create a service product using the project as a template. 4. Create an SO with that product and confirm it. 5. Go to the documents app in the 'Projects' folder, there will be a new folder for the project of the SO, despite that project having the documents feature disabled. --- The templates with the documents feature disabled are not taken into account and a workspace is created for the generated project regardless. This PR avoids generating a workspace for such projects. Task-3460208 Forward-Port-Of: odoo/enterprise#45735 Forward-Port-Of: odoo/enterprise#45547
When employee filing an expense doesn't have a work email, a user error is shown. This commit updates the test_expense_in_payroll_payment_state test to abide to this new mechanism. Community PR: https://github.com/odoo/odoo/pull/130254 Task ID: 3438559 Forward-Port-Of: odoo/enterprise#45640
Original PR description
When employee filing an expense doesn't have a work email, a user error is shown. This commit updates the test_expense_in_payroll_payment_state test to abide to this new mechanism. Community PR: https://github.com/odoo/odoo/pull/130254 Task ID: 3438559 Forward-Port-Of: odoo/enterprise#45640
In the l10n_mx_edi module, xpaths are done on the report_payment_receipt_document template of the account module. In one of those xpaths, a t-set is done using a value from cfdi. "cfdi" is coming from the "values" variable but can be None. A check of the existence of cfdi is always done before its use in the other xpaths of the module. This commit adds this check to the problematic xpath. Forward-Port-Of: odoo/enterprise#45607
Original PR description
In the l10n_mx_edi module, xpaths are done on the report_payment_receipt_document template of the account module. In one of those xpaths, a t-set is done using a value from cfdi. "cfdi" is coming from the "values" variable but can be None. A check of the existence of cfdi is always done before its use in the other xpaths of the module. This commit adds this check to the problematic xpath. Forward-Port-Of: odoo/enterprise#45607
In the barcode app, when adding a decimal amount of received products, the js compute the remaining amount. The problem we faced here whas that the value computed in js had rounding issue (e.g. 10 - 6.6 = 3,0000000004) This value was then used in the backend, making the amount received wrong. Fixed by rounding to the 12th decimal. opw-3315965 Forward-Port-Of: odoo/enterprise#43266 Forward-Port-Of: odoo/enterprise#41695
Original PR description
In the barcode app, when adding a decimal amount of received products, the js compute the remaining amount. The problem we faced here whas that the value computed in js had rounding issue (e.g. 10 - 6.6 = 3,0000000004) This value was then used in the backend, making the amount received wrong. Fixed by rounding to the 12th decimal. opw-3315965 Forward-Port-Of: odoo/enterprise#43266 Forward-Port-Of: odoo/enterprise#41695
before this commit, _sms_get_number_fields and _sms_get_partner_fields function is define twice in the sale.order model without any difference in sale and mass_mailing_sale_subscription module. actually, in the previous version, the model used in mass_mailing_sale_subscription module was sale.subscription, but this model has been merged to sale.order model in the v16 in this commit: https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd and the duplicated fu
Original PR description
before this commit, _sms_get_number_fields and _sms_get_partner_fields function is define twice in the sale.order model without any difference in sale and mass_mailing_sale_subscription module. actually, in the previous version, the model used in mass_mailing_sale_subscription module was sale.subscription, but this model has been merged to sale.order model in the v16 in this commit: https://github.com/odoo/enterprise/commit/8fe6c96558bc9fb9f3655fa52fcbea3fea38afdd and the duplicated function get left over during the merging. after this commit, the duplicated function will be removed from the sale.order model in the mass_mailing_sale_subscription module. Forward-Port-Of: odoo/enterprise#44196 Forward-Port-Of: odoo/enterprise#41603
This is basically applying the same logic as this [commit](https://github.com/odoo/enterprise/pull/36821) but in a slightly different context. To reproduce: - create a chilean localization database with a configure DTE incoming email server to fetch valid EDI XML from a email server (in this case a valid vendor bill) - misconfigure the default account "Proveedores" for purchase balacing, by changing the type from "Payable" to another type of liability, i.e. "Current Liabilities" - try to
Original PR description
This is basically applying the same logic as this [commit](https://github.com/odoo/enterprise/pull/36821) but in a slightly different context. To reproduce: - create a chilean localization database…
This is basically applying the same logic as this [commit](https://github.com/odoo/enterprise/pull/36821) but in a slightly different context. To reproduce: - create a chilean localization database with a configure DTE incoming email server to fetch valid EDI XML from a email server (in this case a valid vendor bill) - misconfigure the default account "Proveedores" for purchase balacing, by changing the type from "Payable" to another type of liability, i.e. "Current Liabilities" - try to fetch the XML (`fetch_mail`) Behavior before fix: - duplicated bills with same name will show up in vendor bills - first bill is invalid but has fields prefilled and committed (invoice lines, customer, due date, etc.) - the second bill is a bare-bones invoice with all error encountered during the XML handling and inviting the user to manually check the XML (chatter attachment) and fill out the information manually Behavior after fix: Only one vendor bill gets created (bare-bones invoice inviting user to correct it manually) Context: While fetching the emails from the “DTE” server and parsing the attachment, while handling a valid xml (customer example attached) the code will run the `_create_document_from_attachment` function. It will hit this try block : https://github.com/odoo/enterprise/blob/16.0/l10n_cl_edi/models/fetchmail_server.py#L262 The logic seems to be that we will try to generate a invoice in “Form” mode (pre-16 context), that now is supposed to be equivalent to the with context here: https://github.com/odoo/enterprise/blob/16.0/l10n_cl_edi/models/fetchmail_server.py#L319 If this for some reason fails, the except block is supposed to capture the error, create a new bare-bones invoice and simply log all the issues in the chatter, thus inviting the user to check manually why this vendor bill as an issue and correct it manually. While doing so, the logic tries to fetch all relevant info from the XML fields, fill in the field and then “commit” it using the invoice_form.write() call. The issue is that the customer has configured his purchase journal to only use one account the is set to “Current Liabilities” instead of “Payable”. This will hit this constrains check `_check_payable_receivable`: https://github.com/odoo/odoo/blob/16.0/addons/account/models/account_move_line.py#L1204 So in a normal setting, when using the frontend, trying to submit a vendor bill with theses invoice lines, would have triggered the UserError and prevent the user from committing that bill. But since these checks only happened at the function return of `_get_invoice_form`, it’s too late since the invalid invoice was already committed and there is no rollback. What happens next is that we hit the except block, we capture the error message and then a new fresh invoice form is created with barebone information. The ideas is to validate the rest of the information in the XML, log any issues in the chatter, add the XML as attachment and let the client decide what to do with this. So de facto, right now two invoice with the same name are create, one having invoice lines and journal entries that are not valid. Then a second one that is supposed to be the catchall invoice to be manually fixed by the client. So the proposed fix just forces a rollback if the first invoice to be committed raises an error, so we only keep the second invoice created during the except block. opw-3375744 Forward-Port-Of: odoo/enterprise#45612 Forward-Port-Of: odoo/enterprise#45535
Steps to reproduce: -Install Fedex carrier -Enable multistep routes -On warehouse config set 3 steps(pick,pack,ship) on outgoing shippments -Create an SO and add Fedex shipping -Validate the first picking and send to shipper Bug: only the first picking has a tracking ref on its chatter repeat previous steps with DHL message is posted on all pickings Fix: set the referrence on all the pickings of the so opw-3279332 Forward-Port-Of: odoo/enterprise#45727 Forward-Port-Of: odoo/enter
Original PR description
Steps to reproduce: -Install Fedex carrier -Enable multistep routes -On warehouse config set 3 steps(pick,pack,ship) on outgoing shippments -Create an SO and add Fedex shipping -Validate the first picking and send to shipper Bug: only the first picking has a tracking ref on its chatter repeat previous steps with DHL message is posted on all pickings Fix: set the referrence on all the pickings of the so opw-3279332 Forward-Port-Of: odoo/enterprise#45727 Forward-Port-Of: odoo/enterprise#44887
This issue occurs when the user tries to connect to sale amazon and at that time, the user gets problems due to network problems, proxy server configuration errors, etc. Traceback- ``` ReadTimeout: HTTPSConnectionPool(host='iap-services.odoo.com', port=443): Read timed out. (read timeout=60) File "home/odoo/src/enterprise/saas-16.3/sale_amazon/utils.py", line 97, in make_proxy_request response = requests.post(url, data=data, timeout=60) File "requests/api.py", line 119, in post
Original PR description
This issue occurs when the user tries to connect to sale amazon and at that time, the user gets problems due to network problems, proxy server configuration errors, etc. Traceback- ``` ReadTimeout:…
This issue occurs when the user tries to connect to sale amazon and at that time, the user gets problems due to network problems, proxy server configuration errors, etc.
Traceback-
```
ReadTimeout: HTTPSConnectionPool(host='iap-services.odoo.com', port=443): Read timed out. (read timeout=60)
File "home/odoo/src/enterprise/saas-16.3/sale_amazon/utils.py", line 97, in make_proxy_request
response = requests.post(url, data=data, timeout=60)
File "requests/api.py", line 119, in post
return request('post', url, data=data, json=json, **kwargs)
File "requests/api.py", line 61, in request
return session.request(method=method, url=url, **kwargs)
File "requests/sessions.py", line 544, in request
resp = self.send(prep, **send_kwargs)
File "requests/sessions.py", line 657, in send
r = adapter.send(request, **kwargs)
File "requests/adapters.py", line 529, in send
raise ReadTimeout(e, request=request)
```
The logger is updated to use the 'warning' level instead of the 'error' level. This change reflects a less severe logging level for cases when timeout while connecting sale Amazon.
sentry-4366899402
Forward-Port-Of: odoo/enterprise#45618After signing a document, the suggestion popup can sometimes cause a traceback This happens when the user has a sign.request.item that wasn't completed and that item was created by a now deleted partner. Deleting the partner removes the create_uid value of the record, causing an issue when trying to access an element of the create_uid tuple opw-3435531 Forward-Port-Of: odoo/enterprise#44920
Original PR description
After signing a document, the suggestion popup can sometimes cause a traceback This happens when the user has a sign.request.item that wasn't completed and that item was created by a now deleted partner. Deleting the partner removes the create_uid value of the record, causing an issue when trying to access an element of the create_uid tuple opw-3435531 Forward-Port-Of: odoo/enterprise#44920
Before this PR: When creating a debit note in an Anglo-Saxon context, lines of the account entry are duplicated for products with automated valuation. after this PR: post method is called passing by context the traditional value 'move_reverse_cancel' to prevent the creation of those lines. Forward-Port-Of: odoo/enterprise#41759 Forward-Port-Of: odoo/enterprise#39176
Original PR description
Before this PR: When creating a debit note in an Anglo-Saxon context, lines of the account entry are duplicated for products with automated valuation. after this PR: post method is called passing by context the traditional value 'move_reverse_cancel' to prevent the creation of those lines. Forward-Port-Of: odoo/enterprise#41759 Forward-Port-Of: odoo/enterprise#39176
This PR addresses 2 bugs: Traceback occuring when launching a workorder from the kanban view for the first time (without ever been connected as an employee) The record was opened two times. In cost analysis of a manufacturing order, there was an error when a user would timesheet (with mrp_workorder_hr installed). The bug was that even if it was an user that was timesheeting, in a workcenter that did not allowed employee timesheet, it was connected employee that was used in cost of opera
Original PR description
This PR addresses 2 bugs: Traceback occuring when launching a workorder from the kanban view for the first time (without ever been connected as an employee) The record was opened two times. In cost analysis of a manufacturing order, there was an error when a user would timesheet (with mrp_workorder_hr installed). The bug was that even if it was an user that was timesheeting, in a workcenter that did not allowed employee timesheet, it was connected employee that was used in cost of operation. The problem was that there was a default employee associate with the workorder even if they could not timesheet. Forward-Port-Of: odoo/enterprise#39354