Tuesday, April 16, 2024
11 changes · 17.0
Enhancements to existing features
This update enhances the visual design of the remote work feature by adjusting the spacing around the "Set Location" button in the calendar interface. The improvement makes the button more visually balanced and easier to interact with, providing a better user experience for employees managing their work location settings.
Original PR description
This commit adds slight improvement to the design of remote work by adding margin to "Set Location" button. task-3693392
Resolved issues and error corrections
The "Use on eBay" column position has been adjusted to match between the form and tree views in the eBay sales module. The column was moved to appear after the "Active" column to maintain consistency and keep related currency columns together, improving the user interface organization.
Original PR description
The column "Use on eBay" was located between "Unit per <currency>" and "<currency> per Unit" columns in the currencies tree view. It was therefore moved after the "Active" column, the same location it has in the form view. The columns "Unit per <currency>" and "<currency per Unit" should always be located next to one another. And the location of "Use on eBay" column should be consistent in both the form and tree views. task-3856386
Miscellaneous changes
Before this commit: * when a user changes 'user_id' to set the same previous 'user_id', the assign date 'date_open' is updated but it should not as the responsible did not change; * when a user changes the salesperson 'user_id' of a crm lead, it triggers a recompute of 'team_id' that triggers a recompute of 'stage_id' that updates 'date_last_stage_update' even if the stage does not change, which happens frequently when changing leads within a given team (new assig
Original PR description
Before this commit: * when a user changes 'user_id' to set the same previous 'user_id', the assign date 'date_open' is updated but it should not as the responsible did not change; * when a user…
Before this commit:
* when a user changes 'user_id' to set the same previous 'user_id', the
assign date 'date_open' is updated but it should not as the responsible
did not change;
* when a user changes the salesperson 'user_id' of a crm lead, it triggers
a recompute of 'team_id' that triggers a recompute of 'stage_id' that
updates 'date_last_stage_update' even if the stage does not change, which
happens frequently when changing leads within a given team (new assign,
salesperson on holidays, ...)
* when merging opportunities, 'user_id' can be set on the main opportunity
which triggers a recomputation of both 'date_last_stage_update' and
'date_open' as explained in above points;
Reason:
The 'date_last_stage_update' field depends on 'stage_id' which depends on
'team_id' which depends on 'user_id'. As a result, when 'user_id' changes,
'date_last_stage_update' also updates.
Moreover those fields are implemented using editable stored computed fields
which are triggered everytime a value is given to those fields, even when
the same value is given.
After this commit:
'date_last_stage_update' and 'date_open' will only update when there are
real changes.
Also fix 'date_open' update when lead is converted into an opportunity.
'date_open' is the date when a user is assigned to a lead / opportunity. It
should not be set when converting a lead to an opportunity, as those two
flows are different. Only setting a responsible should update it.
Task-3515225
Forward-Port-Of: odoo/odoo#144848A unit test for Argentine fiscal vouchers (bono fiscal) in the EDI module has been temporarily removed because the AFIP test environment has implemented new restrictions that require adaptation. The test will be restored once AFIP resolves the underlying issues on their end. This is a temporary measure to prevent test failures while waiting for the external system to be updated.
Original PR description
It is not working because some issues with AFIP test envrionment that added new restrictions that need to adapt- In this case we depend on AFIP to solve it and we do not know when we will have a solution. After everything is ok we will re add the test. Forward-Port-Of: odoo/enterprise#60577
A previous update changed the text of a customer-facing email template in the Helpdesk module. This fix updates the translation template file to reflect that change, ensuring all language translations stay synchronized with the current email content.
Original PR description
Commit 2740da2701557da09566aa25f064fe3cac7a881a modified a mail template's subject, which is translatable. Update the .pot file to reflect the change. opw-3748509
This fix resolves an issue in the Mexican EDI (Electronic Data Interchange) import tests where duplicate partner records were preventing proper customer identification during invoice imports. By removing conflicting demo data, the system now correctly identifies and matches customers when importing Mexican invoices (CFDIs), eliminating unnecessary duplicate customer creation.
Original PR description
When importing a CFDI, we try to retrieve the partner (see `_retrieve_partner`). If more than one partner is retrieved, the partners are not returned. During the `_l10n_mx_edi_import_cfdi_fill_partner` test, there exists two partners with the same VAT (one has a company_id, the other doesn't). Hence, when importing the bill, the `_retrieve_partner` will find 2 and will not return anything, and we end up creating a new partner. To fix that, we remove the VAT of the partner from the demo company. Thus, only one partner will be retrieved. opw-3829223 Forward-Port-Of: odoo/enterprise#60506
A previous fix that added support for the Array 'at' method in older browsers had an unintended side effect: the method was appearing in loops that iterate over object properties. This update corrects that issue by properly hiding the method from these loops, ensuring the code behaves as expected without affecting application functionality.
Original PR description
Commit [1] introduced a fix for old browsers to make the `at` method of the Array class. It did so by simply adding a property on the prototype of the Array class. Unfortunately this way of adding a method means that it is exposed in `for...in` loops. To avoid this, this commit uses Object.defineProperty and sets the property as not enumerable, removing it from the for..in loop. [1]: https://github.com/odoo/odoo/commit/6e39e31030c28a8eb09ddcd93ca9ca382b4f6f10 opw-3824593
This update corrects an internal logic issue in how credit limits are calculated for customer accounts. The fix ensures that company information is properly handled during the calculation process, improving the accuracy and reliability of credit limit determinations.
Original PR description
While in practice you would never get this inverse called with more than one record at a time, it is still wrong to get the company of self in the loop. Fixing it to keep good conscience :) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161815
This update removes a duplicate styling class that was appearing twice in the Record Selector component, which could cause inconsistent styling behavior. By cleaning up this duplication, the component now applies styles more predictably and reliably, improving the overall user interface consistency.
Original PR description
This commit removes the unnecessary duplicate of the 'o-input' class being present in the template of the (Multi)RecordSelector components. As the RecordAutocomplete component uses the Autocomplete component, which already set this classname on its <input> node, the class was present twice in the DOM. This could affect the style when trying to write a rule on .o_input since both elements would get the style. Now, only the input keep the class, which makes things easier and more predictable.
This update corrects a bug where column visibility settings were being incorrectly overwritten in the language management interface tree view. The fix ensures that column visibility preferences are properly preserved and displayed as intended, improving the user experience when managing language configurations.
A performance test for the website blog module was causing random failures and wasn't providing meaningful results. This update removes the problematic test to improve system reliability and reduce false test failures.
Original PR description
Since [this commit], the `test_10_perf_sql_blog_standard_data` test failed randomly. As testing sql perf for website without cache doesn't really make sense (as explained in [this other commit]) we can can just remove the test without cache. [this commit]: https://github.com/odoo/odoo/commit/88b016fdc407e318c43c96df9b582853512f04fa [this other commit]: https://github.com/odoo/odoo/commit/dad8dca0da23143eb2f28debde5139e907368a2e runbot-55755