Daily updates from Odoo
Navigate
Branch
Thursday, February 13, 2020
40 changes
New functionality added to Odoo
CRM users can now merge similar or mistaken lost reasons through a dedicated wizard. This helps clean up sales pipeline reporting without manually changing historical opportunity data.
Original PR description
PR: 43986 Task: 2176997 Task cancelled
Enhancements to existing features
This update refreshes several website snippets to make page sections look cleaner and easier to edit. It simplifies layouts, adjusts default styling such as colors, spacing, titles, buttons, and icons, and adds more flexibility for timeline rows, helping users build more polished website pages with less manual cleanup.
Original PR description
[task-2182907](https://www.odoo.com/web#id=2182907&action=333&active_id=974&model=project.task&view_type=form&menu_id=4720) -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes internal time-related web utilities work more reliably when reused in different parts of the system. It reduces the chance of errors in shared JavaScript code without changing visible user features.
Original PR description
Some functions defined in this file use another function present in the same file through "this" keyword even if it's not needed. This cause problems when these function are required in another file using object destructuring. This commit fix this issue by calling the function only by its name.
Partner forms now guide users more carefully when adding states, reducing accidental creation of incorrect location records. Users can no longer create countries from this flow, quick state creation is disabled, and new states automatically inherit the partner's country when created from the form.
Original PR description
Purpose ======= Improve the state creation flow. Some users created states by mistake, we want to avoid this situation. Specifications ============== Do not allow to create country from the partner form view. Disable the quick create of the state in the partner form view. When we create a state from the partner form view, set by default the country of the state to the country of the partner. Task 2178289
Sales orders now calculate invoice status more reliably while users are editing records, including before the record is fully saved. This helps avoid misleading invoice status information during sales order changes and improves day-to-day accuracy for sales teams.
Original PR description
Works correctly on virtual records during onchanges, notably. Since the data was obtained from a read_group using the ids of self, virtual records never could find any of their data.
CRM lead and opportunity lists can now optionally show campaign, source, and medium information. This helps sales teams understand where leads came from without changing the default list layout.
Original PR description
# Purpose The purpose is to allow the user to choose if he want to display or not information about the campaign, the source and the medium for leads/opportunities. # Specifications This fields are now available as optional fields for the tree views of opportunity and leads. task-2189667
The accounting dashboard was adjusted so it no longer depends on a condition that belongs to the online bank synchronization feature. This keeps the core accounting area properly separated from optional online sync functionality, reducing the chance of display or configuration issues.
Original PR description
The t-if condition using "online_sync" couldn't be there... "online_sync" condition must be present in account_online_sync module and not account module. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
CRM now uses clearer setup text and can automatically enable predictive lead tools when the required CRM and IAP services are installed. This reduces manual configuration during onboarding and helps teams access lead scoring and enrichment capabilities faster.
Original PR description
# Purpose Improve the default configuration on CRM for predictive lead in order to ease the onboarding. # Specifications Modify text and install crm_iap_lead(_enrich) automatically if CRM and IAP are installed. task-2131056
The analytic defaults feature will now be installed automatically when analytic accounting is enabled. This makes the related accounting functionality available without extra setup, reducing configuration steps for users.
Original PR description
"account_analytic_default" module should be auto installed. This way its functionalities are available when analytic accounting option is enabled. Task : 2182900
The accounting dashboard now applies the online synchronization display condition from the correct online sync module. This keeps the dashboard behavior aligned with the installed feature and reduces the risk of accounting screens showing options when online sync is not available.
Original PR description
The t-if condition using "online_sync" must be in this module and not the account module.
Resolved issues and error corrections
This fix prevents internal web editor support files from appearing in the media selection dialog. Business users will see a cleaner media library with only relevant images and files, reducing confusion when editing website content.
Original PR description
Due to the infamous web_editor revert, summernote assets files are once again created and stored in DB, but because they do not contain 'assets_' in their name, they would show up in the media dialog. This commit fixes that by prefixing the created summernote assets file with 'assets_' Stable fix: #45300
Code cleanup and technical improvements
This update simplifies internal CRM code that connects leads, opportunities, and customer records, making related conversion wizards more reliable and flexible. It also improves how website visitor contact actions prepare email and SMS messages, reducing errors when customer details need to be created or verified first.
This refactoring removes an unnecessary shared component used by CRM Helpdesk conversion wizards and moves the needed logic directly into the relevant models. It should make lead and customer handling more reliable and easier to maintain, with minimal visible change for users.
Original PR description
PURPOSE This refactoring commit updates enterprise to a commit proposed in community see PR odoo/odoo#41955. In community we removed the crm.partner.binding mixin. Indeed it defines a mixin for…
PURPOSE
This refactoring commit updates enterprise to a commit proposed in community
see PR odoo/odoo#41955. In community we removed the crm.partner.binding
mixin. Indeed it defines a mixin for unnecessary fields, generally either
redefined in inheriting models, either not used at all. It also holds an
utility method we moved directly on crm.lead model.
SPECIFICATIONS
Code move
* move _find_matching_partner to crm.lead model;
* move action field into inheriting models, except crm.lead.convert2ticket
that does not use it;
* move partner_id to inheriting models;
* remove crm.partner.binding model and inheritance;
Improve behavior
* correctly store lead and partner many2one fields on all inheriting
models. It allows to support a default_lead_id instead of always
relying on active_model / active_id, making the wizards more generic;
* update default_get accordingly in various inheriting models in order to
correctly compute lead / partner values;
LINKS
Task ID 2056759 (remove crm.partner.binding mixin)
Task ID 2088565 (convert onchange / default to compute)
Community PR odoo/odoo#41955
Enterprise PR odoo/enterprise#7322Miscellaneous changes
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#45311
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45311
Fixes for website_form's form builder. task-2196797 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45280
Original PR description
Fixes for website_form's form builder. task-2196797 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45280
When some existing taxes are defined with amount_type = "code", the module uninstallation will leave the current data inconsistent. Add an uninstall hook archiving the given taxes, logging the problematic records ids. Fixes #45240 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45297
Original PR description
When some existing taxes are defined with amount_type = "code", the module uninstallation will leave the current data inconsistent. Add an uninstall hook archiving the given taxes, logging the problematic records ids. Fixes #45240 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45297
Oversight of 92cf2474a2b6cbe13bb0d9f92f21a6f6b9c98a18 Forward-Port-Of: odoo/odoo#45283
Original PR description
Oversight of 92cf2474a2b6cbe13bb0d9f92f21a6f6b9c98a18 Forward-Port-Of: odoo/odoo#45283
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#44358
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#44358
Usecase to reproduce: - Create a product with 10 days manufacture lead time - Create a procurement in order to fullfill a need the 01/15 The MO start date is the 01/05 that's the expected values The MO finished date is the 01/05, 1 h later than the start date It happens due to commit 92aeaa47ff592f3e40957ee092ca2245a1cc0781 This commit modified the wrong start date in order to take the procurement date - manufacturing lead time. However it also modified the finished date to 'the star
Original PR description
Usecase to reproduce: - Create a product with 10 days manufacture lead time - Create a procurement in order to fullfill a need the 01/15 The MO start date is the 01/05 that's the expected values The MO finished date is the 01/05, 1 h later than the start date It happens due to commit 92aeaa47ff592f3e40957ee092ca2245a1cc0781 This commit modified the wrong start date in order to take the procurement date - manufacturing lead time. However it also modified the finished date to 'the start date + 1h'. That returns the problem to the opposite direction. Now the finished moves have a wrong planning. Fix it by using the production+ company lead days instead of 1h. opw-2181962 Forward-Port-Of: odoo/odoo#44342
since it is now implemented by 020e2a5e85036976b309b439582d70b5b775e54f Forward-Port-Of: odoo/odoo#45301
Original PR description
since it is now implemented by 020e2a5e85036976b309b439582d70b5b775e54f Forward-Port-Of: odoo/odoo#45301
The `unit_amount` is a `Float` field with `digits='Product Price'`. Therefore, keep the number of digits of the field, not of the currency. opw-2188646 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#45274
Original PR description
The `unit_amount` is a `Float` field with `digits='Product Price'`. Therefore, keep the number of digits of the field, not of the currency. opw-2188646 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#45274
Forward-Port-Of: odoo/odoo#45260
Original PR description
Forward-Port-Of: odoo/odoo#45260
Before this commit, the behavior of the phone widget was tested in web as if it was always altered with module SMS Giving wrong test results when sms module was not installed After this commit, the separation is clearer, and the phone widget's behavior is tested according to the modules it is altered by 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 gu
Original PR description
Before this commit, the behavior of the phone widget was tested in web as if it was always altered with module SMS Giving wrong test results when sms module was not installed After this commit, the separation is clearer, and the phone widget's behavior is tested according to the modules it is altered by 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#45238
### Issue - Install Time Off & Studio - Set up your language to English with format date to %d/%m/%y instead of %m/%d/%y - Enable Kanban view in Time Off dashboard with Studio - Compare Kanban and List view The list view dates is correctly formatted but not the kanban view dates ### Cause We use momentjs which doesn't take the user date format in account, only the locale. ### Solution Use a field with datetime widget which handle this case. **OPW-2195584**
Original PR description
### Issue - Install Time Off & Studio - Set up your language to English with format date to %d/%m/%y instead of %m/%d/%y - Enable Kanban view in Time Off dashboard with Studio - Compare Kanban and List view The list view dates is correctly formatted but not the kanban view dates ### Cause We use momentjs which doesn't take the user date format in account, only the locale. ### Solution Use a field with datetime widget which handle this case. **OPW-2195584** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45251
Delete the uom 'kg'(kilos, kilograms), open a product form view Traceback will popup because the hardcoded xmlid cannot find the value in the database since has been deleted. Adding a fallback fix the issue opw-2194659 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45197
Original PR description
Delete the uom 'kg'(kilos, kilograms), open a product form view Traceback will popup because the hardcoded xmlid cannot find the value in the database since has been deleted. Adding a fallback fix the issue opw-2194659 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45197
Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider a sales team ST in C1 - Let's consider that the partner of your current user is in ST - Log your user in C2 - Go to CRM > Sales > My pipeline - Create a lead Bug: An access error was raised. opw:2191517 Forward-Port-Of: odoo/odoo#45189
Original PR description
Steps to reproduce the bug: - Let's consider two companies C1 and C2 - Let's consider a sales team ST in C1 - Let's consider that the partner of your current user is in ST - Log your user in C2 - Go to CRM > Sales > My pipeline - Create a lead Bug: An access error was raised. opw:2191517 Forward-Port-Of: odoo/odoo#45189
Makes debugging possible without having to run the db locally and manually adding _loggers everywhere. Parts of the error are logged already, leading to messages like: ...payment_authorize.models.payment: The transaction was unsuccessful Unfortunately they don't show the reason. The entire response is something like: {'messages': {'message': [{'code': 'E00027', 'text': 'The transaction was unsuccessful.'}], 'resultCode': 'Error'}, 'trans
Original PR description
Makes debugging possible without having to run the db locally and manually adding _loggers everywhere. Parts of the error are logged already, leading to messages like:…
Makes debugging possible without having to run the db locally and
manually adding _loggers everywhere.
Parts of the error are logged already, leading to messages like:
...payment_authorize.models.payment: The transaction was unsuccessful
Unfortunately they don't show the reason. The entire response is
something like:
{'messages': {'message': [{'code': 'E00027',
'text': 'The transaction was unsuccessful.'}],
'resultCode': 'Error'},
'transactionResponse': {'SupplementalDataQualificationIndicator': 0,
'accountNumber': '',
'accountType': '',
'authCode': '',
'avsResultCode': 'P',
'cavvResultCode': '',
'cvvResultCode': '',
'errors': [{'errorCode': '5',
'errorText': 'A valid amount is '
'required.'}],
'refTransID': '',
'responseCode': '3',
'testRequest': '0',
'transHash': '',
'transHashSha2': '',
'transId': '0'}}
Since we log the full request above, let's also log the full response.
PS. this was present before but was lost with 26f3d8465d3c6f1da80c186.
opw-2188889
Forward-Port-Of: odoo/odoo#45249# Purpose Remove the domain that was limiting the reporting view. The goal of this reporting view is to allow managers to check what all salespersons are doing. task-2192589 Forward-Port-Of: odoo/odoo#44836
Original PR description
# Purpose Remove the domain that was limiting the reporting view. The goal of this reporting view is to allow managers to check what all salespersons are doing. task-2192589 Forward-Port-Of: odoo/odoo#44836
opw-2152644 Do not set the field writeoff_account_id as required if the payment_difference is zero because there is no writeoff in that case and the field is invisible. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45155 Forward-Port-Of: odoo/odoo#44664
Original PR description
opw-2152644 Do not set the field writeoff_account_id as required if the payment_difference is zero because there is no writeoff in that case and the field is invisible. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45155 Forward-Port-Of: odoo/odoo#44664
- Activate Developer mode - Go to Settings / Technical / Actions / User-defined Defaults - Create the following: Field: To Refund (update SO/PO) (stock.return.picking.line) Default Value (JSON format): true - Create a SO with a product invoiced based on delivered quantity - Validate the SO, validate the picking - Return the picking The field 'To Refund (update SO/PO)' is is not, while it should be. This is because we don't explicitly call the `default_get`, therefore only rely
Original PR description
- Activate Developer mode - Go to Settings / Technical / Actions / User-defined Defaults - Create the following: Field: To Refund (update SO/PO) (stock.return.picking.line) Default Value (JSON format): true - Create a SO with a product invoiced based on delivered quantity - Validate the SO, validate the picking - Return the picking The field 'To Refund (update SO/PO)' is is not, while it should be. This is because we don't explicitly call the `default_get`, therefore only rely on the default value of the field. opw-2172513 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#45202 Forward-Port-Of: odoo/odoo#45105
This factorization is needed for support purpose. I.E.: This will allow posting an account move to balance unbalanced journal entries. Basically, it divides the function into sections that were already present in comments. Forward-Port-Of: odoo/odoo#45145 Forward-Port-Of: odoo/odoo#44694
Original PR description
This factorization is needed for support purpose. I.E.: This will allow posting an account move to balance unbalanced journal entries. Basically, it divides the function into sections that were already present in comments. Forward-Port-Of: odoo/odoo#45145 Forward-Port-Of: odoo/odoo#44694
### Issue - Install CRM and at least 3 languages - Deactivate one of them - Go to CRM > Configuration > Activity Type - Edit an activity type and try to edit translation Traceback (Cannot read property '1' of undefined) ### Cause This is because all the translations are fetched but we don't look if the language they use is active. So at one moment, the relatedLanguage is undefined and we do relatedLanguage[1] ### Solution Filter the translation, to keep only t
Original PR description
### Issue - Install CRM and at least 3 languages - Deactivate one of them - Go to CRM > Configuration > Activity Type - Edit an activity type and try to edit translation Traceback (Cannot read property '1' of undefined) ### Cause This is because all the translations are fetched but we don't look if the language they use is active. So at one moment, the relatedLanguage is undefined and we do relatedLanguage[1] ### Solution Filter the translation, to keep only the ones with an active language. **OPW-2193969** -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#45139
Detected a bit late during testing... Task 2091654 Forward-Port-Of: odoo/enterprise#8432
Original PR description
Detected a bit late during testing... Task 2091654 Forward-Port-Of: odoo/enterprise#8432
- From Accounting Settings > Fiscal Periods > Fiscal Year; - Change fiscal year last day from December 31 to November 30; - Click Apply button An error is raised: 'Invalid fiscal year last day'. This is because the 2 fields (Month and day) are linked by the constraint `_check_fiscalyear_last_day`. However, non-stored writeable related fields are evaluated one at a time, meaning that the constraint is evaluated one value at a time. We do a fancy workaround to write the 2 values at o
Original PR description
- From Accounting Settings > Fiscal Periods > Fiscal Year; - Change fiscal year last day from December 31 to November 30; - Click Apply button An error is raised: 'Invalid fiscal year last day'. This is because the 2 fields (Month and day) are linked by the constraint `_check_fiscalyear_last_day`. However, non-stored writeable related fields are evaluated one at a time, meaning that the constraint is evaluated one value at a time. We do a fancy workaround to write the 2 values at once on the company, hence evaluating the constraint for the 2 fields once. Same fix as odoo/odoo@988018a5baa1a10ee44ea opw-2187056 Forward-Port-Of: odoo/enterprise#8424 Forward-Port-Of: odoo/enterprise#8390
- Create Company A & B - Activate 'Synchronize sales/purchase orders' for A & B - In A, create an RFQ for B with a section or a note - Validate A `ValidationError` is raised: `accountable_required_fields`. This is because the `display_type` is not propagated from the PO to the SO. We can propagate the value as well as stop filtering the lines. Filtering was introduced was sections and notes were not supported in PO. This is not the case anymore. opw-2195653 Forward-Port-Of: od
Original PR description
- Create Company A & B - Activate 'Synchronize sales/purchase orders' for A & B - In A, create an RFQ for B with a section or a note - Validate A `ValidationError` is raised: `accountable_required_fields`. This is because the `display_type` is not propagated from the PO to the SO. We can propagate the value as well as stop filtering the lines. Filtering was introduced was sections and notes were not supported in PO. This is not the case anymore. opw-2195653 Forward-Port-Of: odoo/enterprise#8421 Forward-Port-Of: odoo/enterprise#8402
Forward-Port-Of: odoo/enterprise#8407
Original PR description
Forward-Port-Of: odoo/enterprise#8407
Commit https://github.com/odoo/enterprise/commit/161585d4fbcac25d9f5bcbaa809630e25d1b46c6 was improving the way we fetch the tax repartition lines but it should return account.tax references as it was the case previously. opw-2179959 Forward-Port-Of: odoo/enterprise#8406 Forward-Port-Of: odoo/enterprise#8400
Original PR description
Commit https://github.com/odoo/enterprise/commit/161585d4fbcac25d9f5bcbaa809630e25d1b46c6 was improving the way we fetch the tax repartition lines but it should return account.tax references as it was the case previously. opw-2179959 Forward-Port-Of: odoo/enterprise#8406 Forward-Port-Of: odoo/enterprise#8400
Forward-Port-Of: odoo/enterprise#8405
Original PR description
Forward-Port-Of: odoo/enterprise#8405
In the next case: 1. Generate an Mexican invoice and sign it. 2. Make the invoice payment with a bank statement and generate the payment complement. 3. Un-reconcile the bank statement. In this moment Odoo, remove the move in the payment generated from the bank statement and unlink the record the payment. In 88c2666 was improved to avoid unlink a payment if the PAC status is ``signed``, but in some cases the payment cannot be cancelled, and the PAC status is ``to_cancel``. For this
Original PR description
In the next case: 1. Generate an Mexican invoice and sign it. 2. Make the invoice payment with a bank statement and generate the payment complement. 3. Un-reconcile the bank statement. In this moment…
In the next case: 1. Generate an Mexican invoice and sign it. 2. Make the invoice payment with a bank statement and generate the payment complement. 3. Un-reconcile the bank statement. In this moment Odoo, remove the move in the payment generated from the bank statement and unlink the record the payment. In 88c2666 was improved to avoid unlink a payment if the PAC status is ``signed``, but in some cases the payment cannot be cancelled, and the PAC status is ``to_cancel``. For this reason, now in the unlink process is updated the SAT status and only allow unlink if the CFDI is cancel in the SAT. Cases: 1. Payment complement was not generated, maybe the bank statement is an advance and the payment generated do not have invoices related. In this case, the payment do not have CFDI and allow remove without problem. 2. Payment complement generated but not was signed. When the PAC status is in 'to_sign' or 'retry' and is called the method ``_l10n_mx_edi_cancel``, automatically the ``l10n_mx_edi_pac_status`` is False and allow unlink the CFDI. 3. Payment signed, try unlink but the payment cannot be cancelled. In this case, the SAT status must be ``to_cancel``, and the SAT status ``Valid``, then the payment cannot be unlink. 4. Payment signed, cancel correctly. In this case the payment could be removed. Note: In test instances is not possible get the SAT status = cancelled, for this reason, in test is omitted this validation. Forward-Port-Of: odoo/enterprise#8055
- Activate UoM - Create a subscription with the monthly demo product The UoM is set to Unit(s) instead of Month. This comes from [1] and [2]. We force the UoM at product change. [1] https://github.com/odoo/enterprise/blob/41b6ff000f099c86a2fbde2dcd0e7672b12b5975/sale_subscription/models/sale_subscription.py#L876 [2] https://github.com/odoo/enterprise/blob/41b6ff000f099c86a2fbde2dcd0e7672b12b5975/sale_subscription/models/sale_subscription.py#L922 opw-2187862 Forward-Port-Of: odo
Original PR description
- Activate UoM - Create a subscription with the monthly demo product The UoM is set to Unit(s) instead of Month. This comes from [1] and [2]. We force the UoM at product change. [1] https://github.com/odoo/enterprise/blob/41b6ff000f099c86a2fbde2dcd0e7672b12b5975/sale_subscription/models/sale_subscription.py#L876 [2] https://github.com/odoo/enterprise/blob/41b6ff000f099c86a2fbde2dcd0e7672b12b5975/sale_subscription/models/sale_subscription.py#L922 opw-2187862 Forward-Port-Of: odoo/enterprise#8387 Forward-Port-Of: odoo/enterprise#8372