´extends´ generates a lot of css rules.
So in this commit, we remove it by replacing it by the ´h5´ html tag.
closesodoo/odoo#139484
Related: odoo/enterprise#49408
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
This commit aims to simplify the evaluation context used to
evaluate expressions used in views (invisible, required, readonly,
domain and context attributes). For now, the evaluation context is
typically the current record (there's a key for each field in the
view). In addition to that, there're static keys (that may conflict
with field names): uid, allowed_company_ids, current_company_id,
active_id, active_ids and active_model.
The motivation of this commit is at some point to get rid of the
3 active_* keys, because they are misleading and basically useless.
The notion of active_* exists, but it is something else: when you
are in a form view (let's say the form of a partner) and you open
its opportunities (by clicking on the stat button), the list view
of opportunies shows up and in the context, there're 3 keys
active_*, referring to the record from which we came. One can
easily access those information with context.get("active_*"), in
python or in view archs.
However, almost all `active_id` found in archs were actually used
to refer to the id of the current record. Indeed, for now, in the
evaluation context of a record, the value of the `active_id` key is
always the id of the record. So this commit adapts them to
directly use `id` instead. There was no use of active_ids, and
a single use of active_model which was removed (active_model is
the res_model of the view, so it isn't really necessary).
This commit doesn't drop the support of those keys, it deprecates
them. They will be removed for v18. A warning will be displayed if
they are used.
closesodoo/odoo#136665
Related: odoo/enterprise#47917
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, all mail templates were shared, which was cluttering the UI
for everyone.
Now, each user can have their own templates that they can edit and save. Access
is done through the mail composer wizard, where users can only access their own
templates and templates that don't belong to anyone.
Some groups are considered as admins and can access all templates in
Settings/Technical/Email/Email Templates:
- Sales Admin
- Project Admins
- Helpdesk Admins
- Accountants
- Event Admins
- Recruitment Admins
Task-2504439
Part-of: odoo/odoo#126049
When we go to the simple user view, no need to show "Create Employee"
option unless we are inviting a new user. Also, to standardize the
behavior, we remove the context that conditionally used to hide the option.
Moreover, we add smartbutton leading to the related employees' view to the
simple user form view.
task-3334739
closesodoo/odoo#122870
Related: odoo/enterprise#41646
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
before this commit, if user is searching on member_ids
field in crm.team is giving an archived record also from
member_ids table.
* create a partner (Test Partner) and sales team (Test Team)
* set the created sales team for partner
* add and remove a user (A) to this sales team
* search for partners with sales team in which
user (A) is part of.
* result says that partner (Test Partner) matches the
search condition, which is wrong
In [1] we ensure that m2o relations in multipath domains
do not filter on 'active'.
However the context variable that does this will propagate
to all potential subqueries.
In this case this means 'crm_team_member_ids.user_id' on sale teams will be searched without filtering on 'active'
when it is a subquery of searching 'team_id.member_ids'. Even though searching 'crm_team_member_ids.user_id'
on its own would have filtered on 'active'.
The fix is to set the context for 'active_test' on the field directly, as we already have another field with 'active_test=False' if that is ever needed.
[1]: c15c07c405
after this commit, the search will return active records
only.
closesodoo/odoo#128563
X-original-commit: 08d4aeb0449d145a4e96565ff7e68dc856392904
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A considerable number of upgrade requests fail on different python constraints,
because the DBs in question are missing the `crm_team_member_admin_sales`
xmlid, while the data is in conflict with the attempt to restore the default
data (e.g. `base.user_admin` and `team_sales_department` have been assigned to
different companies or simply the data still exists and is still marked as
active).
The removal of the xmlid can only be done by an admin in developer mode and it
is safe to assume that the intent was to no longer have the default data and
that it is of no use to recreate it.
To support this intention and to make these upgrades succeed, set
`forcecreate="0"` on the XML record `crm_team_member_admin_sales`.
opw-3414340
closesodoo/odoo#128020
X-original-commit: 73fa2c03928afb8a3bdc3533d3af0874505ff6b8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Carsten Wolff (cawo) <cawo@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit fixes the ribbons used in `kanban` and `form` views.
The SCSS uses the square root of the parent `div.ribbon` to calculate its
diagonal width and applies that width to the child `span`.
After changing the ribbon's transform-origin, we calculate the ribbon's
position based on CSS variables of the view's top padding,the height of
the ribbon and the shadow's size (to avoid it being cropped by
overflow-hidden).
By changing the values of a few of these variables in the kanban view,
we were able to remove all the specific SCSS related to ribbons in the
modules.
Other changes were applied inside some of the modules to make this
work:
- `event`: padding corrections on the kanban's cards;
- `hr_holidays: replaced `margin:0` in the SCSS with negative margin
utility classes on the element to achieve the same visual result;
- `discuss`: moved the ribbon to the parent element;
- this was also done to `discuss`, `survey` and `helpdesk`;
- `crm_team_view` in `sales_team`: the ribbon's height made it overflow
from the kanban's card. We fixed this by changing the value of one of
the CSS variables in the view's SCSS file;
- the same thing was done in `survey` and `appointment`;
- `website_event_exhibitor` had some SCSS that wasn't being used because
it uses `.o_ribbon` instead of `.ribbon`
task-2818586
Part-of: odoo/odoo#116641
Draw attention to the monthly assigned lead count when
it is exceeding the limit by changing the text color
to orange.
Task-3204763
Part-of: odoo/odoo#115326
*: sale,sales_team
Improve UI of the CRM app:
- Add placeholders and underline m2o fields in the CRM quick create
- In the lead generation form, underline the industries field, add
the avatar widget on the user_id field, add the color attributes on
the tag field, add a placeholder for the states field and set a
longer selection field to avoid the caret from overlapping the content.
- In the opportunity form, align the expected revenue and probability
headers, set a longer width for the expected revenue field,
change the recurring plan placeholder.
- In the contact opportunities page, change the "Open Opportunities"
filter to exclude lost opportunities.
- In the Sales team page, add a groupby on the company_id.
- In the Sales team form, change the assigned lead count to be
a muted text, the pipeline checkbox should be visible only when leads
has been activated, the quotations/pipeline/leads options should be
aligned.
- In the lost lead modal, change the title from "Lost Reason"
to "Lost Lead" and the validate button from "Submit" to
"Mark as lost".
- In the Sales team member form, align the fields on the left and hide
the Create Employee field as it should not be displayed there because
this is not an hr module.
- In the lead analysis tree view, add the lost reason field with optional
hide.
- Align the enrichment company not found message to the left of the chatter.
- Update the crm iap lead role "Search More" list to display human
readable names instead of the technical names.
Task-3204763
Part-of: odoo/odoo#115326
In case you write user_id = False on the sale order,
It will match the first sale team without sale team manager.
It is because False != None.
After this fix, we check if user_id is Falsy instead of None.
closesodoo/odoo#120346
X-original-commit: 8adde86c719b2dc76e21e440c32de1307e5c4da3
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Steps to reproduce:
- Install Sales.
- Go to any quotation and toggle mobile device mode in the browser.
- Go to Other Info > click in Sales Team field.
Issue:
We stop supporting the 'kanban_view_ref' in newer versions of odoo. So
we won't be able to get proper view.
Solution:
Changed the way we ref the kanban view to use context to get the
referenced kanban view.
Related to #39499
opw-3152174
closesodoo/odoo#116031
Related: odoo/enterprise#39499
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit separate the templates, one for the card and another one for
the menu (the ellipsis dropdown).
The new template, called 'kanban-menu', will only contain the dropdown.
Note that, this behaviour is the same as the one used for the kanban
tooltips.
closesodoo/odoo#107589
Task-id: 3096776
Related: odoo/documentation#3284
Related: odoo/enterprise#34962
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Currently, adding members in a sales.team without the multi-company group is
not possible, the selection does not show any users.
This is because the domain field for the users search ("member_company_ids") is
not computed as none of its triggers are present in the view.
To fix this, we add the 'name' field as a fake trigger to force the
computation.
Side-note: the tour was added into the CRM module as we require this module to
have entry menus into crm.team form views.
Task-3088861
closesodoo/odoo#107352
X-original-commit: 11d24d8757a74cdf4af433bdc735460e68ba6cd2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fix the issue where the slide content records,
crm team records and crm team members records were
overlapping on other group.
This was introduced by odoo/odoo#105531
Task-3086887
closesodoo/odoo#107159
X-original-commit: f7a2928afc4bc6f3ce4622f28f7cd9672b8a7b6f
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose: The enforced min size of kanban cards was applied to ghosts as well,
we undo that.
Task-3004227
Part of odoo/odoo#101897
X-original-commit: d0ee5c0e6deab3b73b761c7e0125ac52f7a7dd0a
Part-of: odoo/odoo#103257
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
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>
When we open the 'CRM > Configuration > Team Members' menu, if there are no
members in any of the teams, we see the empty screen(no dummy data, no
action helper), which looks a bit ugly.
This commit improves the behavior by displaying all the (accessible) sales
teams, even if they are empty. So, even if there are no members available,
we will get to see the dummy data and action helper.
Note that in the data, we already have one sales team available, so this
should be okay. But if someone intentionally removes all the teams, it
will still lead to an empty ugly screen. Since this is a rare case, we
haven't considered it for now.
task-2583755
Part-of: odoo/odoo#92616
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 makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Steps to reproduce:
-Install sales and crm
-Apply multiteam option in crm settings
-Create a user with two teams A and B
-Create with this user a lead with team B
-From this lead create a quotation
Current behavior:
The quotation could have team A (the team of the lead is ignored)
Expected behavior:
The quotation always has team B
Problem when creating the quotation the team id is not propagated
in the context to the final function _get_default_team_id and in
this function the default context team is only check if no teams
have been found for the user, so the function always selects the
first team of the user. To solve the issue we propagate the team
id to the default function and we change it so that if the context
default team is in the user teams it is this one that is going to
be selected and no other.
opw-2830913
X-original-commit: 0b6c63f2be90928f5d6806ef489c369a1310be04
Part-of: odoo/odoo#94045
Purpose of this commit is to better support default_team_id in context when
computing default team. Indeed currently default key is ignored if the user
is member or responsible of any team. It is used only when no membership
exists as a fallback.
However when giving a default_team_id in a default-like method we think we
should better try to match this value. When having memberships the final
team is the default one if present in the subset of teams. Instead of
taking the first found one in the teams set (filtered on a domain or not)
we first check for the default team presence, then fallback on the ordering
based on sequence.
Task-2852947
opw-2830913
X-original-commit: fb060c86daf0c1d737abc9228002cdfa280e1d2c
Part-of: odoo/odoo#94045
Current sales team ordering is based on sequence. However several sales teams
with same sequence may exist. This leads to a not deterministic behavior as
we are unsure how database will choose the ordering.
This is fixed with this commit: when having teams with same sequence we take
the newest one first.
Task-2852947
X-original-commit: 34da99f6bec92553febfae7bc9c80ccebb38f70f
Part-of: odoo/odoo#94045
Purpose of this commit is to improve a bit tests about default team computation.
Coverage is improved, notably about default context value usage that is about
to be updated.
Task-2852947
X-original-commit: 8e18a27352d2fd9e68cd2b54e49dfca6fb658eaa
Part-of: odoo/odoo#94045
Since #83550, the sale.report model is not a stored SQL view anymore,
but a query generated depending on the context, to show the amounts in
the currency of the current company.
Therefore, the table sale_report does not exist anymore in database, which led
to a traceback when opening the crm.team view in sale (Sales/Orders/Sales Team).
This commit makes sure that the graph content correctly uses the contextual query
instead of trying to read the sale_report table.
closesodoo/odoo#90602
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Prior to this commit branded UI components were styled exclusively in
raw SCSS using the '$o-brand-odoo' variable.
This leaded to unnecessary code repetitions since, to achieve the same
visual result, each module defined its own classes.
Visual inconsistencies were frequent too since each module defined its
own variations for interactive states (eg :hover).
This commit injects '$o-brand-odoo' into bootstrap's default
'$theme-color' map, allowing the framework to automatically generate
odoo utility/contextual classes.
These classes can be used to handle text, backgrounds, borders and
buttons wherever needed.
Part of the overall v16 SCSS optimization/restyle, task-2704984.
task-2800721
closesodoo/odoo#87448
Related: odoo/enterprise#25700
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The performances tests in TestLeadAssignPerf have a margin for queries
because of some randomness in query counts.
Those margins avoid random failures but will hide small increments,
making the query count fail randomly in future build. This margin also
makes the update of query counts difficult.
This commit tries to identify the source of this randomness and proposes
some fixes.
Sources of randomness
=====================
Comparing different executions, the query can differ on two point:
1. During the flush, while updating the lead
1.1 the written user_id can vary (~1 additional query)
1.2 the written convert_date can changes (~4 additional queries)
1.3 the written date_last_stage_update can change (~1 additional query)
2. during _handle_salesmen_assignment
2.1 write/_message_auto_subscribe can change? (~1 additional query)
the point 1.2 and 1.3 can be easily reproduced, adding sleep,
especially a 0.1 sleep in convert_opportunity
Writing different values for date will lead to multiple execute
when flushing the records:
the orm cannot group records with different values
Proposed fixes
==============
A. Use `cr.now` instead of `fields.datetime.now`
Using the transaction time will avoid randomness linked to the change of
second during the transaction. This will fix 1.2 and 1.3
B. Sorting members
The members comes from a o2m and the order is not deterministic.
During the test with a subset of lead (10 instead of 100),
the two last members ('Martin Sales Manager' and 'Orteil Sales Own')
can come in different orders, leading to different user_id set on lead.
Instead of 4 different users, the lead where sometimes dispatch on
5 different users with this setup. (5 queries in flush() instead of 4)
This is fixed by adding a complete order (adding id) on crm.team.members
This will solve 1.1
C. The leads are also ordered by id if they have the same probability,
since it shouldn't hurt and make the search more deterministic.
2.1 was fixed by B or C or is not fixed, not sure anymore.
task-2796579
Part-of: odoo/odoo#85525
Steps to follow
- Select only one company in the company selector but not the default one
from the current user;
- Go the the CRM app;
- Create a lead;
-> A multi company error appears !
Solution
- The default team is now restricted to the companies in the context
- When computing a lead's company_id when the team has no company, keep only
the ones within the allowed_company_ids;
opw-2713757
closesodoo/odoo#83764
X-original-commit: 58b9b3e839c7725fdcd66376564ce6554a4b82ac
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose of this commit is to add a base module holding tests for the whole
crm ecosystem. It notably holds currently performance tests, allowing to
track future improvements and changes.
Task-2720144 (Crm performance tests)
Also linked to Task-2703285 (Event performance improvements - event_crm)
closesodoo/odoo#81717
Related: odoo/enterprise#23046
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently no chatter is added on team member form views. Indeed this model is
mainly technical and accessed through a dedicated menu in configuration.
However some fields are tracked and being able to see tracking information is
important in day to day dealing of team members. This is why we add chatter
on team members form view.
We also add context key to avoid autofollow when creating team members. As
chatter is mainly present for tracking and information no need to add extra
followers automatically. This causes unnecessary notifications.
Task-2679897
closesodoo/odoo#79356
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Adrien Dieudonne