Daily updates from Odoo
Navigate
Branch
Thursday, March 19, 2020
9 changes
Enhancements to existing features
Settings pages across several Odoo apps now use a question mark icon for documentation links instead of a book icon. The updated color and size make these help links more consistent with the rest of the interface and easier to recognize.
Original PR description
Purpose ======= - Change the font-awesome icon from fa-book to fa-question. - Change the icon color to text-secondary (the same than the multi-company icon). - Adjust the icon size to the uppercase text size. TaskID: 2209062
Odoo Studio now lets users add an avatar-style image to eligible form views, similar to contact or product pages. Users can choose an existing image field or create a new one, making forms more visual and easier to identify at a glance.
Original PR description
**PURPOSE** - Allow the user to add an 'avatar' picture at the top right of the sheet, like in the contact or product formviews. **SPECIFICATION** - add a grey hook 'Add picture' where the image would show same design that for the pipeline statusbar hook - when clicking the hook, the user is prompted to select the image field to display similar to adding a priority field on the kanban view. - the field is added right before the title <div>, with widget="image" and class="oe_avatar" Task: 2172320 Closes: https://github.com/odoo/enterprise/pull/8176
The helpdesk-related test suite was updated to match a change where products now invoice based on delivery by default instead of sales order. This keeps automated checks aligned with the current business workflow and helps prevent false test failures.
Original PR description
The default invoice policy is now 'delivery'. Tests assuming the previous default value 'order' need to be adapted. Related odoo/odoo#47526 Task 2159161
Odoo Studio now automatically selects the current document field when users add fields to reports or set visibility rules. This reduces confusing choices for most users while still allowing advanced users to choose a different source when needed.
Original PR description
task - https://www.odoo.com/web#id=2058702&action=327&model=project.task&view_type=form&menu_id=4720 pad - https://pad.odoo.com/p/r.50444f91ae4d457c61a3465732f117ab When adding a field in report or defining the visibility, 95% of the time, user will be using field on the model (itself). For better usability, to pre-select "doc" in the field selector, making it easy for most users while still allowing advanced users to go back and pick another item than 'doc'. By this commit, this goal has been achieved.
Resolved issues and error corrections
This update removes a compatibility warning that appeared with newer Python versions. It helps keep system logs cleaner and reduces noise for teams monitoring application health, without changing user-facing behavior.
Original PR description
3.8 triggers a deprecation warning using is/is not with a literal
Code cleanup and technical improvements
The mail enterprise test setup was updated to better match how Discuss is opened and closed in the live application. This is an internal quality change that helps tests reflect real usage more accurately and removes an obsolete safety check.
Original PR description
In community, the 'createDisuss' helper has been updated to use 'dom.prepend' to benefit of its 'on_(attach|detach)_callback' calls. This allows the mail test suite environment to be closer to the actual action behaviour (having those methods called each time it is created/destroyed). This is why one of the mail tests which asserted specifically that the action would not crash when using these methods has been removed. Community PR: https://github.com/odoo/odoo/pull/47865
Miscellaneous changes
Main - By adding _l10n_mx_edi_invoice_payment_data() into l10n_mx_edi_payment_data() method other implementations can leverage upon the Mexican localization without having to break other inheritance made on this method. Explanation - We can want to keep `l10n_mx_edi_payment_data()` method as intact as possible by adding `_l10n_mx_edi_invoice_payment_data()` which will avoid to override the whole method in other implementations that depends in l10n_mx_edi [f] and we want to comp
Original PR description
Main - By adding _l10n_mx_edi_invoice_payment_data() into l10n_mx_edi_payment_data() method other implementations can leverage upon the Mexican localization without having to break other inheritance…
Main - By adding _l10n_mx_edi_invoice_payment_data() into l10n_mx_edi_payment_data() method other implementations can leverage upon the Mexican localization without having to break other inheritance made on this method. Explanation - We can want to keep `l10n_mx_edi_payment_data()` method as intact as possible by adding `_l10n_mx_edi_invoice_payment_data()` which will avoid to override the whole method in other implementations that depends in l10n_mx_edi [f] and we want to compute the Totals on the payment in another fashion by only overriding `_l10n_mx_edi_invoice_payment_data()` method, if needed. `_get_payments_vals()` method computes the values of multi-currency payments in a fashion that sometimes becomes weird-ish [i] & [j]. Because of the way reconciliation is performed when dealing with multi-currency journal items [a]. _get_payments_vals() method has already a pending pending PR [b] trying to solve issue [c]. Since the way of reconciliation can lead to issues like [d] though that method has been fine tuned here [e] and given that issue in [c] has been closed but is still standing. Hint: `_get_payments_vals()` method relies on partial reconciliations [h] we want to have another way to compute the values returned by future `_l10n_mx_edi_invoice_payment_data()` method and use a new implementation where partial reconciliation is not paramount in that computation. Which will allow us to gather more knowledge in this process and get back to here in the future and provide either a solution in the core or in the enterprise. enterprise-mx CI - https://git.vauxoo.com/vauxoo/enterprise-mx/merge_requests/696 Conclusion - In having this code atomized only the part that is concerning to us [g] will be overridden and no harm is done on the core functionality. References - [a] https://github.com/odoo/odoo/pull/41512 [b] https://github.com/odoo/odoo/pull/37620/files#diff-f3712147f4b25231caa371bd83265dbeR208 [c] https://github.com/odoo/odoo/issues/37469 [d] https://github.com/odoo/odoo/issues/29446 [e] https://github.com/odoo-dev/odoo/commit/51bd866b47bd7e6d6e9b9aa898ef347af1210a38 [f] https://github.com/odoo/enterprise/blob/12.0/l10n_mx_edi_payment_bank/models/account_payment.py#L23 [g] https://github.com/odoo/enterprise/blob/12.0/l10n_mx_edi/models/account_payment.py#L458 [h] https://github.com/odoo/odoo/blob/12.0/addons/account/models/account_invoice.py#L190-L213 [i] https://github.com/odoo/odoo/issues/37469#issuecomment-544487090 [j] https://github.com/odoo/odoo/pull/39117/commits/c5658ebea08174389a7061e698a9274275ee19d0 Forward-Port-Of: odoo/enterprise#9251 Forward-Port-Of: odoo/enterprise#7940
Steps to reproduce: 1. Open "Documents" app 2. Click on "Filter..." to open the left panel 3. Click on a tag The problem was that users were thinking that "Select..." located in the modal was a field. Theses following changes will be applied: - Rename 'Filter...' to 'All'. - Add "Filters" as the modal name. - Remove the current selected filters from the dialog. - Remove the flickering animation on tag selection change. Linked to #8734 Task ID: 2200099 Forward-Port-Of: odoo
Original PR description
Steps to reproduce: 1. Open "Documents" app 2. Click on "Filter..." to open the left panel 3. Click on a tag The problem was that users were thinking that "Select..." located in the modal was a field. Theses following changes will be applied: - Rename 'Filter...' to 'All'. - Add "Filters" as the modal name. - Remove the current selected filters from the dialog. - Remove the flickering animation on tag selection change. Linked to #8734 Task ID: 2200099 Forward-Port-Of: odoo/enterprise#9106
Two things in this PR, changing things in the matching of sale orders in the reconciliation widget: - It is unlikely that anyone would make an empty transfer for a SO with a zero amount, by ignoring these lines we save on the costly `POSITION` searches. For example the `website_sale_event` App can lead to a high number of SO with a zero amount (registrations for free events). - Add an (undocumented) switch to completely disable SO matching if it slows things too much and is not considered impo
Original PR description
Two things in this PR, changing things in the matching of sale orders in the reconciliation widget: - It is unlikely that anyone would make an empty transfer for a SO with a zero amount, by ignoring…
Two things in this PR, changing things in the matching of sale orders in the reconciliation widget: - It is unlikely that anyone would make an empty transfer for a SO with a zero amount, by ignoring these lines we save on the costly `POSITION` searches. For example the `website_sale_event` App can lead to a high number of SO with a zero amount (registrations for free events). - Add an (undocumented) switch to completely disable SO matching if it slows things too much and is not considered important for that database. Performance-wise, for a company with 700 bank statement lines and 16K SO matching the other criteria, the SO matching query has to perform 22M string searches (twice per row, each being *O(n^2)*), resulting in a query lasting 11.5s on modern hardware. Without the SO matching the normal search on journal items runs in 2.5s. For the record, changing the `POSITION` substring search to a plain `=` reduces the search time by orders of magnitude (back at 2.5s basically), but it's mostly useless from a functional point of view, so not an option. This demonstrates the impact of the n^2 complexity. Forward-Port-Of: odoo/odoo#47185 Forward-Port-Of: odoo/enterprise#9228 Forward-Port-Of: odoo/enterprise#9218