* modify client-side domain normalisation to error if the domain is invalid (not enough terms / segments for the number of operators) * add better error reporting to attrs / modifiers parsing * add a few layered error augmentation to provide clearer context e.g. "error: invalid domain <thing>" is helpful but "error while parsing modifiers for field foo: modifier invisible: invalid domain <thing>" is much more helpful * rework _evalModifiers to deduplicate it in order to more easily implement this contextual augmentation * test that improper domains are properly found improper * fix a bunch of incorrect attrs domains * also removed an apparently undefined (& unused) "options" argument to a _applyModifiers call closes odoo/odoo#44642 Related: odoo/enterprise#8175 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The old tree views don't really exist anymore, this odd pseudo-flag to dispatch between "list" and "tree" tree views has no reason to remain. Task 1937686 closes odoo/odoo#31243 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Task 1843603 * src_model is redundant with binding_model_id * multi -> binding_view_types (if empty => all views) (maybe should be empty by default yo?) * in convert, type => rec.get(type) but no @type possible on <act_window>... * removed deprecated auto_refresh & auto_search (not used anywhere (?)) closes odoo/odoo#24738 Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit allows the user to link some mail template to activity type with res_model. When a activity has template, buttons appears in activity, allowing the user to send mail based on templates. Task: #1844563 PR: #25620
BS4 "btn-default" class was replaced with "btn-secondary", which makes more sense.
This action allowing to send a mass mailing with a default template on a partner is defined twice in mail on same object, with same xml_id. See in composer views for the other definition. This commit is linked to task ID 1843361 (and 1868112) and to PR #25287 (and #25889).
Add an onboarding panel for invoicing, it appears above the invoice list. After going through the steps the system should be all set to send real invoices. In the payment module, add a payment acquirer step and add it to the invoice onboarding panel. task: 60668
Purpose ======= The Contact form is one of the most used/important view. It is quite important to find the piece of information easily and to navigate in a few clicks to the related views. Specification ============= Stat buttons ------------ - Restructure stat buttons with the following order: Opportunities -> sales user Meetings -> sales users Sales -> Sales users POS Sales -> pos users Subscriptions -> Subscription users Events -> event user Tasks -> project user TIckets -> helpdesk user Purchases -> purchase user Due -> billing: user Invoiced -> billing: user Vendor Bills -> billing: user Customer/Vendor Partner Ledger -> accounting: billing Analytic Accounts -> accounting: billing Credit Cards -> sales user Direct Debit Mandates -> accounting: billing user Publish - Use better/more relevant icons - Check that the proper access rights are set - Remove the bank accounts stat buttons and replace it by a one2many tree on the Invoicing page. Fields ------ Move some res.partner fields from the "Accouting" page to the "sale & Purchase" page: - Fiscal positions - Payment terms Miscellaneous ------------- - Remove dead code. - Display nothing instead "Please complete customer's informations and email" on the popup when sending an email to a contact without email address.
During first scss convertion, classes called as mixins were changed to an @extend instruction which was the best approximation given the fact there is no equivalent in sass to do that. The problem is that the instruction is slowing the scss computation a lot and might also break the style in unexpected ways because of the complex unwanted selectors the instruction induces. This commit removes the need of extends. This is done case per case. Sometimes this involves adding classes in xml, sometimes to change the style a little, ... The button rendering refactoring which was made at the start of the LESS to SASS merge was also done in prevision of this. After this commit, sass computation is like 5-6 times faster than less computation while it was like 10 times *slower* before this commit.