The parent commit allows to select a specific interval for any
date or datetime field in the groupby menu. This makes some filter
akward, for instance "Order Month".
Accordingly, we have rewritten the string and help attributes in
search views archs and removed groupbys related to the same field
(that would have become redundant).
Use crm.lead instead of a the crm.opportunity.report object for
reporting. This allows to show more fields (e.g. tags_ids). The only
field not accessible in the report is #activities, but there is a
deicated report dedicated to activities.
Improved the default search. Example: when reporting on leads, you want
leads+opps by creation date (and not only leads) as an opportunity has
been a lead created too.
mail.thread mixing class defines several methods used in notification process
that are not specific to mail.thread enabled models. It means some models
could override it while some other models do not even have a direct access
to that method.
When calling those methods we have to manually check for method being
available on a record or call a default implementation from mail.thread
even if the model does not inherit from the mixin.
In this commit we propose to hide this check in generic wrappers located
in mail.thread class. It checks for method existence on record and call
the model-specific implementation or falls back on standard behavior. It
allows to be sure the right method is called.
Functionally behavior should stay globally the same. However when updating
some addons code has been updated. Previous code could lead to records not
having correct alias which should not be the case anymore. This commit is
linked to task ID 47934.
The reified view on the res users will be dropped in the following commit.
The previous commit adds support to define each group as a computed field on the res users.
This commit defines:
- A boolean field for each 'isolated' res.group, i.e. a group in the hidden category.
- A selection field for each 'Application' res.group, i.e. a group in a application category.
Example:
- The group to manage pricelist in sales becomes a boolean field
- The groups project user/manager become a selection field
Activities are quite personal and linked to daily jobs of people using it.
Being notified of all activities is therefore not considered as default
behavior and should be a choice done by users. Subtype linked to logged
activities is now not followed by default anymore. It is still configurable
through subscription widget or parent subscription (project/task for example).
This commit is linked to task ID 1824141.
This commit refactors mail.thread message_subscribe method. It is done for two
purposes. First one is to optimize performance by using the new followers
computation methods introduced recently. Second purpose is to clean the API
of message_subscribe to make it simpler to use.
This commit splits message_subscribe in two main parts :
* _message_subscribe is a private method calling the follower new
subscription methods and updating the record set;
* message_subscribe is a public wrapper on _message_subscribe that adds
access rights checks;
Simplification comes by removing message_subscribe_users that was a
shortcut to message_subscribe. Having a method to subscribe partners and
channels is sufficient as we would like to avoid bloating the public API
of mail.thread. A force parameter is also removed from message_subscribe
as this implementation detail can be induced in the computation.
Various addons using the removed methods are updated in order to use the new
subscription API. They have the same functional behavior.
This commit has a great impact when subscribing several followers. In a more
general way all code using message_post is also optimized as posting a message
generally implies subscribing followers. It also improves activity use as
posting a message and subscribing new followers are common process in
activities.
Currently crm and project parse incoming email body following an old
syntax to find some "set field - value" lines in the email content. It is
used to update the record linked to the discussion directly from the email.
However this feature is undocumented and not really supported anymore.
Moreover we don't think being able to update records from emails is a
reliable way of working. Moreover those update is limited to
* revenue and probably for leads; this should totally be managed from
the pipeline view by lead / opportunity responsible;
* priority update coming from a "priority" entry in the incoming email;
this code seems strange as priority is probably not standard in email
headers;
* planned hours for project; this should be managed by project user
and managers through dedicated views in Odoo;
Let us remove that old feature and let people use desktop or mobile
interface to update their records.
- Go to CRM > Reports > Pipeline
- Click on one of the Favorites filters (e.g. 'Opportunities Won Per
Team')
A JS error arises.
The filters are not correct. `__count` should be `__count__` and
`expected revenue` should be `expected_revenue`.
opw-1825759
- Create a customer, set an address
- Create an opportunity from the kanban view
The address fields are not filled in in the opportunity.
We add all fields filled in by `_onchange_partner_id_values`
Complement of commit e2bbee6df5
opw-1816438
*crm,project: css selector adapted in tours
This rev. improves the UX of the 'Invite users' and 'Pending
invitations' part of the Settings dashboard.
Task 32804
Closes#19531
Co-authored-by: Aaron Bohy <aab@odoo.com>
The widget statusbar was using an attribute `clickable` on the field widget
to define if the statusbar was clickable.
This attribute is in fact not a field attribute but a widget option so it
has been moved accordingly.
Note that a retro-compatibility adapation is done in the field widget.
Mathieu Duckerts-Antoine