The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Purpose
=======
Fix the inline input fields which
width seems broken because of the new
always edit mode.
Specifications
==============
Fix the leads generation form inlined inputs
display by reducing the inputs width to match
their content display.
Fix the lead form view to align the expected
revenue with the probability for better UI.
Fix the geolocation field and send email button
of the Assigned Partner form tab by restoring
their inline property. Because of the form
grid layout, nested groups had to be used to
correctly restore the display. Alternative solutions
modify the DOM too much, which could lead to more
xpath and inheritance issues.
Task-2996467
X-original-commit: 8edd4c96ddd1fc48ea0a1b6607233f018b4cf52a
Part-of: odoo/odoo#106570
The goal of this revision is to add a group
`mail.group_mail_notification_type_inbox` which is granted
automatically when the user `notification_type` is set to `Inbox`
to be able to easily hide the filter `Unread messages` when
the user uses the `Email` notification type,
by simply adding `groups="mail.group_mail_notification_type_inbox"`
on the filter rather than overriding `_get_view` in every model.
The code overriding `_get_view` of `project.task`
to hide the filter "Unread messages" replaced
in this revision initially comes from
odoo/odoo@da868d28e2
> - In project.task search View:
> - the filter for unread messages should be visible only if the current user
> managing his notifications in Odoo
The above revision was part of the task 2844212
closesodoo/odoo#104328
Related: odoo/enterprise#33338
Related: odoo/upgrade#3996
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Before this commit, when using the `many2one_avatar_user` on the `user_id`
field of the crm tree views, an error was thrown because the domain of `user_id`
refers to `user_company_ids` which the view did not have access to, so it
wasn't yet computed.
The field was added in invisible to the tree views so that it can be computed
before being accessed.
Task-3053146
closesodoo/odoo#105688
X-original-commit: 558607d98798d6a55adbcd98a6648a888286c3c9
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
In the quick create form views in CRM, the 'recurring_plan' field is missing
(or rather invisible). It is a required field so it prevents the use
of the quick create.
The purpose of this commit is to let it be visible again to users.
Task-3007756
closesodoo/odoo#105311
X-original-commit: d0deb895bba8deeddb95fc8919ded29b80a869f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
At the moment, the tree view is quite dense. In order to ease its
use, make company and phone fields optional and hidden by default.
This is done for crm.leads as both leads and opportunities.
Task-3053159
closesodoo/odoo#104759
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
We don't use the properties field in the leads kanban view.
Because of this, we want to hide the option "View In Kanban" in
the properties definition.
Task-3012780
X-original-commit: 8170e2aede666a4ab2b2395cc3c2d54a87e11cc1
Part-of: odoo/odoo#104252
Purpose:
In the Forecast view of the CRM module, when recurring revenues are activated,
they are not shown in the progress bar of each stage of the kanban view. Only
the prorated expected revenue (non-recurring) are shown. In the regular
kanban view, they are shown.
To display them, we extended the CrmKanban view, which already possesses this
behavior, since behaviors relevant to the CrmKanban view are also relevant
to the ForecastKanban view.
As for the forecast kanban cards, when recurring revenues are activated,
they show "regular" recurring revenues instead of "prorated" recurring
revenues. Expected revenues are prorated. This is misleading for users.
The goal is to show prorated recurring revenues instead of just
recurring revenues.
Task-2994146
Task-3006404
closesodoo/odoo#102037
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
Purpose: split words with whitespace, as it's usually done.
Task-3004227
X-original-commit: c86f4c79326d6df78b434e103141bffb826b19db
Part-of: odoo/odoo#103257
Remove the field `crm_statusbar` as it dosen't have a specific
behaviour, and we can use the classic `statusbar` field instead.
closesodoo/odoo#102992
X-original-commit: 386fa0a5e448f149e75da68a02ad94dd88cc4d08
Related: odoo/enterprise#32669
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Purpose
=======
To be able to customize the working flow on the lead, based on their
team, we add a properties field on leads, whose definition is stored
on their team.
Include the properties value in the merge message to keep the history
of the properties value if they have been overwritten during the merge
process.
Task-2965523
X-original-commit: 4722cc4b1fb027b7b9d731c3b206656588071360
Part-of: odoo/odoo#101487
*: crm,link_tracker,project,sale,utm
Before this commit, in some form and kanban views, there were
missing whitespaces, typically between icons and texts. This was
due to the transition to owl views, because we simply ignored
`&nbsp;` in archs. This commit also fixes a layout issue in
a project view, where the icon and the field should be displayed
in the same line.
closesodoo/odoo#101040
X-original-commit: f5813e348b6052436a4fabaa5837ecc37b15430e
Related: odoo/enterprise#31746
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the `res.partner` form:
- the field `user_id` is set in base,
and is directly within the base res.partner.form form view,
within the `Sales & Purchase` notebook page
(which is in the base module despite what the tab name could make think)
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/odoo/addons/base/views/res_partner_views.xml#L343
- the field `team_id` is set in the module `sales_team`, and added
in the res.partner.form form view from this `sales_team` module
https://github.com/odoo/odoo/blob/f294079a8946e88f0564dc96bf8a9531958697fe/addons/sales_team/views/res_partner_views.xml#L9
Therefore, there isn't any obvious reason why the context `default_`
keys for `user_id` and `team_id` are set
only once the `crm` module installed,
neither why it only applies if you are a salesperson
(to the group `sales_team.group_sale_salesman`, sets in the view
`groups_id`).
If we have a look to the commit
f0b7600314
The goal described in the commit description is still achieved
by moving these default context keys in their respective module.
Besides, having a closer look in this commit,
`default_user_id` is directly added in the simplified partner form
within the base module, but is added through the crm module
for the regular form. Which doesn't make really sense.
Part-of: odoo/odoo#98551
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
*: point_of_sale, website
This commit fixes the style of the settings affected
by changes during the conversion to Owl.
Because of the new DOM of fields, some elements displayed
using the 'row' class were not horizontally aligned
because of the changes made to the DOM of the field that
were used. As the layout have changed, it was needed to
adapt and add new styling class in the template.
closesodoo/odoo#98387
Signed-off-by: Samuel Degueldre <sad@odoo.com>
This commit improves the helper message in team member action
task- 2583755
closesodoo/odoo#92616
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, two lost buttons will appear, if you go to the form view of a lead that has 100% probability. The difference between the two duplicated "Lost" buttons is that one ask for a "lost reason" before marking a lead/opportunity as lost, the other does not.
After discussing with the PO for CRM, it appears that the button that asks for a "lost reason" should not appear on a lead. This commit makes the necessary changes to reflect that behavior.
opw-2886623
closesodoo/odoo#96486
X-original-commit: 707bddefdc5604db3304afa3633a0b90027f78b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Currently, if you try to create an opportunity through the smart button on a contact form, a lead is created.
A lead created from a customer should be an opportunity.
opw-2886623
closesodoo/odoo#96268
X-original-commit: 415c8393f25ab47da45d15ebc455660bfa440389
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With commit[1], we added `o_text_overflow` classes at several places to avoid
long names going out of the boxes. However, for the name/title fields in the
form views, we should always show the full name.
So this commit replaces `o_text_overflow` class with `text-break` from
name/title fields in the form views to display full string in the read
only mode, but also keep them from going outside of the form view.
Below are the modules affected:
- base
- coupon
- crm
- event
- mass_mailing
- mass_mailing_sms
- project
- sales_team
commit[1] - a0ebb46
task-2889845
closesodoo/odoo#96132
X-original-commit: 4a74c7af6b54bd771f50d3885813f4aae442c9e7
Related: odoo/enterprise#29552
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit allows multiple salespersons to collaborate on a lead without
erasing each other's data.
closesodoo/odoo#95042
Taskid: 2900372
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit removes the unnecessary measures(like partner latitude/longitude)
from the lead related graph views. Also, we try to order the measures and keep
time related measures(Days to Assign, Days to Close, Exceeded Closing Days, etc)
first and revenue related measures(Expected Revenues, Prorated Revenues, etc)
last.
Note that with this commit, recurring revenue related measures will be displayed
only when the feature is activated.
ent PR: https://github.com/odoo/enterprise/pull/21981
Task-2674367
closesodoo/odoo#79167
Related: odoo/enterprise#21981
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit does below improvements:
1/ If salesperson and sales team are set on an individual partner, we propagate
those to parent company being created from m2o of the form view.
2/ If the existing parent company is manually linked to an individual partner
being created, and salesperson and sales team are not set on the individual,
we set those values from the linked parent (if set on the parent).
Task-2636290
closesodoo/odoo#78696
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
For bugfix purposes, app administration groups have been given to
(implied by) the "Settings" group because without those rights,
opening/saving the settings crashed.
1) Do not load hidden view content
This commit uses the conditional inheritance of views
(depending on user groups) to avoid loading unnecessary view
& record content client-side.
This improves performance for admins without the specific application
admin rights, but also fixes the main bugfix problem,
caused by the webclient querying name_get for the records in relational
fields content.
Example:
sale_management adds a res.config.settings field to specify
the default sale.order.template for the current company.
If a 'Settings' user without 'sale.group_sale_manager' opens the
settings, he won't see this setting, but if a default template is
specified for the current company, the webclient will still request
the name_get of this template to the server, because the field
was present in the view, only hidden with a groups attribute.
With this commit change in sale, the field won't be in the view unless
you have the Sale manager group, avoiding the error/traceback/bug.
2) Remove implied application administration groups
Do not force the specific application groups on all 'Settings' user,
they globally do not need those rights, and if they need it, they
can add it to their account themselves.
3) Add a test to make sure settings user are able to manage settings.
4) Enforce 'settings' -> 'access rights' -> 'internal user' groups
As the previous test highlighted some 'false positives' because
it considered a settings user unable to read `crm.team`
and `stock.warehouse` records, we also took the opportunity to enforce
the fact that 'Settings' & 'Access rights' users must be internal users.
It makes no sense for a portal/public user to have access to the
settings, and didn't work anyway.
Part-of: odoo/odoo#91909
SPECIFICATION
Various change for the partner view:
- Moved the activity widget to the bottom right of the kanban
- Moved the informations badge to the bottom right next to the
activity widget and made them clickable
- Change the address options order and add a small help below
- Change the 'Remove' button function from delete to remove from
the company and add a delete button to the right end.
- Correct some typo
- Add an 'Archived' ribbon to the kanban card
- Change various small things
LINKS
Task-2821356
closesodoo/odoo#89249
Related: odoo/enterprise#26442
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Revert the possibility to install languages from the form views
of opportunity/lead and partner.
We consider that the quick installation of languages is too
advanced and admin people can go through the dedicated menu if
need be.
task-2839020
closesodoo/odoo#91750
X-original-commit: 5a616997659b2359ec946883b620e2fae6d6c39d
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit shows the sum of field 'recurring_revenue_monthly' on
leads' kanban progressbar next to the sum of 'expected_revenue',
if the recurring revenu is enabled for logged in user.
taskID-2414576
closesodoo/odoo#66237
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Add "Activate" button when selecting multiple languages, select multiple
languages when clicking on "Add languages" in settings.
Specifications
=============
`lang` variable in `base.language.install` changed from Selection to
Many2many to allow multiple languages being activated at once.
Hide globe icon for language fields from view mode (only visible when
editing). Remove state in base.language.install since it's no longer
need to keep track of the installation step.
Task-2662548
closesodoo/odoo#78287
Related: odoo/upgrade#2921
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Add globe button next to language for leads and opportunities if the
database is in multi language mode and user has enough access rights.
User is also unable to edit language from view
PR: odoo/odoo/pull/78287
Task-2662548
Part-of: odoo/odoo#78287
Bug
===
If we
1. Open a lead with an email but without partner
2. Set a partner without email on the lead
3. The warning "The email will be propagated" is visible
4. When saving the form, the email is not propagated even if the
warning message was visible
Solution
========
The reason is that, as the email was not changed, the inverse method
of this field was not called and so the email was not propagated.
The best solution would be to use "force_save" on those fields. But
this feature only works on readonly fields.
So, we simulate a real "force_save" on the email / phone, directly in
JS. That way the inverse will be called, and if necessary, the email /
phone will be propagated.
Task-2704904
closesodoo/odoo#84618
X-original-commit: 1d548c7eadcd25b97856c4769759358f86e00640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: flch-odoo <flch@odoo.com>
PURPOSE
Improve performance in often used views and fields in a normal Odoo usage.
SPECIFICATIONS
On crm.lead model
* remove field user_email and user_login fields. Those are related non stored
and used in kanban for no reason (or even not used). Those can be removed
completely;
Original commit seems to be odoo/odoo@ea2e8b64c4 which seems to show those
fields were added to add a gravtar based on user email, and its login was used
to display "responsible". Maybe an internal Odoo related spec, anyway not used
anymore.
Task-2752043
Part-of: odoo/odoo#83806
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Better aligns the stars with the label when no expected deadline is set,
by styling the parent div to space out non-empty children.
Task-2709761
closesodoo/odoo#81358
X-original-commit: 61925f488557181ae691d222a142a242c939d3e0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*mass_mailing_crm, mass_mailing_sale
Currently, the Mailing stat buttons have a few problems.
The business reporting smart buttons send the user to a list of linked records,
which doesn't provide much value (e.g. what is the user supposed to do with a
list of 12345 leads?). They also show wrong values depending on access rights.
The Mailing KPI smart buttons lead to a blank screen if there's no data to show.
In this commit, we add/adapt all action helpers to help users understand what is
going on. For the business reporting smart buttons we instead send users to
relevant reporting actions, so they can make sense of the data we showed before.
The values of the business reporting smart buttons are now calculated as a super
user.
We also change some domains from the whole UTM Sale Domain to only using
Source ID, which simplifies computation while staying accurate.
task-2604515
closesodoo/odoo#76798
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
This commit simply re-organizes a few fields on the crm.lead form view to give
more visibility to the most important information and to give more space to the
"Notes" section.
Task-2677144
closesodoo/odoo#80591
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Julien Banken <jbn@odoo.com>
Purpose
=======
As a Lead Manager, I do not really care about what's in the "Lead Pipeline"
since this does not exist. Instead, I want to keep an eye on all the leads that
entered the CRM to see how well they are doing and how they are spread.
Specifications
==============
- Remove the group on the Reporting
> Leads menu item, this menu can be used with Opportunities only
- Move it below the Pipeline report
- By default, this menu shows all crm.lead :
- no matter the type (lead/opp) but with the filters in the search view
if needed
- no matter if won/active/lost (but again, filters allow me to change that
if needed)
- Default grouped by month creation date
- Filtered on records created this year to avoid displaying 10 years of CRM
usage - already done
=> The difference if I activate leads is that then I have the extra filters, ...
but this is already valid if I'm only working with opportunities
Also, on the report list view of the leads, this commit brings some small
modifications in order to have a better view of what kind of lead and 'where'
they are:
- Hide by default the "City" field
- Add "Type" field before "Probability" field (only if Leads are activated)
- Add "Stage_id" after "Type" field
Task-2671372
closesodoo/odoo#78748
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
PURPOSE
After this commit when creating a partner the language will default
to the crm lead value.
LINKS
Task-2580065
Pr: odoo/odoo#76812
Related: odoo/enterprise#20689
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
As this is a many2one, it should end with an ``_id`` suffix. Otherwise we
may think this is a char field, which was probably the case at one point.
Task-2671709
Part-of: odoo/odoo#78648
Purpose
=======
Give the user a more organized view of the digest KPIs in the backend and
improve global wording of digest sections and KPIs.
Specifications
==============
Reorganize order of KPIs in digest view. Fix some typos, move buttons in
list and form views.
Task-2582128
closesodoo/odoo#77507
Related: odoo/enterprise#21340
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improve the pipeline analysis search for a better
usability. The changes includes:
- Rename 'My Opportunities' filter to 'My Pipeline'
- Move 'Opportunity' filter above 'Lead', rename it to
'Opportunities', and display only if leads are activated
- Rename 'Lead' filter to 'Leads', and display only if leads are
activated
- Remove the string from filter 'Creation Date', and use the
default field name (which is 'Created On').
Also updated some filter names to have a global convention
and avoid name clashing, updated filter names are listed below.
- `opportunity` to `filter_opportunity`
- `lead` to `filter_lead`
As we need to display same filters and groupby in both community and
enterprise pipeline report search view, we have removed the search
view `crm_opportunity_view_search` from enterprise so that we can use
the community view there and both becomes the same view.
So in this commit we have also added some filters and groupby to
community version(`crm.crm_opportunity_report_view_search`) which was
existed in enterprise search view (`crm_enterprise.crm_opportunity_view_search`)
so that we dont miss any filters used in enterprise.
The filter and groupby added are listed below:
Filter:
- inactive
Groupby:
- compaign
- medium
- source
Apart from this, we have added groups `crm.group_use_lead` to the
groupby filter `conversion_date`.
Enterprise: odoo/enterprise/pull/18797
Upgrade: odoo/upgrade/pull/2937
TaskID-2343223
closesodoo/odoo#71796
Related: odoo/enterprise#18797
Related: odoo/upgrade#2937
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
This commit remove the "groups" attribute on the recurring revenue
fields. Instead we hide them directly in the views. This group was used
only to turn on / off the feature, not for security reason. So it's
fine to move the group in the views.
It will help for the lead merge so we will not be forced to use SUDO
during the merge.
Task-2447721
PR odoo/odoo#75742
