* = account, calendar, im_livechat, mrp, project_todo, sms, snailmail,
test_mail, web, website_livechat
`contains` is more efficient than `afterNextRender` as it does not wait
for several extra animation frames, and it is functionally more
meaningful.
closesodoo/odoo#130451
Related: odoo/enterprise#44999
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
In this commit, all usages of env._t() are replaced by _t().
In templates files, env._t() didn't work because terms used
in attributes where not extracted into the translation files.
Only string are exported from .xml files to translation files.
So, to make it works, we set a variable that is then used
in attributes.
For example :
<t t-set="string_to_translate">String to translate</t>
<Dialog title="string_to_translate>...</Dialog>
task-3292454
closesodoo/odoo#131390
Related: odoo/enterprise#45631
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
As all the templates are now imported in the owl app, there is not need
anymore to specify the owl="1" attribute in the templates.
Part of task~3443861
Part-of: odoo/odoo#130467
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
'_sms_get_default_partners' exists in SMS to find default customers to
notify when sending automated SMS. It can be replaced by '_mail_get_partners'
helper available on BaseModel in mail.
A specific case exists in calendar where it was overridden to avoid notifying
attendees that declined the event, notably for alarms. This feature has been
moved directly in the reminder sending method, to keep behavior coherent.
Test is updated accordingly, and is now really using the SMS mocks to simulate
the sending.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Add a '_phone_format' tool method on BaseModel. It allows to format a number
either directly, either from a field available on the model. It allows to
ease number formatting. It uses available helpers to find numbers using
'_phone_get_number_fields' and '_phone_get_country_field'. With default
generic behavior this allows to simplify most calls to phone number formatting.
Having it available at BaseModel level allows to remove some custom code,
calls to phone_validation API, ...
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Simplify model custom code when dealing with phone and sms by using helpers
and standard behavior defined on all models.
'_sms_get_partner_fields' was introduced at odoo/odoo@bdebcab0ce to have a generic
implementation of finding partners on a record. Since then another version
has been added directly in 'mail' module, using '_mail_get_partners'.
'_sms_get_number_fields' was introduced at the same time to have a generic
implementation of finding numbers on a record. Since then a generic and
improved version has been added directly in 'phone_validation' module, see
'_phone_get_number_fields'.
Those method can therefore be removed, and replaced by the generic ones
available on BaseModel.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Prepares Task-36879 (Mail: Support MultiCompany Aliases)
Part-of: odoo/odoo#130468
RATIONALE
Simplify field management for mail / phone / sms flows. Make it working out
of the box, easier to use and tweak.
SPECIFICATIONS
Support by default 'phone' and 'mobile' fields if present on model as phone
fields to fetch when searching for a number. This allows to remove several
of unnecessary overrides always doing the same thing.
Task-3422449 (Mail, Phone: Move and improve field helpers)
Part-of: odoo/odoo#130468
In the commit [1], the patch has been refactored to support the
native keyword `super`. The current commit just adapts the codebase
to that change.
task 3410198
[1]: 19ea1ac08043e22a811630968e44715cc3bfc495
Part-of: odoo/odoo#125716
In a previous commit 8bfa76a, _lt() returns _t().
So, in this commit, all usages of _lt() are replaced by _t().
task-3292454
closesodoo/odoo#130179
Related: odoo/enterprise#44906
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Since the relational model was rewritten (PR 114024), it is now reactive,
so it is no longer necessary to use model.notify() to render the view.
closesodoo/odoo#130058
Related: odoo/enterprise#44781
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit fixes a really old grammar error in the help message of the
message_needaction_counter field.
Before this commit: “Number of messages which requires an action”
After: “Number of messages requiring action”
The subject of “require” is “messages”, which is third-person plural, so
it can't take the -s suffix.
closesodoo/odoo#129468
X-original-commit: 0d10cfeaa56d5df23df05f436d353978043f4a71
Related: odoo/enterprise#44509
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit makes hotkey uses more coherent throughout the entire
codebase by setting alt+q as main shortcurt for confirm and default
actions and alt+x for cancel actions.
task-3370463
closesodoo/odoo#127469
Related: odoo/enterprise#43694
Signed-off-by: Mathieu Duckerts-Antoine (dam) <dam@odoo.com>
*: mail
This commit fixes the href used by the PhoneField. Following the
specs of a phone uri, spaces must be removed from the phone number
when using the href attribute.
A test has been added to verify that any spaces are removed from
a given phone number.
In mail, the SMS button href has been edited for the same purpose.
task-3371999
closesodoo/odoo#128383
X-original-commit: 9ff0270c8acf9596ebd404627c4f5b1a98b37c59
Signed-off-by: Florent Dardenne (dafl) <dafl@odoo.com>
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
Steps to reproduce the bug:
- Install mass_mailing_sms module (for test purpose)
- Go to Contacts and open list view
- Select a contact and click on "Actions -> Send SMS Text Message"
- Write a message on multiple lines and click on "Send Now"
- Open partner form view
Issue:
The message is not displayed on multiple lines in the chatter.
Cause:
The message is converted to plain text while should be converted to
HTML for logging.
Solution:
Convert the message to HTML (like it is done when sending not in mass)
opw-3301577
closesodoo/odoo#127497
X-original-commit: 11503de934e272d1df615f1a79acd1b96954bbd3
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Steps to reproduce:
- Create a SMS template with the 'Applies to' property set to
Transfer (without this the action will never appear)
- Go to Transfer, pick one, open action and try to send a SMS
Issue:
Traceback
Cause:
When sending the SMS we try to modify the 'mobile' attribute of
'stock.picking' but it doesn't exist.
opw-3286153
X-original-commit: c84f952824bea4c1e0d5dcc7450d5e48a5637db8
Part-of: odoo/odoo#123716
Remove "fake" feature sub-folders that make files harder to find.
Note: If there are too many files in the main folder now, a new split
that actually makes sense can be done at a later time: this would not
just be code move, but removing coupling between said feature and the
rest of the code.
Apply consistent structure, where the top level folder is a feature (or
core), and sub-folders are subdivision of the feature depending on
context (closely related to assets bundles).
```
- core
- common
- public
- web
- feature
- common
- public
- web
```
The opportunity is taken to reorganize the top of the files and imports:
- Always use absolute path in imports to be able to find all usages of a
file with a single search.
- Reorganize imports to group them by module, and to sort them
alphabetically by path/feature.
- Always use single asterisk (*) for `odoo-module`: less characters yay!
And double asterisk should be used for JSDoc comments, not for custom
instructions.
Part of task-3265211
closesodoo/odoo#124168
Related: odoo/enterprise#42121
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Prior to this commit, the SVG's viewBox attribute was missing, which
prevented svgs from being scaled.
This commit fixes this issue.
task-3326633
Part of task-3326263
X-original-commit: 30300c373ad1c63a6cf8b035cae0785a09c6933f
Part-of: odoo/odoo#121886
*: mail, mass_mailing, sms, web_editor
This commit adds a new supportedOptions attribute that can be added to any
field widget metadata object. This documentation can be used from other places
(Studio for example) by getting the field from the registry and then read
this key. This attribute can contain an array, detailing the list of available
options for the field widget.
By using an array, it can be ordered easily without having an object with keys
unalphabetically. Ordering the options can make sense, especially when two
options are tied to each other, it is easier to group them one after the other.
(eg: 'start_date' first, then 'end_date')
Each option documented is an object and has the following attributes:
- help: contains more details on the current option and its use
- name: name used in the options object from the node
- label: a label with a more explicit name than the option name
- type: the type of value that must be used as a value (string, boolean, selection, field, domain)
- choices: for options with a 'selection': can be used to know available values
where multiple values can be chosen as the value. This must be
an array containing the options.
- availableTypes: for options with a 'field' selection: can be used to filter the
available fieldNames to choose as a value.
- default: the value that is used by default, when the option is not set
in the options
task-3259617
closesodoo/odoo#118713
Related: odoo/enterprise#39847
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@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>
Before this commit, the use of multiple <field> with the same name in a
view was not well supported.
Why was this?
Some Field components need to know information related to the <field>
such as context, domain, required and readonly. The solution used before
this commit to access this information is to use the getFieldContext,
getFieldDomain, isReadonly, isRequired functions of the model.
Unfortunately, these only take into account the last occurrence of the
<field> because the model is not aware that the same field is present
several times on the view. The information must therefore not come from
the model. For example, it was not possible to have the same field
twice with 2 different domains. It will use the domain of the last
field for both.
Solution:
We will add the object "dynamicInfo" to the fieldInfo passed to the Fields
extractProps function. This object will contain a getter to get the value
of required, readonly, domain and context for the current <field>.
If a Field needs one of its information, it will just have to get it
from extractProps.
Part of Task: 3179751
closesodoo/odoo#115197
Related: odoo/enterprise#38151
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We forget to remove few 'props.value' in 688986f888.
We should replace it by 'props.record.data[props.name]'.
closesodoo/odoo#114785
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
This commit, is part of a series of commits that aim to simplifie the
concrete fields API.
In this commit we will remove value prop from concrete fields. Now each
field will directly use this.props.record.data[this.props.name] to
access their value, As a consequence of this, the name props need to be
mandatory.
task-id 3179751
closesodoo/odoo#113495
Related: odoo/enterprise#37464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this change, when the recipient_single_description field was empty (the field is then false), the field box was still displayed before the number. Since the field is not editable there is just a blank space.
This PR hides the field when it is empty to avoid having the empty space.
closesodoo/odoo#114354
X-original-commit: a7425a2d829a7bfe0e25619a3bd5c40d9e112bb0
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>
This commit is part of the preliminary work to rewrite the form,
list and kanban model. We want this new Model to only be aware of
field related information it needs (whereas in its current
implementation, the model stores all the information extracted
from the field node in the arch). This would allow to properly
manage multiple occurrences of the same field in views, that is,
each occurrence would be represented by a field component (if
visible of course), and that field component would use the field
information of the arch node it represents. To this end, we want
fields from not using anymore information stored in activeFields
in the record datapoint. Instead, we now call extractProps with
the whole fieldInfo (the information extracted from the arch), s.t.
each field can generate the props it needs from those information
(e.g. sub views for x2manys).
This commit doesn't remove the use of record.activeFields in
concrete fields (this will come later), but reworks the fieldInfo
object generated by parseFieldNode, and provide it to the calls of
extractProps. In fieldInfo, the `options` key is no longer inside
`attrs`, as it is now top-level, alongside several other generic
keys that have been processed (like on_change, modifiers...). For
that reason, a lot of extractProps definitions had to be adapted.
Part of task 3179751
closesodoo/odoo#113092
Related: odoo/enterprise#37266
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
The goal of this revision is to re-use the environment among the
different steps of the registry loading,
instead of creating a new environment for each step.
1. Simply To avoid to repeat the line
`env = api.Environment(cr, SUPERUSER_ID, {})`
multiple times in the code
2. This also allows to share the context among the different
steps. This is not yet used in this revision, but it could
be, for instance to avoid the current repetition to add the keys
`install_module`, in `convert_csv_import` and `xml_import._tag_record`
Part-of: odoo/odoo#108254
Followup of odoo/odoo#95623 (introduce scheduled message notification) as well
as odoo/odoo#99482 (support scheduled datetime from template to composer in
both comment and mailing modes).
Task-3093257 (Mail: The Composer Update)
Part-of: odoo/odoo#107356
steps:
- Go to Rental app
- Open a rental Order
- Click on Action
- Send an SMS text message
- Fill phone number and message
- Sens SMS
Issue:
Traceback
Cause:
Sale order doesn't have a phone or mobile field so the sms.composer tries to write on it use "False"
Solution ensure the field name isn't false before writing
opw-3103232
closesodoo/odoo#110038
X-original-commit: 70a9995c9e02f36dc15d2723151ef0a205ebc12b
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Prior to this commit, the recipient in the SMS wizard
shows The name of the record.
In this commit, we make the partner the recipient instead
showing The name of the record itself.
task-3000243
closesodoo/odoo#110801
X-original-commit: 16e25edaf5c589046d42c62a2c32d337504d9e37
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Before this commit, clicking on a SendSMSButton in a FormViewDialog could
change the record of the main form view.
Problem:
When closing the dialog opened by the SendSMSButton, the model is reloaded
with the record id associated with the button. This has the effect of
replacing the root with this record. This will replace the record used
in the main form view by the one in the FormViewDialog.
How to reproduce:
- Go to a form view with an x2m field that has the same model as the form view
- Add a record in the x2m in order to open a FormViewDialog with at
least one field using the "phone" widget
- Complete the field with the "phone" widget
- Click on the "SMS" button
- Click on "Discard" button
Before this commit:
The dialog opened by SendSMSButton is closed and the main form view
record is replaced by the FormViewDialog record.
After this commit:
The dialog opened by SendSMSButton is closed and the record of the
main form view has not changed.
closesodoo/odoo#110527
Taskid: 3107429
X-original-commit: 9ceba129223a6368c720596ea17a3f7268487649
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Georis François (fge) <fge@odoo.com>
Purpose of this commit is to clearly check input of ``message_post`` method
and its main helpers in order to prevent wrong usage of message post API.
Some values used to populate message fields should not be set directly when
posting or logging messages. Indeed they may be part of other process (like
notification process managed by ``_notify_thread``, or could be setup by
custom routes like 'reaction_ids', or custom usage of 'model' and 'res_id'
that could conflicts with record on which methods are called).
We therefore add checks and cleanup in those methods to be sure the API
is used as intended and avoid unwanted side effects.
Task-2710804 (Mail: Clean MailThread Posting API)
Part-of: odoo/odoo#99482
**Issue:**
- Install crm (to have a form view with phone field).
- Click crm icon.
- Open list view.
- Create a new record.
- Enter title and phone number.
- Click sms button from the right of phone number field.
- On the wizard (dialog), enter a message and send.
- The wizard is closed but (BUG) the form view returns to the state where
a new record is being created.
**Solution:**
The record containing the new sms message is properly created, however
the form view is reloaded with undefined `resId`, thus the form reloaded
as if it is "new".
The simplest fix is to specify the `resId` of the newly created record in
the `model.load` call as proposed in this commit.
closesodoo/odoo#108431
X-original-commit: edaf37eeb9244976ecc6c60aec089f9a2b4e3020
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
CONTEXT:
emoji_char_field and emoji_text_field
previously used the emoji_dropdown component
along with some utility functions to display
a very limited number of emojis.
As discuss now has a feature-full emoji picker
we aim to take advantage of it by bootstrapping
the picker from the existing components,
using a new javascript model for the
insert/update logic
AFTER THE CHANGE:
Users should be able to select the same emojis
they can use in the discuss chat in all fields
that previously featured an emoji picker.
Such as the livechat bot responses,
social posts, mailing subjects and
the sms message composer.
RELATED CHANGES:
Some tests are updated to use the pyEnv testing
'framework', as we now need to have access to
the messaging service to test these fields.
emoji_mixin is modified to match any emoji
character. The mixin is consolidated into
a single function is actually called anymore.
The text to emoji dict from emojis.js is removed
as it is no longer relevant where it was used.
The fields that used the emoji_mixin will no longer
trigger onChange on inserting an emoji.
However both the input and keydown event are fired
to allow fields using onchange_on_keydown
to trigger the onchange.
The emoji button was turned into an actual button
replacing the original span used in these fields.
This required a different approach to styling as
buttons inherently behave differently than spans.
The button is now moved using an empty div next
to the input and absolute positioning.
Most of the code used for char and text emoji
fields is consolidated into emojis_field_common.
task-3035021
closesodoo/odoo#104799
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Previously, we had an option on char/text fields called "onchange_on_keydown",
which allowed to trigger the onchange while the user was typing (instead of
when the field is blurred).
It was notably used when typing a phone number in the sms composer, to warn
the user that the phone number is invalid.
This feature was lost during the port to OWL, this commit restores it.
Task-3033107
closesodoo/odoo#106193
X-original-commit: 54def8969d49d6e5284cd97ab8df75e08043cd4e
Related: odoo/enterprise#34211
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Remove the Dynamic Placeholder from the legacy Odoo field.
Introduce in 308f639e295fce07e4f34d6c76b35aab259e21ad
And migrate to be OWL compatible in #101768
Therefore the old code targeting legacy odoo field is unnecessary
and need to be cleaned.
task-3071417
closesodoo/odoo#105920
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Sébastien Theys