Probably since recent changes in the views architecture, and
because the test coverage was recently extended, this test
failed when l10n_mx_edit module was installed.
While verifying the current user has access to all the fields specified
in the settings view, we browse all the fields, including the ones in a sub-view:
<field name="x_ids">
<tree>
<field name="whatever">
</tree>
</field>
x_ids being a settings field, but not whatever, which made the test fail.
To fix this problem, we check the fields belong to the res.config.settings
model before trying to access it.
closesodoo/odoo#104119
X-original-commit: 60f22b71063eada039f59321722e794c653acbde
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The initial bug report was the ability to disable all companies
at once and messing up the whole database when you do so.
However, forcing administrators to choose a new company for active users
before archiving a company seems relevant, and solve the
above reported issue in the same time.
closesodoo/odoo#104112
X-original-commit: 786ed3c7a688a662767abfb6e74e7f6dbc938f2e
Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since #98551, groups have been moved from views fields to xml content
to harmonize the behavior of xml and view groups.
Nevertheless, this reduced the coverage of the test verifying settings user
are always able to open the settings view.
This commit brings back part of that coverage, checking for each application manager
group that the settings view can be opened and saved correctly.
closesodoo/odoo#103989
X-original-commit: bb067f894a5e5511370990b98981e739565d2f2a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
See the explanation here:
https://github.com/odoo/odoo/blob/5069c8fd1cee063827873de0f6c2d9fe938337a9/odoo/addons/base/models/ir_ui_view.py#L1209-L1217
The strategy was to create a temporary
<t groups="..."> node which gets deleted after the postprocessing.
The deletion counted on the fact `groups` was the only attribute set
to delete this temporary technical node. In case
someone configured manually in a view architecture directly a t node
with a groups and something else.
But, studio adds another attribute to nodes with "groups=" in the
context of the studio edition (`studio=True` in the context)
https://github.com/odoo/enterprise/blob/7e66f89e1c85852908edc45e72706e51838960b0/web_studio/models/ir_ui_view.py#L53
and therefore another attribute was added on this temporary technical node,
which therefore didn't get deleted properly before being send to the
webclient.
So, we change the heuristic, instead of relying no the fact
`groups` was the only attribute, set a technical attribute on the node
to identify it comes directly from the postprocessing and it must
be deleted properly before being sent to the webclient.
closesodoo/odoo#103832
X-original-commit: 53c684a69bbe8894f05306631272bcf08c226f96
Related: odoo/enterprise#33096
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Since odoo/odoo#95729
nodes with a `groups=` are completely removed from the views when
the user is not part of the group, instead of being made invisible.
In that PR, views have been adapted to add back fields, with invisible="1",
when they were required, for instance when they were used in a domain
of another field which was still there despite the user is not part
of the given group.
As `tree` views having `multi_edit="1"` where not considered
as editable views, the domain of fields in these views were not
validated:
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1460
- https://github.com/odoo/odoo/blob/1fb8fa16ab7dc298d54f089d7163fb556dbc5fcc/odoo/addons/base/models/ir_ui_view.py#L1321-L1322
while they are well required for the web client,
in `multi_edit="1"` this is possible to edit relational/many2one field,
and therefore it will do `name_search` calls using the domain of the
field, and therefore the fields used in these domains must always
be present in the views. Without it, a crash in the web client occurs
when attempting to edit the relational/many2one field.
This revision targets to consider the `multi_edit="1"` tree views
as editable, to make the field domains validated as they should be.
Hence, views are adapted to add back fields with `invisible="1"`
when they are required in domains of other fields.
Part-of: odoo/odoo#103790
It was not always set (e.g. in the generate_email call of
mail.template) and it executes methods like _render_qweb_html where
data was already optional.
closesodoo/odoo#103840
X-original-commit: ddb2bf9f9cb6ea3a4bbdc4fb68c7fbcb0e66aa43
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The arguments for the method `fields_get` are `allfields` and
`attributes`, but this model is overriding it with different name,
provoking the error:
TypeError: fields_get() got an unexpected keyword argument 'allfields'
This commits fixes it renamign the argument to the correct one.
TT40013
closesodoo/odoo#103771
X-original-commit: 3884136b73b1efe4de6a28b9447a72a5d257666c
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
When looking to fetch grouped data from the database, `read_group`
should work(-ish), especially with support for `array_agg`. This also
means this need should be more or less solved around RPC: client can
either `read_group` or group on the client side.
This leaves a glaring hole in the fabric: there's no convenient tools
to apply grouping to recordsets. `itertools.groupby` exists, but it
requires that the input be grouped by the key function, and it yields
an iterable of items which is not the most convenient for recordsets.
This here utility:
- is exclusive to recordsets
- returns a mapping of grouping keys to subsets of the input recordset
- keeps the prefetching of the source recordset
- allows grouping on a field, or an arbitrary (callable) key
- should work even on "new records" (aka should be suitable for
onchanges / arbitrary compute functions)
While the method is RPC-compatible, it's not especially designed for
that, it is likely a much better idea for the client to `read` the
data they need then group that client side on whatever criteria they
are interested in, or `read_group` the aggregated information they
need directly if that's an option.
Part-of: odoo/odoo#101522
Since the recent css change the text of the description field was no taking all the place he could, so it was impossible to read, thanks to the colspan it's now the way it was intended
closesodoo/odoo#103634
X-original-commit: 93d29540ff6a6756a84d904047d4e9554d6d9ad7
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
The Owl web client does not suppress GTK-style mnemonics, so these
should be removed, as otherwise they are explicitly displayed.
Following GTK rules, the old GTK client would use the `_` letter
prefix in labels to underline the letter and use the corresponding
character as accelerator/mnemonic for activating the
control (https://docs.gtk.org/gtk4/ctor.Label.new_with_mnemonic.html).
The web client "supported" this feature by just ignoring and dropping
the `_` it found in labels, even after it gained support for keyboard
accelerators (= hotkeys).
The new Owl form just ignores GTK-style mnemonics entirely, not
performing that preprocessing on widget labels. As a result, the
mnemonic marker (`_`) now appears literally in some labels, and needs
to be removed.
closesodoo/odoo#103563
X-original-commit: ca80632a1045b26927f72d93f4ec58e7a58b5654
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
The same override of `_get_view` was done in `res.partner` and `crm.lead`
in order to call `_view_get_address`, to change the address format
of the partner and lead form.
The definition of `_view_get_address` was already shared between these
two models through the `format.address.mixin` mixin.
So, why not share the override of `_get_view` also in this mixin,
so only one override needs to be written, instead of two.
In addition to merge the code of the `_get_view` override
in `format.address.mixin`, also set the `_get_view_cache_key`,
so the partner and lead form are correctly cached by company,
in case multiple companies in a same db use different address views.
Before this revision, this wasn't the case for `crm.lead`,
which therefore leaded to a bug when two companies where
using different address view, and one company accessed the lead
form before the other, therefore caching its own view version
in the cache, re-used later by the second company when fetching
its own lead form.
This revision takes the opportunity to add a unit test for crm.lead,
to assert the expected form according to the company address.
There was already a test for res.partner, but not for crm.lead.
To avoid copy/pasting the unit for both models,
a common test class is created, re-used to test both res.partner
and crm.lead.
closesodoo/odoo#103438
X-original-commit: 7e4a8b77024af663c5555c6d56557e2c6136b24b
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Ducplicating a company is not allowed (see copy override in
base/res_company.py), therefore removing the button from the view
altogether can avoid user confusion.
Task-3000228
closesodoo/odoo#103250
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
classic layout issue due to the group that cause a wrong alignment
closesodoo/odoo#103205
X-original-commit: 2f5b96639c8bb7975696c507c11d57d164e52cbb
Signed-off-by: Morgane Demesmaeker <edm@odoo.com>
The `analytic_distribution` field is a Json.
It was stored temporarily as a char.
Search is not available yet, so we do queries by hand when we need to search on keys.
Also added a constraint on account_analytic_distribution_model,
so we don't have models with accounts specific to a company when the model has no company or another company.
It would cause an issue when looking at the models from another company.
X-original-commit: 7064c95aa04e5138bb12ae97acfee04ebb67cc0e
Part-of: odoo/odoo#103097
For non-translated field, when search(['name', 'in', list_right])
The behavior of False and the behavior of None in list_right should be the same.
Translated fields need customized process for 'in' operator
X-original-commit: a9a3c666f08c5612432dba40a69c7cfdc54ba96e
Part-of: odoo/odoo#103031
The trigram index function jsonb_path_query_array("column_name", '$.*')::text
uses all translations' representations to build the indexed text. So the
original text needs to be JSON-escaped correctly to match it.
X-original-commit: 7547df664945dddcb839e4903068f7f25ecfc08c
Part-of: odoo/odoo#103031
make searching translated field language dependent
add an extra filter using trigram index to speed up '=' and 'like' search
X-original-commit: 5b6f0a9e5f9d60735e306709a3e7d7ac46a586be
Part-of: odoo/odoo#103031
Instead of having a dedicated module for all-things dark mode related,
this commit moves the (S)CSS files into their respecting modules and
uses `web` and `web_enterprise` to provide the base infrastructure for
the dark mode (cf. dedicated assets bundle).
Note:
Don't forget that you have to handle 2 cases:
1: SCSS variables must be placed BEFORE bright ones
2: CSS variables must be placed AFTER
task-2710677
Part-of: odoo/odoo#102868
This commit adapts several components in order to correctly handle
color-scheme variations.
It also allows user_menu to handle switch entries
task-2710677
Part-of: odoo/odoo#102868
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Using patcher.start() can easily lead to incorrect cleanup.
-> after a copy paste, patcher is working, but stop is forgotten
-> stop is present, but won't be called if something fails during the
test
This commit add an utility `start(patcher)` to always have the add
cleanup.
Using a standard way to start the patcher with an automated addCleanup
should prevent this kind of mistake. This is why this commit also
replaces all valid patch.start() (followed immediately by a addCleanup)
closesodoo/odoo#102873
X-original-commit: 7d5a193d86316965a0908c65cfacfb607dc3f3ad
Related: odoo/enterprise#32618
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
It is technically nearly impossible to delete a company
when it actually dealed with customers
(emitted invoices, received payments, ...).
Hence, if you want to get rid of a company,
for instance because you closed one of your subsidiaries,
giving the possibility to archive your company,
thanks to an active field, would be the best way to go.
We are hesitating to do a related field to the
`partner_id.active`, but we are a bit afraid
some people archive the partner linked to their company
for other valid reasons than get rid of their subsidiary
(such as avoid changing the address of their company
by mistake through the Contacts app),
while still wanting the company itself to be active.
So, we make it an independant column at the moment,
so we have the actual stored column in case we need it,
and will do a related stored to the partner
later on if we change our mind.
Manual forward-port of #102801closesodoo/odoo#102586
Signed-off-by: Olivier Dony <odo@odoo.com>
Before this commit the neutralize system introduced in v16 was using ORM
methods in order to change appropriate records. Although flexible, this approach
could lead to call some methods with side effects while neutralizing
(eg: overloads of write).
This patch converts the neutralize system to a safer "inert" SQL based approach
by migrating the generic method _neutralize to SQL files exposed in the
data folder.
Task id: 2961687closesodoo/odoo#102792
X-original-commit: e5dbded9bb363351feff7ca8a56c7f8a6860f492
Related: odoo/enterprise#32580
Signed-off-by: Fabien Meghazi <fme@odoo.com>
Only kanban, tree and form implements onchanges.
Therefore, on calendar, graph, pivot, ..., putting `on_change="1"`
is useless and is a waste of resources and KB.
e.g. CRM lead pivot view
Before:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After:
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" modifiers="{"invisible": true}"/>
</pivot>
```
I would have like something smarter, like using the `editable` concept
for instance, but it's not that easy.
e.g. kanban is not considered as editable, while it does support
onchanges when grouping record by a field and drag and dropping
record from one column to another.
However, if we change the kanban view to make it editable,
the view validation will start validating the fields domain:
https://github.com/odoo/odoo/blob/45d4ac14f65c53dcde56592715d50169bde116ad/odoo/addons/base/models/ir_ui_view.py#L1439-L1442
causing issues:
- If a field used in the domain is not in the view, it will need to be
added in the view,
- while it will not be used, as you cannot do a search in related fields
in kanban views anyway.
e.g.
```
odoo.tools.convert.ParseError: while parsing /data/build/odoo/addons/analytic/views/analytic_line_views.xml:120
Error while validating view near:
<kanban class="o_kanban_mobile" __validate__="1">
<field name="date"/>
<field name="name"/>
Field 'company_id' used in domain of field 'account_id' ([('company_id', 'in', [company_id, False])]) must be present in view but is missing.
```
In addition, the kanban doesn't need the readonly and required
attributes on the field nodes, as other editable views (tree and forms)
do.
In addition, the tree list is currently considered as "editable" only
when it has `editable="bottom" or `editable="top"`, while
a tree without this editable attribute can still trigger onchange,
for instance when using `widget="handle"` or `widget="boolean_toggle"`.
We should therefore making the tree list editable whatever the case,
leading to the same issues than listed for the kanban above,
or make an exception for field in non-editable tree views using a
widget..
So, as the smarter way seems difficult and risky, for a limited gain
I choose the easy way by separating the concept "editable" and
"onchange-able" and to not set `on_change="1"` on views not considered
as "onchange-able".
closesodoo/odoo#102788
X-original-commit: aeb65ee536b1611c1cb829c91906f327f8e331c7
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Replace some layout magic with some layout determinism; in particular,
the view attempted to have a 4 column layout which is not well supported
in grid form views.
This commit instead create a "normal" structure (outer group > inner
group) for "boolean" group access (e.g. 'Extra Rights' or 'Technical'
sections of the user form access groups, whilst in debug mode).
closesodoo/odoo#102789
X-original-commit: fd854e87d8a138052302afbd3da486f41102c695
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
in b1d57adf6ff3 the size of the header added to source files while
concatenating them was reduced, but the corresponding offset use when
generating source maps was not adapted, causing source maps to drift
further and further from the actual source location the further in the
compiled asset the line is.
This commit fixes that by decrementing the header offset as needed.
closesodoo/odoo#102651
X-original-commit: 4d4585ee6c905c2a3adc4692098c1a3544417629
Signed-off-by: Géry Debongnie <ged@odoo.com>
Signed-off-by: Samuel Degueldre <sad@odoo.com>
The bundle name is irrelevant in the bundle content and will prevent
attachment to store the same file if the bundles are exactly the same.
closesodoo/odoo#102502
X-original-commit: b1d57adf6ff358aa79f41817f4f7bfe60f9e5ac0
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
If source is something like
"admin@éxample.com" <admin@éxample.com>
candidates founds are
['"admin@\xc3\xa9xample.com"', 'admin@\xc3\xa9xample.com']
and the first one raises an error because of "".
Malformed addresses should be ignored.
opw-2982426
closesodoo/odoo#102353
X-original-commit: 35ad2dd630a8ed173c6a9275585eac46b9a19363
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Julien Castiaux <juc@odoo.com>
pivot, graph, cohort views do not care to know whether a field
is readonly or required, as you cannot edit records in these views.
Even kanban is readonly in most cases:
- you can drag and drop records from one column to another,
which is prevented if the group by field is readonly
but this shouldn't rely on the fact the field is
within the architecture, as you can group by on any fields
from the search views / control panel.
Hence, this shouldn't rely entirely on the modifiers passed on the field
nodes in the view architecture alone.
- you can create new record inside the kanban,
with a simplified form, thanks to the `quick_create`,
but this uses an independant form view, in which the readonly and
required modifiers are correctly passed.
So, `modifiers="{'readonly': true, 'required': true}"` can be dropped
for kanban views as well.
This allow to spare some KB by not setting useless modifiers in views.
e.g. CRM > My pipeline pivot
Before
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row" modifiers="{"readonly": true}"/>
<field name="stage_id" type="col" on_change="1" can_create="true" can_write="true"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true, "readonly": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
After
```xml
<pivot string="Pipeline Analysis" sample="1">
<field name="create_date" interval="month" type="row"/>
<field name="stage_id" type="col" on_change="1"/>
<field name="expected_revenue" type="measure"/>
<field name="color" modifiers="{"invisible": true}"/>
<field name="automated_probability" modifiers="{"invisible": true}"/>
<field name="message_bounce" modifiers="{"invisible": true}"/>
<field name="probability" on_change="1" modifiers="{"invisible": true}"/>
</pivot>
```
Regarding the change of behavior shown in `addons/web/static/tests/views/kanban_view_tests.js`.
It was introduced very recently, by myself, in
odoo/odoo#100806
I revert this possibility to set readonly="0" on a field node in a
kanban view, because:
- First, this is not used anywhere in both odoo/odoo and
odoo/enterprise.
- Second, this really makes things harder if we want to do so:
- as readonly="0" is passed, the "readonly" gets removed from the node
modifiers, as they are simplified by removing falsy value:
modifiers="{'invisible: True, 'readonly': False}" becomes modifiers="{'invisible': True}"
- as readonly in not amongst the modifiers, it fallbacks on the model
field property, in the javascript code, which is readonly: True.
- the thing to do would be to still transfer "readonly"
from the field attributes to the node modifiers.
- which either mean to consider a kanban view as editable
- this will cause issues because the validation mechanism
will suddenly check the domain attribute property
https://github.com/odoo/odoo/blob/d4a92b112d0554a2624f7768feb7d54e0484469f/odoo/addons/base/models/ir_ui_view.py#L1443
and there will be plenty of views where some field used in the
domains will be missing. Besides it is pointless to validate these
domains as they are completely unused in kanban views
- either mean to find another mechanism than "editable" to decide
wheter to transfer the modifiers "readonly"/"required" or not,
which over-complicates things.
- besides only "readonly" would need to be passed, not "required.
So, to keep the code stupid simple, I remove this possibility added only
a few days ago, which is actually not used anywhere in standard for the
moment.
closesodoo/odoo#102221
X-original-commit: 69c3d5aa25655173ed66a52570559322c650c7df
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
In `--dev xml` mode,
you would like the views to be loaded from their definition
in the XML file directly.
The view caching introduced in odoo/odoo#99417 prevents that feature,
as once the view has been loaded a first time, the views are returned
directly from the cache, therefore not taking into account changes
directly done in the XML file views.
Setting a conditional decorator,
disabling the caching when in `--dev xml` mode,
solves this issue.
Solves https://github.com/odoo/odoo/pull/99417#issuecomment-1241977197closesodoo/odoo#102117
X-original-commit: 5fe1d89f4d8718df92c39a80d4b575b8d0381c19
Related: odoo/documentation#2786
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
By definition, views are useless without the web client.
The web client is in the module `web`.
Therefore, in a perfect world, the `get_views` model method
and any related method should be within the `web` module,
as without it they are useless.
Let's imagine you would like to use fully in command-line,
without web client, all those view related methods are useless.
Maybe excepted for reports, as you might still like to be
able to print reports while using odoo fully in command line.
Views related method therefore shouldn't be in `odoo/models.py`.
Also, when you think about it, `get_views` related methods do not
make sense without the model `ir.ui.view`, which is loaded after
the `get_views` related methods, which also doesn't make sense.
However, moving these methods fully in the `web` module is an harder
work. For instance, there are base models, such as res.partner,
already overriding `get_view` in the `base` module,
and therefore relying on these view related methods.
As a first step, we move view related methods direcly in the
`odoo/addons/base/models/ir_ui_view.py` file, where
the `ir.ui.view` model is loaded.
This is not only a design / cleaning change,
but a required change to be able to use content of
`odoo.tools.config`, which is loaded after `odoo/models.py`.
For instance, if you want to configure a conditional decorator based on
the config `odoo.tools.config['dev_mode']`, it is not possible
to do so in `odoo/models.py` because the config is parsed/loaded
after `odoo/models.py`.
The config is loaded here:
https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L127
While, within the same file, `odoo/models.py` gets loaded through the
`import odoo`
https://github.com/odoo/odoo/blob/31de2b0a7a0921cab3c6c54045d15da46c8e6d8a/odoo/cli/server.py#L26
And we would like to put such a decorator based on `odoo.tools.config['dev_mode']`
on `_get_view_cache`, to not cache the back-end views when `--dev xml` is
passed in the server arguments.
X-original-commit: 0901adc38a724aec75676285977f1905a84ed8ee
Part-of: odoo/odoo#102117
During tests, when matching ir.mail_server has `smtp_encryption` set to
`starttls`, connect() will crash with an AttributeError as follows:
2022-09-22 07:04:27,882 20445 ERROR tests-150-starttls odoo.addons.base.tests.test_ir_mail_server: ERROR: TestIrMailServer.test_mail_server_send_email
Traceback (most recent call last):
File "/home/odoo/src/odoo/15.0/odoo/tools/misc.py", line 804, in deco
return func(*args, **kwargs)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/tests/test_ir_mail_server.py", line 261, in test_mail_server_send_email
IrMailServer.send_email(message, mail_server_id=self.server_domain.id)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/ir_mail_server.py", line 575, in send_email
smtp = self.connect(
File "/usr/lib/python3.8/unittest/mock.py", line 1081, in __call__
return self._mock_call(*args, **kwargs)
File "/usr/lib/python3.8/unittest/mock.py", line 1085, in _mock_call
return self._execute_mock_call(*args, **kwargs)
File "/usr/lib/python3.8/unittest/mock.py", line 1146, in _execute_mock_call
result = effect(*args, **kwargs)
File "/home/odoo/src/odoo/15.0/odoo/addons/base/models/ir_mail_server.py", line 313, in connect
connection.starttls(context=ssl_context)
AttributeError: 'TestingSMTPSession' object has no attribute 'starttls'
This commit adds a dummy `starttls()` method to `TestingSMTPSession` to
gracefully handle such case.
closesodoo/odoo#101962
X-original-commit: ec156901dd4db2fc7a2827b1eb78515f6259699e
Signed-off-by: Julien Castiaux <juc@odoo.com>
Signed-off-by: Xavier Alt (xal) <xal@odoo.com>
Purpose: Enhance the profile picture of
* Mitchell Admin and Marc Demo as they
are now sometimes shown in larger sizes (as in appointment).
* Joel Willis, whose picture is used on his eLearning profile
Task-2992949
closesodoo/odoo#101945
X-original-commit: d0e1360e63efca56c06fad82780ab6a96fb6f0eb
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Setting the attributes `can_create` and `can_write` in views
which are not editable is useless as you cannot edit the record
in these views.
This allow to gain some KB when serving the view to the web client,
as well as making the view cleaner.
e.g. the graph view in the CRM > My Pipeline menu
Before:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id" can_create="true" can_write="true"/>
<field name="user_id" on_change="1" can_create="true" can_write="true"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
After:
```xml
<graph string="Opportunities" sample="1">
<field name="stage_id"/>
<field name="user_id" on_change="1"/>
<field name="color" modifiers="{"invisible": true}"/>
</graph>
```
This revision takes the opportunity to port the `editable` concept
from the server to the web client MockServer,
in order to be able to test the removal of these attributes from the views
in the QUnit tests.
The `_editableNode` JS function added here is the translation of the
existing `def _editable_node` method in `addons/base/models/ir_ui_view.py`
https://github.com/odoo/odoo/blob/f5edde3624f4fe40f87cc7fed7dcfc4bbce1f19f/odoo/addons/base/models/ir_ui_view.py#L1282-L1301closesodoo/odoo#101902
X-original-commit: f0beddf534a57e972ac3a7bef6afa1caae1dcff3
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
*: im_livechat, survey, utm, website_crm_iap_reveal, website_forum,
website_livechat, website_sale, website_sale_comparison
Before this commit all cookies were considered essential.
This commit makes some of them optional. It also makes it possible for
the website visitor to only accept the essential cookies.
task-2800976
X-original-commit: 9a8a9463289a7446e9be0ef62ff895feb37a4de4
Part-of: odoo/odoo#101845
Co-authored-by: Benoit Socias <bso@odoo.com>
This is an oversight in odoo/odoo#100130
A modifier set with `context.get('...')`,
for instance
`invisible="context.get('sign_directly_without_mail',False)"`
takes priority on attrs
only if the result of `context.get('...')` isn't falsy
e.g.
https://github.com/odoo/enterprise/blob/1a4e4fafe4fc78dab0aad7ab6241a6f4a7be317a/sign/wizard/sign_send_request_views.xml#L64
should return
- `modifiers="{'invisible': [['is_user_signer', '=', false]]}"`
with `context.get('sign_directly_without_mail') == False`
- `modifiers="{'invisible': true}"`
with `context.get('sign_directly_without_mail') == True`
closesodoo/odoo#101813
X-original-commit: a3dc5f5fd34671c67253c6ff36bb7c960f9170ff
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Steps to reproduce:
1. change system and admin's time zone to one with a different
date than UTC
2. enable multi-currency in the accounting module
3. add rates for the current date in local time zone and UTC
4. go to settings > currencies
5. the rate for the UTC date is displayed
To fix this, we should use a time zone aware field in `res_currency`.
opw-2945108
closesodoo/odoo#101686
X-original-commit: 2f1d8d6db4efab86d35f362138e80e03692537dd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Khanalizadeh Ahmad (khah) <khah@odoo.com>
Purpose
=======
The template user groups are applied to new users, but this is not the
case for existing users.
To harmonize the flow, the added groups to the default user template are
synchronized with the existing users.
closesodoo/odoo#101086
X-original-commit: aefb05eb497a8a16a9359432f41024c09552ed70
Related: odoo/enterprise#31759
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
If called in cascade, this could lead to a situation in which a same
thread is trying to create recursively several registries when loading
the sames modules, which obviously cannot work in any way.
Use button_install instead, that will simply update the module state
while waiting to be installed in a proper way, instead of forcing
a registry creation that will mess the whole process.
X-original-commit: 6b52844a8dc78788cbd948c7e2f90156ee8b89d7
Part-of: odoo/odoo#101086
xmo-odoo