With the introduction of Knowledge Behavior Component, came a need to create
html nodes which would have limited interactions with the editor. i.e. an Odoo
view already has everything it needs to function properly, and when it is
inserted in the editor, any manipulation on the selection or on the style that
could be done with it should be prevented. Another example would be the
/template block (will be renamed /clipboard in the future) that has a
non-editable part (buttons which have a definite action in Odoo, and which
should not be interacted with) as well as an editable part inside of it).
To solve this use case, this commit proposes to mark specific html nodes with
a `data-oe-protected` attribute which could have one of three values:
- "true"
- Only mutations of type "attributes" can be registered on the node itself
which has the `data-oe-protected="true"` attribute
- Prevent mutations of children (and sub-children) from being registered by
the mutationObserver of the editor
- Prevent the selection handling when its anchor is inside a
`data-oe-protected="true"` element, even if it is `contenteditable="false"`
- Prevent the command hint
- Prevent the usage of the wysiwyg toolbar
- Prevent the dblClick tooltip
- Prevent the editor sanitization `Sanitize.js`
- "false"
- Designed to be contained inside a node with `data-oe-protected="true"`
- Re-enable all features disabled by a parent node with
`data-oe-protected="true" for the children of a node with
`data-oe-protected="false"
- ("")
- This is considered equivalent to have the `data-oe-protected` attribute
set to "true" (like other html attributes).
Another attribute is added: `data-oe-transient-content`, with the following
values:
- "true"
- Prevent the serialization of the children of the node, so they are not
shared during a collaboration.
- Transient nodes will be removed during `cleanForSave`, meaning that they
will never be part of the html_field value in the database
- ("")
- equivalent to "true"
The use case is an embedded view: there is a large quantity of nodes that
are not relevant to share nor to save, since it will be recreated with the
lastest data from the database, with the information relevant to the
currently active user each time it has to be rendered.
Note:
This commit does not handle the dynamic switch from a specific value for
`data-oe-protected` to another (i.e. switching from "false" to "" or "true").
This could cause a number of problems like:
- some mutations from when the value was "true" are not yet handled when the
switch (to "false") happens => those mutations will be registered as if they
were always under the "false" value, even though it is not the case.
- in collaborative, some nodes with oids that were not relevant (under the value
"true") won't necessarily have the same oids in between collaborators.
Therefore we cannot suddently listen to their mutations and expect the changes
to be shared by switching to "false".
In conclusion: the `data-oe-protected` attribute value should stay the same
during the entire edition.
Task-2821374
Part-of: odoo/odoo#104680
odoo/odoo#111651 improved and optimised triggers but dropped the
in-place cleanup of field dependencies. As a consequence, during
module uninstallation if a stored computed field is removed (because
it's part of a module being uninstalled), and one of its dependencies
is subsequently altered (e.g. it's itself removed, or written to) the
second update will break as the query trying to find out which
dependent records to update will error, either because of trying to
select / filter on a missing column, or because of trying to fetch
in a missing table.
The simplest examples of this issue are computed fields with a
dependency on `ir.model`:
- In `calendar`, `calendar.event.res_model` is a related on
`res_model_id.model`, this prevents the removal of *any* `ir.model`
record if it gets uninstalled.
As a result the `calendar.attendee` and `calendar.event` tables
don't get removed (just emptied of all their non-automatic fields),
their records remain as well, and when the non-automatic fields get
re-added during installation re-instating the NOT NULL constraints
fails, breaking the uninstall/reinstall test.
- In `payment`, `payment.provider.module_state` is a related on
`module_id.state`, this breaks *during* uninstallation, as after
`module_uninstall` first calls `_module_data_uninstall` which
removes the field, then it *updates the modules being uninstalled*
(sets their state), which tries to find out which
`payment.provider`'s `module_state` is should update, which breaks
because the `module_id` column has been removed.
This second one was worked around in odoo/odoo#118900, by marking
modules as uninstalled before actually gutting them, but as it turns
out the "actual" fix is needed anyway. So revert the workaround, and
actually fix the issue.
closesodoo/odoo#119130
X-original-commit: 48a420efcf7c7b46416bab006003553cc9d23846
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Make the public `read_group` depends of its private method `_read_group`
refactored to match the backend usage.
We try to keep the public API similar for this first part of the
rafactor, but there are still some API change:
- We cannot order by `id` anymore.
- The display_name of many2x group values are not lazy anymore.
Part-of: odoo/odoo#110737
Lot of override of read_group reimplement partially custom security
rule of `_search` method. In order to simplify these security check
and have a consistent behavior between the search and read_group method,
_read_group now use _search to create the from and where clause.
Part-of: odoo/odoo#110737
The `_read_group` was designed to be used by the web client to
efficiently compute aggregations grouped by one or more fields.
However, more and more developers have been using it from the backend
to make computations more efficient (avoid doing the aggregation
in Python). Unfortunately, the API was designed for the web client,
which added a lot of boilerplate when used in the Python (list of
dict with misleading key name choices).
`_read_group` was created to improve the performance of read_group
for backend use (4ef0c00b4b), but didn't
change the API and based the implementation on read_group itself.
Rewrite `_read_group` from scratch with a new API to make it easier
to use from the backend (see the method documentation). Also, split
the method to make it easy to override and add custom behavior.
Part-of: odoo/odoo#110737
The default `group_operator` of `Many2oneReference` is 'sum' (inherited
from the parent class `Integer`), it doesn't make any functional sense
to sum ids.
Also set group_operator to None on `co2` instead of override read_group
for the same result.
Part-of: odoo/odoo#110737
before this commit, on duplicating a contact tag
will duplicate the assigned partners also.
suppose if we have a partner A with tag B assigned,
and then we duplicate tag B and create new tag C,
the newly created tag is automatically getting
assigned to partner A.
after this commit, the copy is set to False for
partner_ids field in tag and then the partners
wont be copied on duplicating a tag
closesodoo/odoo#118974
X-original-commit: 5dc9104403606b6421b9cde732cfa3d6bb5962aa
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Before this, uninstalling the `payment` module (or any of its
dependencies) is broken: as payment.provider has a dependency on
ir.module.module.state, marking the modules causes a lookup of the
payment provides to update, but the table was removed by
`_module_data_uninstall`, so the lookup blows up.
This is a consequence of odoo/odoo#111651 which improved and optimised
triggers but dropped the in-place cleanup of the triggers tree.
Thus while the columns & tables get removed from the database the
in-memory structures (registry, models, fields, ..., as well as the
trigger and dependency caches) are not so the python side will happily
try to look up stuff which has been nuked if accessed at the wrong
moment (which is any moment between the start of
`_module_data_uninstall` and the creation of a new registry, really).
As `_module_data_uninstall` is nothing but a giant pile of dodgy state
anyway, making modules as uninstalled before it executes doesn't seem
like a huge deal. It may cause unnecessary extra recomputation for the
few models which depend on modules, but that doesn't seem like a major
issue, at worst it makes uninstallation a touch slower but they're not
a huge performance concern at the moment (they're more of a
correctness one).
closesodoo/odoo#118959
X-original-commit: 460efeb623ec62c980d187710bd4e7614af0e7bd
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Making a test post_install using @tagged should always remove the
at_install tag.
The main reason for that is that runbot split config select if an
at_install or post_install tests should be executed is using negation:
`--test-tags -post_install`. The reason for that is that giving a positive tag will
replace the "standard" tag and non standard tag could be executed if
giving `--test-tags at_install` (without negation)
Since runbot tests in parallel builds, one of them using
`--test-tags -post_install` and the other `--test-tags -at_install`,
a test that is both post install and at install wont be executed at all.
Also, a tests with both tags will be executed twice
in a normal flow, usually not intended.
The correct way to make a test post_install is to use
@tagged('post_install', '-at_install')
closesodoo/odoo#118969
X-original-commit: d1db306b212d4abb5b2faab9e56c8e83b85c53b9
Related: odoo/enterprise#39966
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This commit fixes a use case where a user would not be able to access the
property field values of a record because he did not have access to that
record's parent (from the property field definition configuration).
In a concrete example:
- In the Knowledge App
- Marc Demo has access to the "Article B".
- The parent article of "Article B" is "Article A".
- Marc Demo does not have access to "Article A".
- Article B has some property fields values configured.
- If Marc Demo tries to open "Article B" -> crash
This is caused by the framework having to read the property definition from the
parent record, which we don't have access to.
A "sudo" was added to allow that use case (which is supported).
In addition, this commit also adds further checks on the web client side to
gracefully handle a special use case where the end-user could not write on the
parent record because of record rules.
(It only checked *access rules*).
To avoid making an extra RPC every time we load the record (to check if we can
write on the parent), we only make that check when the user tries to modify
(add/edit/remove) a property and show a proper error message.
(This also applies when creating new property field tags).
Task-3062064
closesodoo/odoo#118929
X-original-commit: bc538f6944461a642bac0f757ec96d7f8cc14c9a
Related: odoo/enterprise#39946
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit, when the user changes the access rights of another
user, he will see a warning message the other access rights will change
with his changes. In that warning message, `Other` category could be
displayed and that category is only displayed in the user form view if
the user is in debug mode since it is a Technical category.
This commit hides the `Other` category in the warning message when the
user is not in debug mode to be consistent with the visibility of that
category in the form view.
task-3049636
X-original-commit: 9998ec50652a0c9b66e5f2b2c0ef5ce30861b79f
Part-of: odoo/odoo#118825
At the moment, XSD files are automatically downloaded at database
initialization, which is quite unnecessary.
The idea is to change Odoo's use of XSDs from being systematically
downloaded and used for validation to simply being available if desired
(e.g. for development or for customers who want them).
To achieve this, this commit does the following:
- remove the XSD download crons;
- provide a 'download XSDs' button in the Settings (next to the debug
mode button) which is available in debug mode;
- skip XSD validation if any required XSD file is not present; and
- deprecate the 'force_reload' option.
Entreprise PR: odoo/enterprise#38350
Task id: 3010716
closesodoo/odoo#118790
X-original-commit: c8174c7914e567489de74b574b076467440bdb2d
Related: odoo/enterprise#39879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
When new records are used to precompute some fields, the computations
are expected to use the "right" values for floats, in particular float
fields are expected to be rounded.
closesodoo/odoo#118518
Signed-off-by: Raphael Collet <rco@odoo.com>
before this commit, the form view of
ir.actions.act_window.view was not properly aligned.
* open any menu linked with type ir.actions.act_window
* click on Edit Action from debugger button
* click on Add a line from the View one2many field
after this commit, the view will be
aligned properly.
closesodoo/odoo#118764
X-original-commit: 369a8cfca3f8165d6a7b6849b65564e396de9e76
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
The current profiler will add default value in the user session
using disk space without valid reason.
This commit makes those parameters optional in the session.
closesodoo/odoo#118762
X-original-commit: eb3bf03b119105f56806d7460fccd4c0133deaab
Signed-off-by: Jérémy Kersten <jke@odoo.com>
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Prior to this change the convert tool did could mangle
the value of html fields when importing static data.
This is because html does not support 'self-closing'
except for HTML5 where it is allowed on void elements (such as img).
Browsers will assume that they are opening tags, left unclosed.
<span/> becomes <span>
They will then try to repair them with variying degrees of success.
Example where it fails:
`<t><t/></t><t><t/></t>`
should become
`<t><t></t></t><t><t></t></t>`
but it becomes
`<t><t></t><t><t></t></t>`
i.e. instead of closing the 'self-closing' tag immediately,
it puts everything inside a single t node
More concretely:
```
<t t-if>
<t t-out />
</t>
<t t-else>
<t t-out/>
</t>
```
becomes
```
<t t-if>
<t t-out></t>
<t t-else>
<t t-out></t>
</t>
</t>
```
which is invalid
-------------------------
The fix is simply to tell lxml that we want to print the xml nodes
as HTML nodes. This will make sure the output is compliant with
the standard and keep the semantic clear for the browser.
The issue does not appear before 16.2, as jquery used to fix it
for us until an update here 9c41ee5091ac06ac3ca71aeac607195c70061e4a
task-3162320
X-original-commit: 8ff2e1018264972107f19755ecda352d78dfa829
Part-of: odoo/odoo#118710
This commit consists of a full rework of the quick create form in the calendar
view, so that it shows more options to the user rather than only the name of
the event. To accomplish this, we added a new attribute on the calendar view
with the id of the quick create form view to be used. This allows us to have
a custom view to be shown on quick create.
task-3129030
closesodoo/odoo#114827
Signed-off-by: Leonardo Pavan Rocha <lpr@odoo.com>
This commit adds the loading="lazy" attribute to every img tags compiled
by the kanban compiler and modifies some kanban archs in order to use
img tags instead of divs with background-image style to load images
(this allows again the loading="lazy" attribute to work).
The purpose is to avoid loading images that are outside the user viewport
at all time in order to reduce the load on the network when new images are
loaded.
Steps to test: find all views that are using the o_kanban_image or o_kanban_image_fill_left
class and ensure all the images in these views appear in the network tab of devtools
when they enter the user viewport. Example: res.partners, hr.employee, ...
task-3102207
closesodoo/odoo#117049
Related: odoo/enterprise#39560
Signed-off-by: Géry Debongnie <ged@odoo.com>
The geoip2 module is not installed in the iot so this one cannot launch Odoo.
This module is not used by the iot so it is not necessary
to install the module in the iot and therefore to make a new build
From this commit c59750d824closesodoo/odoo#118240
X-original-commit: 5f251f7c95adf9b67ef1c81ee0084b0b5c396cc3
Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>
Precommit hooks would stock data until a call to ``cr.flush`` was made.
Notably, this happens when the ``assertRaises`` method is called.
Functions were applied on records already cleared from the cache.
This change adds a cleanup call for `TransactionCase` as it keeps
the same cursor for all tests. Cursor precommits can now
be safely executed inside tests.
Task-2834304
Forward port of #117555closesodoo/odoo#118290
X-original-commit: ff5d0c75fcea5842c5236b1b3f7480ef5a3dc415
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Thiry Renaud (reth) <reth@odoo.com>
Along with improving the table_kind API, #117439 added a warning when
dropping non-tables.
This warning turns out to trigger on many models, in two major cases:
- the hook is called on abstract models, which don't have a table in
the first place, it probably should not be called for those but can
easily be skipped
- the hook is also called on `_auto = False` which don't have a table
anymore, this is because we use `DROP TABLE $table CASCADE`, which
implicitly drops any view (or table) depending on the table, it
might be possible to avoid this by ensuring we drop models in
reverse topological order *and* drop all of a module's views then
tables at once (by passing multiple names to `DROP`, but for now
just ignore the case where we're trying to drop an object which
can't be found
closesodoo/odoo#118194
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
This is an improvement over commit f6c13d7 in order to allow full
customization of postgresql connection's `application_name`.
In a PID linux namespace the containers processes IDs might not be relevant
for a system administrator and one might want to customize the content of the
`application_name` just like it was possible to do before commit f6c13d7
using the `PGAPPNAME` environment variable.
This commit allows to expose an `ODOO_PGAPPNAME` environment variable whose
content will be interpolated with the PID (optional)
closesodoo/odoo#117921
X-original-commit: a4108eee91f8e9bf82be5a4be4b91bab16baa0df
Signed-off-by: Olivier Dony (odo) <odo@odoo.com>
As a developer,
when you craft your records set manually,
and wrongly use the API and set something weird in `ids`,
something else than a tuple of integers,
`repr` should help you to understand you did something wrong.
e.g.
before
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner(1,)
```
after
```py
In [1]: env['res.partner']._browse(self.env, '(1,)', 'bar')
Out[1]: res.partner'(1,)'
```
We could put an assert in `_browse` to make sure `ids`
is a tuple of integers, but this is considered a non-stable
change, as it will suddenly crashes when you will update
Odoo while it wasn't the case before.
closesodoo/odoo#118119
X-original-commit: f689c4f53fc4663b17c57bd1d704b9ffb9f11f8d
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
The co-model field in `IrField` view is accepting Related Model name
even if it is invalid. And replaces the invalid model name with `_unknown`.
This causes KeyError `display_name` when trying to create or read a record.
To fix that we are adding Validations for the Related Model field when it gets
updated from UI side.
sentry-3933471439
closesodoo/odoo#118052
X-original-commit: e4f7798fd5a5cccd5d385f535fbc21264cb6948b
Signed-off-by: Rémy Voet <ryv@odoo.com>
17c4f47b0a updated table_kind to return
`pg_class.relkind`, however the semantics are *not* the same, and that
was ignored: `relkind = t` is for *toast* tables, not *temporary*
tables. In `pg_class` the temporary-ness is instead signaled by
`relpersistence` (which applies to both tables and sequences), temp
(and unlogged) tables have `relkind = r`. `existing_tables` does that
correctly, possibly unwittingly.
While at it, upgrade `table_kind` to return an `enum` (whose value is
the old discriminant).
closesodoo/odoo#117444
Related: odoo/enterprise#39185
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
`res.currency` already has some utilitises like `round` or
`compare_amounts` but until now we always needed to import
`format_amount` from the tools in order to format.
This commit unifies the API.
X-original-commit: 3517a0fece96dd5d0deb02c9fd973444e748986b
Part-of: odoo/odoo#117964
Recent Odoo versions require modern postgres (e.g. use of jsonb), the
`NULLS {FIRST | LAST}` clause was added in 8.3 so should be well
supported.
While Odoo's use of nulls is not always consistent, the NULLS ordering
clauses can be quite useful especially when sorting `DESC`: `NULLS
FIRST` and `NULLS LAST` are literal positions so they put nulls at
that location regardless of sort order whereas the default Postgres
ordering is to consider nulls larger than every other value so they
appear first when sorting DESC, which is often undesirable (putting
nulls first when sorting ASC can also be useful to fill records).
Update `_generate_order_by_inner` to correctly process `NULLS` clauses:
- Use `regex_order` to ensure we parse orderings correctly and
consistently, also update `regex_order` to use named groups to make
the relevant bits clearer (and VERBOSE for readability).
- Given `a_id DESC` and `_fields[a_id].relation._order = 'xxx NULLS
LAST'`, reversing the clause should order by `xxx DESC NULLS FIRST`
to correctly flip the original as `NULLS` clauses are not relative
to the sorting order (they put the `NULL`-valued records at the
specified location regardless). Therefore apply `reverse_direction`
to `NULLS`.
- Manually expand `NULLS` clauses on m2o fields: propagating the
clause through the join would yield unexpected and illogical results
when mixing NULL m2o fields and non-NULL m2o fields with NULL
`_order` fields (as they would get mixed rather than clearly layered
/ separated).
However because SQL booleans are ordered the usual way (`true >
false`) the `NULLS` clause is fundamentally equivalent to sorting on
the field being NULL (if `NULLS LAST`) or not (if `NULLS FIRST`). So
we can prepend the expanded m2o's ordering with such a clause to get
the correct behavior.
Replaces #116464
Supersedes #116664closesodoo/odoo#117439
Signed-off-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Petar Najman <petar.najman@modoolar.com>
Remove an option used by the phone widget in the res_user view.
task - 3246848
closesodoo/odoo#117805
X-original-commit: a998437ed465f1a2a0aaee3651472ff8c58ba067
Related: odoo/enterprise#39387
Signed-off-by: Kevin Baptiste <kba@odoo.com>
Adding the if condition to handle starred argument passed to
cr.execute
Adding two test to test that case
closesodoo/odoo#117688
X-original-commit: 4ab64dcd21ecd99c081975beee5ac13d2aa70a6b
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>
Since saas 16.1, we added a more visible error information box when the
module system cannot find some dependencies, or if there is an error in
the JS code. This error box is very useful to understand a lot of
typical devlopment issues. However, it was occasionally displayed in
production code.
However, we sometimes observe that the error information box was
displayed, because the request to load an assets failed with a 404.
It is unclear in which circumstance this can happen, but it seems that
the following elements are involved:
- the user has an open tab with odoo, kept open for a while
- some js code is changed on the server, which causes the previous
assets to be deleted
- the user reload its open tabs, so the browser will load the /web page
from disk, which points to the old assets files
- then it will try to load all assets, with a 404 on one of the script
- the error information box is displayed
This commit intercepts the loading error and stop displaying the error
information box, which is basically the same behaviour as 16.0 and
before. We could force a reload in that case, but it seems dangerous,
since in case of errors, it could easily lead to an infinite loop.
closesodoo/odoo#117625
X-original-commit: 0a44b5b1e008b591a716efd26217c7db7360c37b
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before revision 5bf1207c8c
a new environment was created for each call
at `xml_import` or `convert_file`,
with `odoo.api.Environment(cr, SUPERUSER_ID, {})`
meaning the context was empty, meaning the lang was never set
Now that we pass from end to end the environment,
the caller of `xml_import` or `convert_file`
passes his own environment, therefore propagating
his `context` variables, therefore potentially passing
a lang in the context.
Therefore, since this change, the lang of the user
is taken into account when calling `xml_import`/`convert_file`,
and it updates the translation term rather than the source term
for translated fields.
This could be an actual/intended valid behavior,
this needs to be discussed,
but currently the places where `xml_import`/`convert_file`
is called expects to update the source term,
not the translated term.
See for reference
https://github.com/odoo/odoo/pull/116780#issuecomment-1486506663
Therefore, as this is an unexpected/unintended change of behavior
of the refactor 5bf1207c8c,
and as code blocks calling `xml_import`/`convert_file` have not
been adapted, we prefer to play it safe
and revert the behavior to what is was.
This is very possible other context keys will need to be dropped,
but one of the desired change of the refactor was to be
able to pass keys in the context, currently we prefer
to not wipe the environment context and just blacklist the one we
do not want to propagate, such as the lang.
If other related issues arise, we will then re-consider.
closesodoo/odoo#117621
X-original-commit: 44fa57e52fbc853b7756a96c73c94baa469c99ca
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
As we have a team dedicated to work on analysing tracebacks
with sentry, and to takedown all tracebacks occuring on the saas,
we do an effort to avoid unecessary warnings and tracebacks
for both sentry and the runbot.
closesodoo/odoo#112101
Signed-off-by: Rémy Voet <ryv@odoo.com>
This fixes an issue with an override of onchange() on account.asset,
which asks for less fields to be considered in the snapshot. This also
guarantees that onchange() does not return values for unexpected fields.
Part-of: odoo/odoo#116779
Before this commit:
in the --dev=xml mode, terms in ir_ui_view.arch cannot be correctly wrapped with
translation tags in the edit_translation=True context
After this commit:
The logic of get_trans_func is moved to _compute_arch of model ir.ui.view,
since ir_ui_view is its only use case and the hack
with_context (edit_translation=None)
makes the logic very confusing as a method for Fields.
task-3225622
X-original-commit: 05ebdce14227b767bbddeab38e31f1eb747d9887
Part-of: odoo/odoo#117256
Currently, the property fields of type integer and decimal does not
behave like the standard fields. There are the following issues:
1. The property fields of type integer and decimal do not fallback to
the value 0 or 0.0 when the field is emptied.
2. The user can not write the value 0 in the property field of type
integer and decimal. The value gets discarded whenever the user
unfocuses the input field.
This commit will fix those two issues and ensure that the property
fields have the same behavior as the standard fields.
task-3226202
closesodoo/odoo#117253
X-original-commit: 08c317743ba90802f471058a8f12d7211f9eb150
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When editing an action using the dev options, one may need to update the
action helper of the current action. Currently, the html field used to
edit the action helper does not have the "codeview" option. As a result,
the raw html of the action helper can not be edited easily. To solve
that problem, this commit will simply add the "codeview" option on the
html field.
task-3252414
closesodoo/odoo#117032
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
abd-msyukyu-odoo