The purpose of this task is to improve the UI of the 'Apps', by
improving the clarity of the kanban, sequencing the apps and
simplifying the app categories in the searchpanel
So in this commit, Added the new sequences for ir.module.module
and ir.module.category records.
TaskID: 2240257
Related Enterprise: https://github.com/odoo/enterprise/pull/12413Closes: #55907
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
There are inconsistencies in the m2o accounts create & edit behavior.
New off-balance account type was not correctly filtered
This change correct those two issues
Task ID: #2288757closesodoo/odoo#54626
Related: odoo/enterprise#11920
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Currently the address part of the contact widget does not display well as
marker and address are on two separate lines. Indeed a d-flex is missing
along with align-items-baseline in order to render correctly.
Linked to task ID-2314778
PR #55702
X-original-commit 59801738a4c02db4d8dd230d50ec749661db5260
X-original-commit: f19725c6fb0c6df33e7bdb5361dda2bc11359021
With this commit, the timezone (in the user's preferences) is
automatically set to the timezone of its browser the first time
this user logs in.
Task 2207715
closesodoo/odoo#55726
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
A previous commit has paved the way for displaying sample data in the
reporting views. The present commit brings the required changes to have
sample data in pivot views.
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
A previous commit has paved the way for displaying sample data in the
reporting views. The present commit brings the required changes to have
sample data in graph views.
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Enable MTO route at the start of main flow tour since it's used
by it. Also fix a small bug when the form view is open from a
create edit where the route are hidden.
closesodoo/odoo#55790
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit adds the parameter `scales` in the calendar view's template.
This parameter can be used to choose which mode(s) is/are allowed.
This commit also refactors the way we manage calendar scales.
Before scales were defined in model and renderer, now it's defined
in the view and given to model, controller and renderer by params.
Task: 2193921
This commit adds a new year scale to the calendar view.
It comes with a new view in the calendar, this view displays a
4x3 grid which cells are month views.
Task: 2193921
This is a followup of commit bc2bb5e03c2b32d4ee1b0597ea5889c17d2b0e0e
When a module is updated, a constraint application may (temporarily)
fail because the existing data does not respect the constraint, this is
OK and can be fixed through hooks/migration scripts and was handled by
the aforementioned commit.
However when updating multiple modules, it is possible that an
inheriting module will try to re-apply the failed constraint and
succeed, if that is the case, when processing the `post_constraints` an
already-existing constraint will be applied and raise an error.
To fix this, a check is made before trying to apply the constraint, to
verify that it is not already in _constraint_queue, if it is not, then
we may attempt to apply it, if it is in the queue, then we may safely
ignore it as it will be applied further down the registry cycle.
closesodoo/odoo#55725
X-original-commit: 5225b9ce5178302af05b63029fb184e27b781815
Signed-off-by: Adrian Torres (adt) <adt@odoo.com>
Useful information to identify where a translation comes from
Remove base.group_no_one as the view is already in debug only and
technical
closesodoo/odoo#55649
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Python 3 before 3.8 has a bug that causes the email.policy classes to
incorrectly fold and RFC2047-encode "identification fields" in email
messages. This mainly applies to Message-Id, References, and In-Reply-To
fields.
We are impacted by this bug since odoo/odoo#35929 where we switched to
using the "modern" email.message API.
RFC2047 section 5 clearly states that those headers/fields are not to be
encoded, and that would violate RFC5322.
Further, such a folded Message-Id is considered non-RFC-conformant by
popular MTAs (GMail, Outlook), which will then generate *another*
Message-Id field, causing the original threading information to be lost.
Replies to such a modified message will reference the new, unknown
Message-Id, and won't be attached to the original thread.
The solution we adopt here is to monkey-patch the SMTP policies to
special-case those identification fields and deactivate the automatic
folding, until the bug is properly and fully fixed in the standard lib.
Some considerations taken into account for this patch:
- `email.policy.SMTP` is being monkey-patched globally to make sure we
fix all possible places where Messages are being encoded/folded
- the fix is **not** made version-specific, considering that even in Python
3.8 the official bugfix only applies to Message-Id, but still fails to
protect other identification fields, like *References* and
*In-Reply-To*. The author specifically noted that shortcoming [2].
The fix wouldn't break anything on Python 3.8 anyway.
- the `noFoldPolicy` trick for preventing folding is done with no max
line length at all. RFC5322, section 2.1.1 states [3] that the maximum
length is 998 due to legacy implementations, but there is no provision
to wrap identification fields that are longer than that. Wrapping at
998 chars would corrupt the header anyway. We'll just count on the
fact that we don't usually need 1k+ chars in those headers.
The invalid folding/encoding in action on Python 3.6 (in Python 3.8 only
the second header gets folded):
```py
>>> msg = email.message.EmailMessage(policy=email.policy.SMTP)
>>> msg['Message-Id'] = '<929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>'
>>> msg['In-Reply-To'] = '<92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>'
>>> print(msg.as_string())
Message-Id: =?utf-8?q?=3C929227342217024=2E1596730490=2E324691772460938-exam?=
=?utf-8?q?ple-30661-some=2Ereference=40test-123=2Eexample=2Ecom=3E?=
In-Reply-To: =?utf-8?q?=3C92922734221723=2E1596730568=2E324691772460444-anot?=
=?utf-8?q?her-30661-parent=2Ereference=40test-123=2Eexample=2Ecom=3E?=
```
and the expected result after the fix:
```py
>>> msg = email.message.EmailMessage(policy=email.policy.SMTP)
>>> msg['Message-Id'] = '<929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>'
>>> msg['In-Reply-To'] = '<92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>'
>>> print(msg.as_string())
Message-Id: <929227342217024.1596730490.324691772460938-example-30661-some.reference@test-123.example.com>
In-Reply-To: <92922734221723.1596730568.324691772460444-another-30661-parent.reference@test-123.example.com>
```
[1] bpo-35805: https://bugs.python.org/issue35805
[2] https://github.com/python/cpython/pull/13397#issuecomment-493618544
[3] https://tools.ietf.org/html/rfc5322#section-2.1.1closesodoo/odoo#55656
X-original-commit: 02b78770147e2eda65a76d29c6f2fc3278581b22
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
The following commit https://github.com/odoo/odoo/commit/b3d9647695065ea582e4a6b0603f3ebf9fde6976 added the possibility to provide addtionnal context to RedirectWarningHandler.
Unfortunately the RedirectWarning python function does not handle the new argument and crashes.
This commit handle the addtionnal argument.
closesodoo/odoo#55487
Taskid: 2286999
X-original-commit: 60bbf47ad21abb1db7ebd2dc0a9379140007a93d
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Our CSRF tokens are based on the current user session, and automatically
expire as soon as the session does.
However, they also come with a default 1h expiration delay. This proves
to be a frequent annoyance for users who pause more than 1h on a form
before submitting it (e.g. user logs out and browser sits on login page
until the next day).
It can even lead to blocking bugs, e.g. when the 1h expiration occurs in the
middle of taking a survey exam, and the user is never able to post the
answers that are only present in the state of the form they need to
post.
More generally, users have a hard time understanding those CSRF expiration
errors, and don't know how to react.
Longer default expiration times have been considered (e.g. 1 day or
1 week) but those would not bring any identified benefit in terms of
security, while still giving a chance that some users would experience
the incomprehensible HTTP 400 errors).
Attacks that can typically compromise the CSRF token (XSS, RCE)
can achieve as much, or more, on the system or user account than what is
possible with the token. And nothing generally prevents the attacker
from using the token immediately after capturing it, during the initial
attack, making the expiration delay rather irrelevant.
Given there seems to be no significant benefit in expiring the tokens
before the session itself, let's just keep them valid as long as the
session.
Note: sessions are GC'd automatically after 7 days of inactivity,
which gives an effective 1 week expiry for abandoned web forms anyway,
as the token expires with the session.
Additionally, fix `survey` module tests, that were using an incorrect
regex for extracting CSRF tokens.
closesodoo/odoo#51499
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Task 2309613
We have a new hierarchy:
* Accounting
* [Generic, not changed]
* Localization
* Account Chart
* Check
* EDI
* Point of Sale
* Purchase
* Reporting
* Sale
This helps in displaying only the chart of accounts when clicking on
"Install more Packages" from the accounting settings in the Fiscal
Localization section.
We can also refine the search in the _auto_install_l10n post init hook
of account.
closesodoo/odoo#55384
Related: odoo/enterprise#12179
Related: odoo/upgrade#1568
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
When trying to generate translation for a model that is not present in
the registry (leftover of migration?), the code used to return
self.browse(), expecting an empty recordset.
self was however a TranslationModuleReader that has no browse method
return empty recordset with no model specified
closesodoo/odoo#55574
X-original-commit: c004f00bdec83b7c56664425011db53db85da53a
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Since commit 1b30a78b, LRU is now based on OrderedDict and keys can be found
on dictionnary 'd' directly.
closesodoo/odoo#55541
X-original-commit: 3f093da75765d66ed1e2d828e8b41ed05d936d0b
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Thanks to this setup, we will be able to run the tours independently to any demo data.
To do so, the HttpSavepointCase is born to do the same as HttpCase but with a setUpClass.
--task: 2290120
Some module description had changed without updating the .pot
closesodoo/odoo#55503
X-original-commit: ae3c28fe189468e91872971c397e62bad30e28f0
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
PURPOSE
When displaying an email in a list the mail client (gmail, outlook...) computes
a preview based on the content. This preview is generally not well computed as
it contains a lot of garbage and tags while it should contain only relevant
text.
SPECIFICATIONS
To build this preview, all mail clients read the content of the email.
The only way to be able to customize the preview is to add an invisible
HTML element at the beginning of the email with the wanted preview text.
We add at the end of the preview `‌` (zero-width non-joiner) to
fill the end of the preview in order to not have the beginning of the
mail at the end of the preview. It doesn't work with simple space as
the mail clients trim each HTML element content.
Task ID-2172125
PR #49886
Purpose of the task is, We saw that users encounter difficulties
while installing languages so improve the user onboarding experience
when user wants to install a new language.
So in this commit,
- Change the load langauge wizard title as 'Add Language' and rename
the button as 'Add'
- Removed documentation link as it is not up to date
- Added the 'Add language' button to general settings and it will open
the wizard to load the languages. and move the 'manage language' button
to the debug mode.
- After install added button 'switch to (lang) & close' to switch to
newly added language.
closes odoo/odoo#53581
Taskid: 2281393
Closes: #53581
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Co-authored-by: Nisha Patel <nit@odoo.com>
Purpose
=======
Since the 13.0, a regression has been introduced in hr_timesheet.
Considering:
- The account.analytic.line model, representing a timesheet entry
- The project.task model, representing a task, on which we have the fields:
- timesheet_ids: One2many
- planned_hours: Computed (sudo), stored, representing the sum of the timesheet amounts
- An ir.rule restricting the timesheets CRUD to his own only.
A user can only see its own timesheets on a task, but the field "Planned Hours",
which is stored-compute_sudo, should take all the timesheet lines into account
However, when adding a new line and then recomputing the value, no existing line
from another user is binded on self, then the value is erased and saved on the
database.
Specification
=============
This commit introduces a test that illustrates that bad usage of a shared cache.
A correct way to fix this could be to avoid using the cache if an ir.rule is pointing
to the related model. That would force the recomputation in a real sudoed environment.
closesodoo/odoo#55408
Taskid: 2285924
X-original-commit: 50e229fe66b2a82717d4260287e18a875bbd26f5
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Use "繁體中文" instead of "正體字"
It is a synonym but it is a bit more formal. It is also more coherent
with "简体中文" used for zh_CN
closesodoo/odoo#55387
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Before this commit, when being in a settings form view with at
least two items in the breadcrumbs (the settings view preceeded by
another one), clicking on a button to execute an action didn't
properly work: an history back was done instead, thus returning to
the previous action.
For instance, go to Sales (without demo data), click on 'Set
payments' in the onboarding banner, click 'Go to the configuration
panel', and in the settings view click on 'Install More Packages'.
The issue has been introduced by [1], but we couldn't find a
scenario to reproduce it before saas-13.3.
[1] a3845ae3f0
Issue spotted in task 2277314
closesodoo/odoo#55351
X-original-commit: 6ccb108e9a621a672fde715ea78656ffeb6834e5
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, the address of the company in the boxed template was not properly aligned with the tag line.
closesodoo/odoo#55344
Taskid: 2287262
X-original-commit: 03cfc283df715247fc33ce78698582788c1d4aa9
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
Allow to finely tune display of datetimes in front-end by adding support of
tzinfo parameter of babel format_datetime. See babel for more details about
its use.
Also add some missing translations bits due to last QWeb options added.
LINKS
Followup of 69d2513de21c2e80de605f77912a3687b8a79c6d
PR #55325
X-original-commit: c7d6e90c93e505950496eec382c89a9936d243be
Before this commit, footer were too small for "clean" template wieh the company address is displayed on 5 lines.
closesodoo/odoo#54330
Taskid: 2287262
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Steps to reproduce:
- install helpdesk, hr_expense (the demo data has a clear example of the bug)
- go to helpdesk > tickets > set a custom filter > "activities is set"
Previous behavior:
the results show the ticket with id=2 as if it had an activity set.
Because the search sql query collides with other activities set on other models
(hr.expense.sheet in this example)
Current behavior:
the sql query returns the proper result
opw-2273680
closesodoo/odoo#55297
X-original-commit: 6e90c41413f6a726c08071c71d01c738a6538079
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- Install Inventory
- Create an excel file with the following values :
--------------------------------------------------------------------------------------------------------------------------------------------------------
location_id | location_dest_id | Operation Type / database ID | Stock moves / product | Stock moves / unit of measure | Stock moves / name
--------------------------------------------------------------------------------------------------------------------------------------------------------
Partner Locations/Vendors | WH/Stock | 1 | Non existent product | Units | Test
--------------------------------------------------------------------------------------------------------------------------------------------------------
- Go to Inventory > Operations > Transfers and import the file
- Check the "Create if doesn't exist" option for "Stock moves / Product" and click on "TEST" button
Import fails because Product does not exist and is not created.
"name_create_enabled_fields" is used in frontend to store which fields have to be created if they don't exist.
The issue comes from the fact that the keys used in "name_create_enabled_fields" contain
the full path to the related field (i.e. move_lines/product_id), but only the final field name is used
when checking "name_create_enabled_fields" in the backend (i.e. product_id).
The prefix from the keys in "name_create_enabled_fields" should be removed when parsing fields from One2many.
opw-2282087
X-original-commit: fadce5c117e3a14ec659cf0accee85502214120d
RATIONALE
Even will soon gain a major update called Event Online, allowing to better
support full-online events. In order to prepare its merge, preparatory merge
are done to lessen the final diff.
PURPOSE
As new "Online Event" support is about to land, new and improved demo data
is necessary to showcase it. Improve online event demo data: have more tracks,
tags, colors, speakers, partners, descriptions, ... Make it WOW and AMAZING.
Improve demo data, especially track-related demo data: more tracks, better
datetimes, titles, tags, ... in order to have at least one event that looks
like a real event.
LINKS
PR #55260
Task ID-2310491 (Event Online Preparation 5)
Part of Task ID-2252655 (Main Online Event task)
Part of Task ID-2283796 (Event B2Basics / Registration Flow)
Co-Authored-By: Aurélien Warnon <awa@odoo.com>
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
RATIONALE
Events are sometimes held online, gathering a community. In this merge we
improve Event application to better support full-online events with improved
tracks, wishlists, chat rooms, ...
PURPOSE
Prepare Event Online support by providing fixes in registration and event
frontend flows. Also provide a quick back2basic in backend views to prepare
addition of Online sub modules.
SPECIFICATIONS
Allow to give add_direction to duration widget, propagated to babel formatting.
See babel for any information about its use.
LINKS
Community PR odoo/odoo#55197
Enterprise PR odoo/enterprise#12113
Task ID-2309702 (Event Preparatory Merge 4)
Prepares Task ID-2252655 (Main Online Event task)
Reported by VFE, odoo/odoo#54564 missed one of the use cases in menus:
normally a menu can have *either* sub-menus or an action (aka only
"leaf" menu items can have actions), however there's an exception for
root (application) menus: those can have an action, which is used as
the application's action, that is, what gets executed when opening the
application itself.
* root menus were already special cased (to allow a ``web_icon``),
expand this to allow both action and submenus
* modify the alternatives -- submenu-items and menuitems with a parent
-- so they keep the behavior of allowing *either* an action or
children
closesodoo/odoo#55144
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This commit introduces a new semantics to define action and method buttons
in the list view.
The aim of this feature is to be able to do some actions on selected records, or on the entire
records' domain with the help of buttons located in the controlPanel, much like the form view header buttons.
To define such buttons, one must add a `header` node in the list view's xml definition
```
<tree>
<header>
<button type="action|object" name="actionId|methodName" string="button's text" context="{}"/>
</header>
<field name="fieldName" />
</tree>
```
task-2246383
For clarity, some data files are formatted as pseudo-tree
structure. This is somewhat confusing and dangerous when the structure
has no meaning... so add meaning:
* allow nesting menuitems, nested items are set as children to the
parent they're nested in
* update schema to allow an icon *or* a parent on regular menu items,
and neither on nested (they have an implicit parent meaning can't
have an icon)
* remove attributes which don't actually exist from the menuitem
schema
* also type sequence as an integer while at it
Convert two large-ish menuitem data files to recursive form.
closesodoo/odoo#54564
Related: odoo/enterprise#11887
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
* fix link from backend tutorial to log_access section
* flesh out log access documentation
* add documentation for log_access itself & improve doc for a few
other model-level attributes
Currently there are a few issues with testing reporting (at the
command-line):
1. there is a global report after at_install tests, but it gets
"scrolled off" by long post_install tests, and is thus easy to
miss
2. with test tags, it's easy to fat finger a typo and run 0 tests,
which look like everything's running fine (no failure)
To improve this, print a global report at shutdown (in
`--stop-after-init` mode if tests are enabled) which recapitulates the
test results *and prints a warning if no tests were run at all*.
Also update the reporting collection to make this more reliable:
* have `run_unit_tests` return `None` if it has run no tests, the
assertion reporting machinery counts this as neither success nor
failure which is exactly what we want
* have load_test only report a success *if files were actually
loaded* (by having `load_data` return that information)
Task 2301268
closesodoo/odoo#54812
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this change, we create an xid for every parent of a record
being imported, regardless of whether it already has an xid, or if
it's being created implicitly through the child.
This generates unnecessary extra xids on pre-existing objects
e.g. update 5 product variants -> the product gets 5 new xids despite
already having one.
We should *only* set a xid on parent records which are being
implicitly created by the creation of a child with a specified
xid. That is, we should never set a xid on the parent if it exists
before the child is created.
Update _process_end to try and see if "non-loaded" xids correspond to
an automatically generated "parent" xid: we're still setting a xid on
implicitly created records (if the child is created with a xid) so
they're properly removed if e.g. the module is uninstalled, but
because we're only doing so at creation these xids will not be visited
during update and _process_end will try to delete them.
A special case can be added to check that "unknown" parent xids don't
have children which _inherit them, in which case we want to protect them.
Task 2251039
closesodoo/odoo#53283
Related: odoo/enterprise#12023
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The `initialize_sys_path` is the function responsible of getting the
custom Odoo import hooks to work, i.e. addons import via
`import odoo.addons`. This function is called by some other module
related functions to ensure the paths are correctly setup. We are
confident it is useless to re-initialize the path in many places.
The `load_openerp_module` function is called during server bootup by
both `odoo-bin server` and `odoo-bin shell`, both command parse the
configuration before starting the server which initialize the paths
already.
Most call to `get_module`, `get_module_path` and `get_resource_path` are
done in models or controllers where a registry is setup already. There
is one notable exception which is the subcommand discovery done during
the bootup, for that specific case, we initialize the paths with a
partially loaded configuration.
closesodoo/odoo#49715
Task: 2200956
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Make the error message more comprehensible for users, using the record's
display name, the company's name, the field's label and value.
Incompatible companies on records:
- 'Foo' belongs to company 'X' and 'Contact' (partner_id: 'Bar')
belongs to another company.
closesodoo/odoo#54883
X-original-commit: e410c90bbddb581100d170bf8180e790bb7af5fd
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Consider a context-dependent field and two possible cache structures for
storing the data of that field for N records and K context keys. The
common use-case is to assume that N is much larger than K. We look at
how many dicts are used in each cache structure, where we label dicts
with N entries as "large", and dicts with K entries as "small".
Structure | Number of dicts
---------------------------+-------------------
cache[field][id][key] | 1 large + N small
cache[field][key][id] | 1 small + K large
It is known that "small" dicts have a large relative overhead when
compared to "large" dicts. Given this fact, the second cache structure
will generate less memory overhead. Here are numbers for N=16, showing
the size in bytes taken by the cache structure. Larger values of N lead
to larger size differences, always in favor of the second structure.
Structure | K=1 | K=2 | K=3 | K=4 | K=5 | K=6
-----------------------+------+------+------+------+------+------
cache[field][id][key] | 4488 | 4488 | 4488 | 4488 | 4488 | 6536
cache[field][key][id] | 888 | 1536 | 2184 | 2832 | 3480 | 4256
Moreover, some memory operations are performed on many records and a
single context key. Those operations are clearly simpler and faster
with the second cache structure.
When default_get is called, the wanted fields are specified through the
fields_list arg. It is useless to fill the values for unwanted fields.
As default_get is called for nearly all records creation, simplifying
the default_get overrides:
* remove potential wrong side-effects of the values
* remove some useless or wrong defaults computations (searches, refs,
...)
Avoid concatenation of translated strings & raw values and/or other
translated values, and use the new _ API (by providing the formatting
values to ensure the fallback on the english terms in case of wrong
translation).
By including the expected values inside the string to translate, we
ensure that the formatted values are included at the right place in the
resulting translated text.
This also provides more information on the string to translate to
the translators, s.t. the chosen terms for the translations can be more
adapted to the translation context.
closesodoo/odoo#54635
Related: odoo/enterprise#11925
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Before this commit only admin setting user can merge contact which is a bit to restrictive
Contract Creation group seems more adequate
closesodoo/odoo#54831
X-original-commit: b5d5bc30dd3769deab09cbc0915741a93df229ef
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Barad Mahendra