*: 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>
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, 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>
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
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>
**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>
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>
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>
**Issue:**
- Open crm.
- Open a lead.
- Input a number in the phone field.
- Click everywhere for the input to be recognized.
- Click the sms button that appears when hovering over the phone
field.
- BUG1: The shown dialog doesn't have the inputted phone number.
- BUG2: When closing the dialog, any changes made in the form
before clicking the sms button are lost.
**Solution:**
Make sure the changes are saved before calling the action that
shows the wizard.
After this fix:
- The phone number input in the form is now used in the
wizard.
- When closing the wizard, the "unsaved" changes are kept.
closesodoo/odoo#105862
Task-id: 3056454
X-original-commit: a1bc67d811cab58e6ab336c636a1b1d83fc64446
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Introduce the '@mail/model' module that gathers all the stuff involved
in model definitions. This allows us to reduce the number of imports.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website, website_livechat, website_slides
Task-3056971
Part-of: odoo/odoo#105096
This commit simplifies discuss template by putting record accessors
in the context of template.
*: calendar, hr_holidays, im_livechat, sms, snailmail,
website_livechat
Task-3055022
Part-of: odoo/odoo#105099
Model patches are now defined using the `registerPatch` function. This
function takes an object as argument which keys match those of a model
definition.
Benefits:
+ More consistent shape between model definitions and patch definitions
+ No need to import one function to each type of patch
+ No need to repeat the model name for each type of patch
+ No need to import the original definition
Task-2998282.
* = calendar, crm, hr, im_livechat, note, rating, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#101827
X-original-commit: 7d23491b44b7372209057ea2abc565a95710b316
Related: odoo/enterprise#32136
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
This commit brings back the Send SMS button, which was no longer
visible in form views since they are now displayed in edition by
default.
It also solves the missing enable_sms option, which was not yet
ported from the legacy implementation.
A test file has been added to the sms module to verify the presence
of the button in the view.
closesodoo/odoo#101786
X-original-commit: fdb38657904202d9bfa75817289a53596b914406
Related: odoo/enterprise#32108
Signed-off-by: Michaël Mattiello <mcm@odoo.com>
Signed-off-by: Luca Vitali <luvi@odoo.com>
This ports the `sms_widget` field to OWL.
closesodoo/odoo#101350
X-original-commit: 89109de6d3752388f0b2f976c8a32588f760ec48
Related: odoo/enterprise#31882
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This moves the emojis char and text fields to the new fields directory,
and renames them to follow the new naming conventions.
X-original-commit: 92488725a608a2e14297228ebccddc5cc2ee5d6d
Part-of: odoo/odoo#101350
Introduce a new Dynamic Placeholder Generator
in mass mailing and SMS creation.
Using a specific character (#) in subject or via the PowerBox in body
we open a field selector popup, which can be use to select
the wanted field and enter a default value. on validation, the dynamic
placeholder will be inserted in the corresponding input/editable.
task-2154624
closesodoo/odoo#71878
Related: odoo/enterprise#30333
Related: odoo/upgrade#3766
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The sms field extension had been badly converted.
The button didn't do anything cause the action wasn't properly
configured.
closesodoo/odoo#98646
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: sms, snailmail.
The createThreadViewComponent helper was used during tests to mount
a thread view component and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient so that the thread view
component can be mounted in its real environment.
task-2871066
closesodoo/odoo#94691
Related: odoo/enterprise#28954
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Emails could not be resent from the chatter after failing to be sent.
This was due to parts of code not being updated after a refactoring of OWL.
Multiple other instances of non-updated code are updated here.
Task-2887153
closesodoo/odoo#94529
X-original-commit: 8fbdb1b52b9051e92e4980d5af73460a46fe70da
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
* hr, im_livechat, mail, sms, snailmail, test_mail_full, website_livechat,
website_slides
PURPOSE:
Creating a record with no values has no sense but is sometimes useful during
tests.
The support should be dropped for `default` parameter in `create`.
SPECIFICATION:
All the occurrences of `create()` have been replaced by `create({})`.
Task-2869394
closesodoo/odoo#93917
Related: odoo/enterprise#28538
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: sms, snailmail, test_mail.
This PR helps reducing the noise in the one introducing the new environment in
the discuss app. Indeed, we won't rely on the bus anymore to listen to do actions,
we will instead use the action service. The diff is awfull because the indentation
has changed as well as the parameter names. Changing the indentation and the parameters
now will ease the review of the main task.
task-2582313
closesodoo/odoo#90581
Related: odoo/enterprise#26970
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
*: sms, snailmail, test_mail
This commit introduces models that define records being 1:1 map with components,
as a step to move further to having essentially all business code in models.
Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.
Task-2831082
closesodoo/odoo#90320
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: sms, snailmail.
In order to reduce the noise in the new discuss env PR, all the
messaging.device.isMobile occurences have been renamed to isSmall
in order to match the new env terminology.
task-2582313
closesodoo/odoo#89655
Related: odoo/enterprise#26597
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Skip the confirmation step when wanting to get rid of a notification
for emails, sms or letters that were not sent.
Technical:
- All 3 wizards to confirm the discarding of the notification have been removed
(the ones for mail, sms and letter) have been removed
- The method to discard notification has been centralized in MailThread
(notify_cancel_by_type in addons/mail/models/mail_thread.py)
- This centralization has been done as well on the client code as the same
server code is called whether it is a mail, a sms or a letter
(in addons/mail/static/src/models/notification_group/notification_group.js)
- Existing front and back test have been adapted
- A test of notify_cancel_by_type for mail has been added
(addons/test_mail/tests/test_mail_management.py)
- add missing author_id in mail_notification demo data
Task-2752190
closesodoo/odoo#84452
Related: odoo/upgrade#3246
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
*: hr_holidays, im_livechat, mail, mail_bot, sms, snailmail, test_mail,
website_livechat, website_slides.
Mail tests are currently relying on this during tests to make env, widget,
data available. We don't wan't to add magic keys to this anymore.
task-2792108
closesodoo/odoo#86559
Related: odoo/enterprise#25341
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Move model definition files from `models/thing/thing.js` to
`models/thing.js` and remove the now empty intermediate directory.
Task-2759582
* = calendar, crm_livechat, hr, im_livechat, mail_bot, sms, snailmail,
website_livechat, website_slides
closesodoo/odoo#86464
Related: odoo/enterprise#25291
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
*: calendar, hr, hr_holidays, im_livechat, mail, mail_bot, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the removal of beforeEach function in the
mail test suite. Cleanup was relying on beforeEach adding widgets,
components, unpatch method 'this'. We need to clean things up without
using either beforeEach or 'this'.
task-2792108
closesodoo/odoo#86526
Related: odoo/enterprise#25326
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Reorder smart buttons on the hr_employee to have them in the following order:
1. Documents
2. Holiday status
3. Time Off
4. Planning
5. Timesheets
6. Equipments
7. Cars
8. Contracts
9. Appraisal
10. Work Entries
11. Payroll
12. Attendance
13. Extra Hours
- Log in the chatter the name of the plan that has been started via the button "Launch Plan"
- When on mobile, open the Time Off Calendar in month view
- When sending a sms without any message, only display Message once in the invalid fields
- Avoid the sms-help info disappearing when clicking on it and there are characters in the body of the message
- Update the tooltip of phone number in the send sms wizard
- Avoid the employee name to be displayed on two lines on mobile if the name is too long. Reduce the font size instead
task-2735679
closesodoo/odoo#83745
Related: odoo/enterprise#23886
Signed-off-by: Kevin Baptiste <kba@odoo.com>
*: calendar, hr, hr_holidays, im_livechat, note, sms, snailmail,
website_livechat, website_slides.
This commit prepares the ground for the model definitions PR.
In order to reduce the noise, all mail module's beforeEach
functions will be made async.
task-2767820
closesodoo/odoo#84845
Related: odoo/enterprise#24489
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
