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>
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>
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>
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>
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
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
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>
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>
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>
- If we only install sales_team, on the footer of sale team kanban view
there's empty grey border which looks ugly. Also, if the data are
not available, the empty graphs don't look so beautifull.
This commit improves the kanban view to avoid this empty grey border
when there's no content within it, and in case of lack of the data,
we now display sample data in graph with grey color. Note that the
actual data now has colors, green for the future / present data range
and pink for the past ones.
- When opening the configuration menu of team kanban from CRM, we observe
three columns: View, New and Reporting. However, those columns are not
consistent. For example, when leads are activated, we don't see 'Leads'
action under 'New' column. Also the order for the actions are not
consistent for 'View' and 'Reporting' columns.
This commit re-organizes the sequence of the actions for these columns
and thus makes them consistent. Note that we want to always show the
'Activites' at the last, which is being added from crm with 'Leads' and
'Opportunities' actions. So an empty seperator is introduced to keep
them seperate, and push the sales related actions on the top of
'Activities'.
- Right now, the alias on sales team's kanban view is being shown
with `<small>` tag, but it is hard to read. Apart from that, in
the list view, only the alias name is displayed even if the alias
domain is configured.
This commit makes the alias more easy to read by displaying it
with `<span>` tag on the kanban view, and by showing the full
alias along with the domain on list view. Note that on the kanban view,
alias will now be displayed always, which previously was displayed only
when 'leads' were enabled.
- This commit also changes of the action 'crm_activity_report_action' from
'Pipeline Activities' to simply 'Activities' to avoid confusion.
- Apart from that, this commit also adds currency symbol in the form
view and kanban view (while configuring the target), with the suffix
' / month' after the input. Adds the alias name in the
team list view, and it adds 'many2one_avatar_user' widget on user_id
field for both list and form view.
TaskID-2582208
Part-of: odoo/odoo#73530
PURPOSE
Make crm.team deletion effect explicit on main models (excluding wizards
or reports). Purpose is to ensure deleting a crm team has known side
effets.
SPECIFICATIONS
M2O on crm.team set to CASCADE
* crm.lead.scoring.frequency: as we remove the team no need to keep the
PLS data -> change to "cascade";
* crm.team.member: when removing a team, remove its members as it prevents
from unlinking the team;
M2O on crm.team set to SET NULL
* account.move: void team_id field but track it to keep history;
* crm.lead: void team_id field as it will be taken back into assign
process (either manual or automatic), and will therefore be managed
by other sales persons. In case of archived / lost leads setting to
void has no real issue;
* crm.stage: void team_id and set stage as shared to avoid loosing stage
information for existing leads in that stage;
* res.partner: void team_id taking care of this customer as this field
is mainly informative anyway;
* crm.iap.lead.mining.request: void team_id as it only impacts generated
leads. Those will be created with a void team which is ok;
* crm.reveal.rule: void team_id as it only impacts generated leads. Those
will be created with a void team which is ok;
* event.lead.rule: void lead_sales_team_id as this impact generated leads.
Those will be created with a void team which is ok;
* pos.config and pos.oser: void crm_team_id field. It is optional as it is
not a core field of this model. Pos configurations and orders are still
valid without team assigned on it;
* sale.order: void team_id field but track it to keep history;
* website: void salesteam_id field;
Prevent unlink when having more than 5 SO not canceled. If more than 5 active
SOs in the team, we consider this team to be actively used. 5 is some random
guess based on "user testing", aka more than testing CRM feature and less
than use it in real life use cases.
LINKS
Task ID-2507750
COM PR odoo/odoo#70645
ENT PR odoo/enterprise#18266
GLOBAl PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Compute default team id for sales related documents. Note that this method is
not called by default_get as it takes some additional parameters and is meant
to be called by other default methods. Heuristic (when multiple match: take
first sequence ordered)
1- any of my teams (member OR responsible) matching domain
2- any of my teams (member OR responsible)
3- default from context
4- any team matching my company and domain
5- any team matching my company
Note: ResPartner.team_id field is explicitly not taken into account. We think
this field causes a lot of noises compared to its added value. Think notably:
team not in responsible teams, team company not matching responsible or lead
company, asked domain not matching, ...
We also improve various places where sale team is computed on sales documents.
Purpose is to try to use same heuristic as much as possible in various
team_id fields.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: COMPANY-BASED DOMAINS
Improve support of multi company. Sales team can either be linked to a given
company, either be cross companies (company_id = False). Currently it is easy
to have issues while trying to add users from a companyA to a team belonging
to companyB.
When using mono membership mode
* members are res.users records;
* a domain is added on users to belong either to the team company, either
to all available teams if team has no company;
When using multi membership mode
* members are crm.team.member records;
* a domain is added on user_id field of membership records so that they
belong either to the team company, either to all available teams if team
has no company;
Those domains are implemented using a computed field it is not directly
translatable to a domain. Domain is added directly on field at model level
and include the "avoid shared users" domain leaf.
SPECIFCIATIONS: CHECK_COMPANY
``check_company`` attribute is set on team member allowing to automatically
detect badly configured memberships. Check company is activated on user_id
and team_id fields of crm.team.member model to ensure they match.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#9966
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS
Purpose of this commit is to allow to use either mono salesteam mode, either
multi salesteams mode. Basic CRM use mono membership: a salesperson belongs
to a single sales team. It is however possible to choose to work using multiple
memberships. This is configured through a configuration parameter available in
CRM configuration settings.
Mono salesteam behavior
* a given user can be member of a single sales team at a time;
* when moving an user from team to team, its existing memberships are
archived to keep history of what has been done within this team;
* display an alert when creating a new team member that would archive
existing memberships;
* displayed members on team form view are directly res.users records to
avoid displaying unnecessary layer when using a simple CRM;
Multi salesteam behavior
* a given user can be member of several sales team at a time;
* unicity contraint (user_id, crm_team_id) is still enforced;
* displayed members on team form view are crm.team.member records as
advanced configuration can be done directly at that level;
In all cases when adding a new member check for archived membership before
creating it. If an archived version of the member exists it is unlinked in
order to avoid breaking the unicity constraint.
Archived memberships can be managed in its dedicated menu for advanced sales
team use.
SPECIFICATIONS: SETTINGS VIEW
Move Multi Teams checkbox below Recurring Revenues / Leads checkboxes. On its
right alias configuration should appear if Leads is checked.
PLS take third configuration line. On its right future commits will gradually
add automatic assignment configuration.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICATIONS: MODEL CLEANING
In this commit we improve team member model to make it more usable and
aligned with current Odoo views and usability.
This commit contains notably
* add some related fields on the user: phone, mobile, company, email;
* rename "team_user_domain" to "assignment_domain";
* rename "maximum_user_leads" to "assignment_max";
* improve member views globally;
We also introduce dynamic domain computation for users and teams when seeing
team members. This allows to limit selection of users or teams depending
on already existing configuration. Purpose is to avoid having people trying
to create wrong configuration (duplicates, ...) and receiving error messages.
Also
* clean some data and demo about teams and members;
* fix some views glitches;
* improve views: add some fields in search views, improve wording of
fields or actions, ... globally improve usability and US as well as
feedback given to users;
* group sales team members by team by default as it help getting an
overview of team members distribution;
* update tests to create team members instead of writing directly on m2m
towards users;
SPECIFICATIONS: SALE_TEAM_ID FIELD ON RES.USERS
In this commit we also rewrite sale_team_id field of res.users. Previously in
crm it was simply a many2one field linking to a crm.team. It was used to compute
team membership as a standard many2one / one2many relationship. In enterprise
module ``website_crm_score`` this field was set as a related on first user
teams. Indeed scoring changed relationship between users and teams to a
many2many.
This field is now directly a computed many2one field that links to the
"main" team of the user even in multi memberships mode. As memberships can
now be de-activated we changed this field to a computed stored field. It is
based on oldest active membership of user. That way default team of documents
will be the user's oldest team considered as its "main team".
SPECIFICATIONS: LEAD_ALL_ASSIGNED_MONTH_COUNT
Improve crm_team ``lead_all_assigned_month_count`` field computation. It is
now simply the sum of assigned leads of team members. Differences may
happen if a lead in teamA is assigned to an user working in teamB. This should
not happen if team / user is correctly set at lead level which is generally
the case. However if that happens, old field counted it. New field will not
count it as it is not directly linked to a team's member.
SPECIFICATIONS: DEMO DATA
Make crm.lead demo data coherent with user_id / team_id . As demo data should
be using a mono-membership behavior for users and teams, we have to ensure
user_id and team_id effectively matches. It allows to have coherent reporting
and assignment demo flows.
Also avoid having Odoobot responsible of leads. Instead of undefined user_id
and team_id leading to Odoobot being responsible of some leads, force it
to be False. Those demo data allow to test automatic assignment of lead
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996
GLOBAL PURPOSE
Ability to have salesmen belonging to several sales team is a core requirement
of CRM. It is therefore moved from website_crm_score to crm along with cleaning
and behavior improvement. Automatic lead assignment is also moved and cleaned.
SPECIFICIATIONS
Move sales team membership model from website_crm_score (enterprise) directly
into sales_team. It allows to have the base requirements to correctly handle
mono and multi sales team for salesperson.
Membership is modeled using a decorated many2many relationship. Members of
a sales team are res.users. Subscriptions are crm.team.member linking a team
and an user. It is a rename of team.user model coming from website_crm_score
as well as some other relational fields renaming.
Part of old team.user model is moved directly to sales team, part of it to
crm module (notably assignment limits). Its support will be improved in the
upcoming commits. Assignment related fields will be cleaned and used when
moving assignment directly into CRM.
LINKS
Task ID-2086889 (main task)
Task ID-2357969 (scoring migration task)
Community PR odoo/odoo#48422
Enterprise PR odoo/enterprise#499
Upgrade PR odoo/upgrade#996996
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
This commit fixes all issues detected by the new pylint
gettext-variable test.
It converts some calls to the new syntax
_("Foo %s", bar)
to progressively migrate the code to the new syntax.
A few calls were not technically incorrect but still detected by the
linter.
_("Foo" +
"Bar")
has been converted to
_("Foo"
"Bar")
as it has the same effect and make sure the argument is of type
asteroid.Const instead of BinOp).
closesodoo/odoo#53683
Related: odoo/enterprise#11467
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
The color picker help the user to choose a color instead of picking it
by id.
The title and arial-label "no-color" default value are removed from the
picker_preview because they are not accurate. Instead name of currently set
color is used.
Task ID 2128166
closesodoo/odoo#47474
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
For a tag to be displayed on a kanban card, it needs to have a color set.
We won't be changing that behaviour, since it would mean having
two options > the color, and whether or not to show it in the kanban
The purpose of this task is to set a color on new tags to make the user
save a bit more time, set a color for him as he might not find the feature,
and make sure the tag will be on the kanban cards.
Specification
=============
For each of the following models, at creation, set a random integer between
1 and 11 in field 'color'
Models:
res.partner.category
crm.tag
project.tags
hr.applicant.category
helpdesk.tag
hr.employee.category
event.track.tag
mrp.eco.tag
repair.tags
closesodoo/odoo#49967
Taskid: 2234527
Related: odoo/enterprise#10112
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Prepare enhancements of sales team membership.
SPECIFICATIONS
Linting containing
* reorder fields according to their use;
* order methods according to guidelines (compute, CRUD, actions, tools);
* fix some docstrings and typos;
* remove unused imports and dead code;
* rename files according to guidelines;
* move views in their own file for mail.activity and assets;
* correctly name data and demo files;
* rename some inner methods to ease understanding;
LINKS
Task ID 2086889 (sales team enhancements)
Task ID 2234698 (preparation lint)
Community PR odoo/odoo#49520
As the crm.lead.tags model shall be used in CRM and/or Sales apps,
it has been moved to the sales_team module, which is a depedency
of the CRM and Sales apps.
As these tags becomes more generic than just "lead tags", the model
has been renamed from crm.lead.tags to crm.tags.
Tags on sale orders were already present but not visible. They are
now visible in the "Other Info" section, and optionally in sale order
tree views.
When a quotation is created from an opportunity (CRM app), existing tags
are populated from the opportunity to the sale order (Sales app).
Views and demo data of several modules have been updated accordingly.
Task ID 2191276
Purpose
=======
The main definition of 'assignation' is the following:
"an appointment to meet someone in secret, typically one made by lovers"
The correct word we should be using is 'assignment':
"the allocation of someone or something as belonging to a particular group or category"
So in this commit change every iteration of the word
'assignation' to 'assignment', across all modules.
closes odoo/odoo#45041
Taskid: 1966215
Closes: #45041
Related: odoo/enterprise#8375
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Each search on member_ids will trigger a ref call (one exists query each
time), whereas we could just directly use the appropriate share field on
res_users.
This commit changes the method _get_default_team_id so that it removes
the xmlid reference to the default team. Instead, we will now use
the team sequence (with default team's sequence being set as 1)
and falling back to the next team with the highest sequence if the
default team got deleted.
Therefore, teams will now be ordered by sequence instead of name,
allowing the users to reorder their teams as they see fit
This commit also removes useless sudo when searching teams
Task: #1962182
PR: #32372
wip
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
reply_to field is not used (and not available) anywhere. Its use is completely replaced by
aliases you can set on teams. Let us therefore remove this field.
Related to task 1985539
Closes#33497
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Reason:
*Sales team configuration is too complex with fields you
don't understand and that bring no added value
*Remove the team type, every team should be able to handle
a POS or a website for example
Contains:
*Removal of the team_type, use_quotations, use_leads fields
*Removal of the graph configuration fields
*Adapting the filters that were based on the team_type
*Clear distinction between the team dashboard behavior in crm
from the one in sales
*Cleansing of now dead code due to the removal of the previously
mentionned fields
Task: #1830105
Enterprise PR: #3006Closes: #28063
- Create 2 companies C1 and C2
- Assign User U1 in C1
- Assign the default Sales Team (`sales_team.team_sales_department`) to
C2
- Create an invoice with U1
An `AccessError` is raised because the user is not allowed to access the
default Sales Team.
We fall back on `sales_team.team_sales_department` only if the user has
read access.
opw-1876966
niyasraphy