Currently using a customer with a company set on a lead without company
crashes, as it keep a void company on the lead. This is not compatible
with the company set on the partner itself.
OPW-2805181
Task-2888330
X-original-commit: 51be6cab5c4437ef56de5d1b25c0ba8486d25291
Part-of: odoo/odoo#94493
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
This commit revamps the grouped-kanban implementation for smaller
screens (aka. mobile) by making it more "responsive" and avoiding
mobile-specific variation. It makes the implementation simpler and
closer to what the user expects from the desktop version.
In a nutshell:
- columns are displayed individually ; an horizontal scroll allows to
switch to the other ones, "snapping" to the column (aka. carroussel-like).
- each column takes 90% of the viewport's width to give a hint of its
siblings.
- each column scrolls (vertically) individually to avoid being lost when
switching from one column to another.
- folded columns are "virtually unfolded": they takes the same space as
the other ones, but content is loaded on-demand.
- some configuration modals are fullscreen for ease of use.
Part of the SCSS revamp task-2704984
task-2883057
Part-of: odoo/odoo#94134
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently, when creating a new stage, even if there are sales team(s)
available, the `team_count` always displays zero, because it is a
computed field but is not dependent on any other field.
This commit improves the behavior by small hack, which makes the
compute method dependent on `team_id` field so that it can be
triggered while creating a record.
taskID-2819559
closesodoo/odoo#88738
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit improves the helper string for 'My Pipleline' a bit in case
the logged in user has not joined any sales team yet. Also, if user is
having enough rights to access 'Configuration >Sales Team' menu, the
helper string will now contain a link to this menu as well.
task-2846401
closesodoo/odoo#91304
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Update to latest runbot state, at least for tests known to be
deterministic.
Notably mail tests are lower than before, probably due to odoo/odoo#73271closesodoo/odoo#93470
X-original-commit: 6118ecba8d807ac5ebc69ae4877e1f202b0daeb1
Related: odoo/enterprise#28308
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
install crm and change a lead between two won
stages
Expected behavior:
The date_closed does not change
Current behavior:
The date_closed changes
opw-2839298
closesodoo/odoo#92534
X-original-commit: 0c55c0d31021abe966c453c4827d5873a7af485c
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.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
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
How to reproduce the bug ?
- install the CRM and sales modules
- remove the user from the all the sales security group
- go back to the dashboard and click on settings
What is the bug ?
The res.config.settings model of the CRM module has a field referencing
the crm.lead.scoring.frequency model. This model can only be accessed by
the members of the sale security groups. If an admin is not part of the
sales group, he will get an error when he wants to access the settings
while he will not see the sales or the crm settings tab.
opw-2755177
closesodoo/odoo#91405
X-original-commit: 5f2d6dfac018339283971eadc2a3bbadc857ae35
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@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>
Earlier in Odoo, JS views were defined by defining 4 elements: View,
Controller, Model, Renderer. This was complex in some way, because we
wanted to inherit behaviour as well, so it was necessary to think along
multiple dimensions to understand how the code was running.
Then, with Owl, we rewrote some views, and simplified them: views were
now just a Component. Most of the common behaviour now came from the
generic View component that instantiated the concrete view with the
proper informations. In practice, views were still split in views
(which was the equivalent of the Controller of earlier views), Model and
Renderer
Now, this commit reintroduce the Controller, and change the way views
are defined: by an object with multiple metadata, and an (optional)
props function to compute the actual props used by the view.
As a result, views are now much easier to extend/modify.
closesodoo/odoo#89889
Related: odoo/enterprise#26728
Signed-off-by: Géry Debongnie <ged@odoo.com>
Refactor the `load_views` API so it no longer sends multiple times the same
fields description.
e.g.
When `load_views` is called to get the kanban, tree and form views,
the list of fields of the model was sent 4 times:
- Once for each view, with only the fields used in the view,
in `['fields_views']['kanban']['fields']` for instance
- Once globally, with all the fields of the model, in `['fields']`
The goal of this revision is to change that so it sends the list of all fields
only once.
In addition, if a view contains x2many fields,
the fields description of the comodel is also sent.
It was sent in the `views` key of the view fields dict.
e.g.
When calling `load_views` of `res.partner` to get the kanban,
tree and form views,
the `res.partner` fields description was actually sent 6 times:
- Once for each view
- Once globally
- Once for each view of the many2many field `child_ids` of the form view, in
- `['fields_views']['form']['fields']['child_ids']['views']['kanban']['fields']`
- `['fields_views']['form']['fields']['child_ids']['views']['form']['fields']`
The change suggested in this revision is to:
- Remove the fields description for each view in `['fields_views']`.
As it no longer contains the fields,
the key becomes `['views']` instead of `['fields_views']`.
- Replace the dict key `['fields']` by `['models']`,
which is a dict with as key the model name and as values
the model fields description. It contains the fields description
for all models implied in the view:
the model of the main view and the model of all one2many and many2many fields.
With this change, the fields description will only be sent once by model
implied in the view.
In addition, the web client was getting the information about the fields
sometimes in the global fields description list (e.g. `['fields']`),
sometimes in the fields description list of the view type
(e.g. `['fields_views']['form']['fields']`),
making it a pain to try to make changes / performance gain
in these field description dictionaries, because you never knew in which dict
the web client was getting its info.
Now, as there is only one place to get the fields description from,
it's clearer and cleaner.
- one2many and many2many fields views are passed directly in the main view
architecture rather than being put in the `views` key
of the field description.
This is actually easier to treat by the web client,
and this will allow in a future work to cache an entire view in one block
of text rather than having to combine multiple cached blocks of text
to return one view.
- one2many and many2many fields which do not have directly embedded views
have their views directly injected in the architecture,
so the web client doesn't have to do RPC calls to `load_views`
for each one2many and many2many fields not having embedded views.
For instance, this allow to reduce the number of RPC calls to `load_views`
from 8 to 1 when loading the form of `product.product`.
Currently, this behavior is limited to 1 level deep but we consider making it
go all the way down in future works. We did not do it for the moment because
in certain cases it rises the processing time and the size (bytes) too much.
e.g. the sale.order view can be 5 levels deep,
meaning you can reach 4 dialogs on top the main view.
```
sale.order form > order_line > sale.order.line form > invoice_lines >
account.move.line form > asset_ids > account.asset form >
depreciation_move_ids > account.move form.
```
This will also benefit in future works to cache an entire view in one block
of text rather to having to combine multiple cached block of text
to get one view.
- `fields_view_get` becomes `get_view`.
As it no longer returns the fields description,
keeping the `fields` in the name `fields_view_get` no longer makes sense.
Hence removing `fields` from the method name, it becomes `view_get`.
As it gets renamed anyway, we take the opportunity to rename it `get_view`,
which is more in line with the general getter/setter guidelines
in the model object world.
- `_fields_view_get` becomes `_get_view`. For the same reasons than above.
- `load_views` becomes `get_views`.
This is not mandatory, there is no technical reason to rename `load_views` as
it practically sends the same info as before,
the view architectures and their fields description. Just in another way.
We just take the opportunity of this pull request to suggest a cleaner API:
`_get_view`, `get_view` and `get_views`.
- Arguments `toolbar=False, submenu=False` fo the methods
`_fields_view_get` and `fields_view_get` are converted to a kwargs `**options`
in `_get_view` and `get_view`.
The rationale is that submenu was already no longer used (deprecated)
and the mobile options is introduced.
The mobile options is necessary to tell the server to send the mobile views
for x2many fields (kanban instead of tree).
Instead of adding a new argument each time we add a new option to
`fields_view_get`, it seems wiser to have a kwargs `**options` to avoid
to re-write all overrides each time a new option is introduced.
- `_fields_view_get` returned a dict containing the arch in text and some of the
view information. Now, `get_view` returns a tuple with the view architecture
as an `etree` node, and the view as a browse record. The rationale is that all
overrides of `_fields_view_get` were about modifying the arch only
(e.g. changing the address format/re-organizing the address related field
nodes of the partner according to the company country).
To do so, all these overrides were doing `etree.fromstring` to parse the arch
which was sent in text to convert it to an `etree`,
then operations were done on the `etree`,
and then `etree.tostring` was called to convert back the arch to string.
With this change of signature to send the arch as an `etree`,
all these back and forth `etree.fromstring` -> `etree.tostring` are avoided,
allowing some performance gain and less code in the end.
- A cleanup of the keys returned in the dict of `fields_view_get`
has been performed in `get_view`:
- `fields` is removed, as explained above,
- `view_id` is renamed `id`,
- `name` is removed, it was unused by the web client,
- `type` is removed, it was unused by the web client,
- `field_parent` is removed, it was unused by the web client,
- `base_model` is removed, it was unused by the web client.
- `filters` is moved from the global dict returned by `load_views`
(now `get_views`) to the dict returned by `fields_view_get` (now `get_view`)
as it applies only to the `search` view type.
- Retro-compatible methods for the 3 methods
`fields_view_get`, `_fields_view_get` and `load_views` are provided,
with deprecation warnings in them.
- The web client could cache the model fields description
(as it already caches the views),
so it doesn't need to fetch them again if it asks for another view of a model
for which he already has the fields description.
If we do so, `get_views` could return only the list of models used by
the views, without the fields description as of now,
and the web client would then call `fields_get` independently only for
the models for which it doesn't have yet the fields description.
This would avoid the server to return the fields description
and to call `fields_get`, which is costly, for each `get_views`,
therefore gaining performances.
- Inject the views of the one2many and many2many fields all the way down,
unlimited depth level, as explained above.
- Cache with `ormcache` the architecture of back-end views.
This is already done for qweb views, it's not done for back-end views.
Therefore the postprocessing of the views is performed for each `get_views`,
which is costly, while the view architecture doesn't change for users
belonging to the same groups, according to the groups implied by the view.
This pull request is co-authored by
Aaron Bohy (aab) for the web client part and
Denis Ledoux (dle) for the server part.
Part-of: odoo/odoo#87522
Only the group_salesman can see the opportunities statbuttons
Fix a few not-smart mass_mailing tests:
- running the mass mailing queue processes the messages as the user
running the queue, and will try to send the demo messages, depending
on demo data (when re-running the tests) the test user may not have
the accesses required; sending just the one test email avoids that
issue
- the leads kpi assumes the user has access to leads, that ain't
necessarily the case
For the second issue, when sending statistics if the mailing has a
user `_prepare_statistics_email_values` should be called with that
user as "current" (cf `_action_send_statistics`), so we can just work
off of the current env, though it might be a good idea to eventually
check that.
closesodoo/odoo#89774
X-original-commit: 39af865800c6752b60171f16d6056ceb3c5a1636
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
``CRM`` application calls ``phone_get_sanitized_number`` on partner model to
synchronize lead values to its partner values. This method is defined in
``mail.thread.phone`` mixin. ``Partner`` model inherit from this mixin in
``SMS`` application which is auto install after mail and IAP. If this app
is removed, code is not reachable anymore and lead synchronize fails.
How to reproduce
* install CRM and its automatically installed dependencies;
* uninstall IAP;
* run lead unit tests -> synchronize crashes due to missing method as partner
does not inherit from the mixin anymore;
In this commit we define the missing methods on Partner model directly into
phone_validation. In SMS the inherit order is fixed so that the mixin method
takes over the manually defined one.
Fixes#79460.
X-original-commit: eefac25da8d8a01e5f7da8fab35810da402c0bd9
Part-of: odoo/odoo#88970
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
It looks like in enterprise, the value of has_group is already in cache
This will lead to an additional query when checking mail.message
creation access rights in community.
This commit warmup the user _has_group ormcache to avoid an
inconsistency between community and enterprise
Stack of the additional query:
```
sql('SELECT 1 FROM res_groups_users_rel WHERE uid=%s AND gid IN\n ... (SELECT res_id FROM ir_model_data WHERE module=%s AND name=%s)') (SELECT 1 FROM res_groups_users_rel WHERE uid=29 AND gid IN (SELECT res_id FROM ir_model_data WHERE module='base' AND name='group_user'))
execute (odoo/addons/base/models/res_users.py (self._cr.execute("""SELECT 1 FROM res_groups_users_rel WHERE uid=%s AND gid IN):847)
_has_group (odoo/tools/cache.py (value = d[key] = self.method(*args, **kwargs)):90)
lookup (called at <decorator-gen-111> ():2)
_has_group (odoo/addons/base/models/res_users.py (return self.with_user(uid)._has_group(group_ext_id)):832)
has_group (addons/mail/models/mail_message.py (if not self.env['res.users'].has_group('base.group_user'):):380)
check_access_rule (odoo/models.py (records.check_access_rule('create')):4321)
_create (odoo/models.py (records = self._create(data_list)):4087)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-16> ():2)
create (odoo/addons/base/models/ir_fields.py (recs = super().create(vals_list)):613)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-68> ():2)
create (addons/mail/models/mail_message.py (messages = super(Message, self).create(values_list)):599)
create (odoo/api.py (return create(self, arg)):410)
_model_create_multi (called at <decorator-gen-193> ():2)
create (addons/mail/models/mail_thread.py (return self.env['mail.message'].create(create_values_list)):2132)
_message_create (addons/mail/models/mail_thread.py (new_message = self._message_create(msg_values)):1874)
message_post (addons/rating/models/mail_thread.py (message = super(MailThread, self).message_post(**kwargs)):14)
message_post (addons/mail/wizard/mail_compose_message.py (ActiveModel.browse(res_id).message_post(**post_params)):321)
_action_send_mail (addons/mail/models/mail_thread.py (return composer._action_send_mail(auto_commit=auto_commit)):1964)
message_post_with_template (addons/mail/models/mail_thread.py (return record.message_post_with_template(False, **kwargs)):1929)
_message_compose_with_view (addons/mail/models/mail_thread.py (self._message_compose_with_view(views_or_xmlid, **kwargs)):1933)
message_post_with_view (addons/crm/models/crm_lead.py (opportunities_head.message_post_with_view():1336)
_merge_opportunity (addons/crm/models/crm_team.py (merged = lead_duplicates._merge_opportunity(user_id=False, team_id=False, auto_unlink=False, max_length=0)):578)
_allocate_leads_deduplicate (addons/crm/models/crm_team.py (assign_res = team._allocate_leads_deduplicate(candidate_lead, duplicates_cache=duplicates_lead_cache)):507)
_allocate_leads (addons/crm/models/crm_team.py (teams_data = self._allocate_leads(work_days=work_days)):304)
_action_assign_leads
test_assign_perf_duplicates (odoo/tools/misc.py (return func(*args, **kwargs)):792)
```
task-2796579
Part-of: odoo/odoo#85525
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
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Instead of displaying the float duration in the log, we display it
with this format:
1.5 => 1 hour 30 minutes
0.5 => 30 minutes
task-2665863
closesodoo/odoo#87057
Related: odoo/enterprise#21799
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The test `test_assign_count` may fail randomly leading to the error:
```
self.assertEqual(self.sales_team_1_m3.lead_month_count, 14)
AssertionError: 12 != 14
```
Since BUNDLE_HOURS_DELAY is 0 (during tests), the domain becomes
`[('create_date', '<', fields.Datetime.now()]`
Depending of the time when the transaction starts, and the tests is
executed, the domain could match more or less records when executed one
second earlier or later. This is especially True for single module build
where there is less logic and the execution is faster. The domain may be
tested earlier and match less records.
This error can be reproduced deterministically by setting
`BUNDLE_HOURS_DELAY = 1/3600`
A fix could be to ignore ignore the create_date domain if the
BUNDLE_HOURS_DELAY is 0, we want to match all records in theory
(except if some of them are created in the future...)
The chosen solution is to use cr.now and use a <= instead.
Some assertions where also added to the test in order to identify why
the count was different and give a more precise message when it fails.
```
AssertionError: Lists differ: [] != ['TestLeadInitial_0000', 'TestLeadInitial_[97 chars]006']
Second list contains 6 additional elements.
First extra element 0:
'TestLeadInitial_0000'
- []
+ ['TestLeadInitial_0000',
+ 'TestLeadInitial_0001',
+ 'TestLeadInitial_0002',
+ 'TestLeadInitial_0004',
+ 'TestLeadInitial_0005',
+ 'TestLeadInitial_0006']
```
task-2796579
closesodoo/odoo#87107
X-original-commit: 4a5b68f05c57ba36560d43733dfd04b67c3297a8
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.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
Expected Behaviour
When creating a contact from a lead with an unactive language, Odoo should
replace this language with the parent's language or the DB language.
Observed Behaviour
Since saas-15.1, when you create a contact from a lead email adress,
the contact is created with the lead's language, even if it's not active,
which give an error.
Reproducibility
This bug can be reproduced following these steps:
1. Set an uninstalled language on a lead (two choices):
a. Select an uninstalled language on a lead (this is what happens with
the trial creation, and how to reproduce it via the interface)
- install 8 languages in order to activate the "Search More..." link in
the Language select field of a lead
- on a lead which doesn't have a Customer yet, in the Language, "Search
More...", filter with Active = False, and select an uninstalled language
b. Install a language, select it on a lead with no Customer, and uninstall
the language
2. On the lead, in its chatter, open the Send Message and check the checkbox
next to its email => it should open a popup
3. Validate the popup => there is an exception in saas-15.X, and not in 15.0.
Related Issues/PR
- opw-2745841
closesodoo/odoo#85992
X-original-commit: c9b6ec91a87a4ad007287d978adc34332a97f8da
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Still having sometimes a test failing due to extra queries...
closesodoo/odoo#85929
X-original-commit: 34eebe66f12bf43dbf7c16800e177907fe39f2ba
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*crm, project
With owl2, the `el` of components is no longer available. It still
works in Odoo on LegacyComponent, which has been introduced to ease
the switch from owl1 to owl2, and we're now incrementally removing
it.
With this commit, the action scrolling helpers no longer rely on
component.el, meaning that views using them (through the hook
`useSetupAction`) no longer need to extend LegacyComponent.
More specifically, we move the action scrolling helpers from core/
to webclient/actions, as those helpers make no sense outside the
context of actions (and thus are unnecessary in the frontend).
Tests have been adapted as well.
closesodoo/odoo#85631
Related: odoo/enterprise#24902
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
This commit orders the records coming from the mock server the same
way they are ordered by the ORM, while also allowing it to support
multiple levels of orderby.
This has been done to increase consistency in the test suite and provide
a more accurate representation of how records would be returned by the
actual server.
Some tests performed their assertions based on this previous
undeterministic system and have been adapted, either by altering
the base setup or the assertions themselves.
closesodoo/odoo#84718
Related: odoo/enterprise#24509
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if we try to merge crm leads and few of the
details are not available, traceback was thrown. For ex-
- When lead does not have a company or the company does not have
currency set
- When the visitor name is not set
This commit fixes both of the tracebacks and thus allows users
to merge the leads in these cases.
taskID-2745017
closesodoo/odoo#84656
X-original-commit: eda3f43dde8122aa5f572f57bf2c3c0d94abe1f2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
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>
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Purpose
=======
When we group the record based on a boolean fields, we want to show
"Yes/No" instead of "True/False".
This has been done for the list view, the pivot view and the kanban
view.
Task-2648390
Part-of: odoo/odoo#79911
Laurent Desausoi