Before this rev., if concurrent calls to 'read_follower' were
performed, it might happen that the read followers appearead twice
in the follower dropdown.
This was for example the case when validating an invoice: the
customer was listed twice as follower.
Note: in this particular case, the record shouldn't be reloaded
twice: this is another bug to adress.
Critical improvement,
`:)` was making a laughing guy that could be considered as mockery.
This smiley is way more friendly and should improve support feedback by at
least an order of magnitude better, maybe two.
Closes#16672
When the user changes the filters in the search view, this one
triggers up an event to notify its environment that its state
changed. This came with the new views, as before the search view
triggered an event on itself (i.e. used 'trigger' instead of
'trigger_up'). At some point, 'trigger' will be deprecated and
'trigger_up' will be used instead, everywhere.
The code in mail hasn't been updated accordingly, so the thread
wasn't updated when the user changed the filters.
When a user opens a record in a form view, the chatter is
displayed. Then, if he clicks on 'Create', the chatter is removed
from the DOM (there is no chatter in create mode). After saving
the newly created record, the chatter is displayed again, but the
same widget's instance is kept.
However, when being removed from the DOM, the event handlers bound
on elements of the chatter (e.g. 'New Message', 'Log a Note'...
buttons) are automatically unbound.
So before this rev., the buttons didn't work anymore once the form
view had switched to create mode. In this commit, we detach the
chatter's $el before updating the view, so that its handlers aren't
unbound when the old content is replaced by the new one.
Activities now have recommended next activities. Based on next activities
configured on activity types, it allows to implement light workflows
using next activities feature.
This feature was removed when refactoring crm activities to generic
activities. People asking to remove it were visibly wrong and it is
now implemented back as it was in v10.
Indeed when having a lot of available channels searchbox is displayed
quite low in the screen. This is annoying. This commit improves that
behavior by putting the searchbox above channels.
* account, mail, sale
Since the views refactoring, modifiers were not properly handled
anymore (readonly/required not recomputed, use of readonly/required
of "python field" instead of "view field", ...). This commit tries to
implement a system which allows to handle the modifiers (re)computation
the same way for all the basic views.
For this to work, many specialized renderers behaviors have been moved
to the basic renderer so that more mechanisms are shared (especially by
the form renderer and the list editable renderer). The list editable
renderer is hugely impacted by this commit.
Here is a list of key changes:
- The basic renderer now has a `_renderFieldWidget` function which is
used without modification by the form and the list renderers.
- Modifiers have to be registered thanks to the basic renderer
`_registerModifiersData` function (this is done automatically for
fields by the `_renderFieldWidget` function for example).
- All instantiated widgets are accessible, organized by record, and
ordered in a special basic renderer variable.
- The code which resets the widgets of the form view and the code
which updates the row of a list editable view is now shared in the
basic renderer and now also automatically updates the DOM according
to the reevaluated modifiers.
- The last point has an huge impact on list editable renderer: all the
widgets have to be instantiated when editing a row (even readonly and
invisible ones) as they can be switched to editable/visible during
edition (after a modifiers update).
- `replace_element` and `readonly` options of `AbstractField` are
useless: widgets are now always replacing the list editable cells
in edition and the `readonly` widget mechanism is replaced by the
notion of 'focusable' widgets.
(see `AbstractField.getFocusableElement`)
- The 'tab' navigation mechanism is impacted by the previous point,
some code sharing have been done in basic renderer for this too.
- `AbstractField` does not care anymore of the 'required' status, this
is the view responsability to check that a required field has a set
value on save.
- Some list editable bug fixing (e.g. it was possible to edit multiple
rows at the same time, it was not possible to navigate towards the
previous field, crash on o2m add an item click, ...)
- The mockserver now properly simulates server modifiers computation.
- ...
Note: list editable style may be worse than before this commit but a
CSS update is coming in a few days.
A record of the basic model may need to be displayed in different
views (e.g. a o2m record is displayed in the, e.g., Kanban view
inside the main form view, and if clicked, it is also displayed
in the form view opened in a dialog). However, the fields present
in those views may differ.
The previous implementation of fieldsInfo in the record didn't
handle that, as it was a dict whose keys were field names. With
this commit, the fieldsInfo is dict whose keys are view types, and
the values are dicts whose keys are field names (the fields of
the corresponding views, with they attrs in the view).
This allows to create multiple o2m records in a row in a form view.
The RPC system was not completely satisfactory, we decided to prepare
the future and do it properly. This commit introduces the new rpc
system, which replace the previous new one. We now simply have a
method, this._rpc, which takes a dictionary of parameters. The idea is
that depending on the parameters, it is able to add correct default
value when necessary.
For situations where we don't have the this._rpc method, we can use the
rpc.query method, which takes the same arguments, but directly calls
ajax.rpc instead of triggering up some events.
* Data manager load_view returns a viewInfo object
* ViewInfo contains: the arch, fields and fieldsInfo objects, and some extra informations
* The fields come from the server and are frozen, without any view attributes (depend of the model).
* The fieldsInfo contains every view attributes and informations.
Before this commit, the AbstractField specialization to use to
instantiate a field was determined in the renderers. Now this is
regrouped in BasicView.
Note: renderers are still left free to not use the determined
Class (like Kanban and not editable List which instantiate widgets
only if the "widget" attribute is present).
Field options do not depend on any context/data. They can so be
"computed" once and for all in the BasicView implementation instead
of in the AbstractField's one.
Also, remove the flag __always_reload and leave it be in the
options object (always_reload).
This commit tries to refactore the management of contexts and domains
in the webclient.
- Get rid of CompoundDomain: use standard array manipulation to
join multiple domains or use the Domain class (to be improved)
- Get rid of data.js build_domain and build_context methods
- Link this.record to the data point from the basic model for all
fields (not only relational fields)
- Add a getContext and a getDomain function to the basic model
data point (localData element) so that AbstractField implementations
can use them thanks to their this.record element.
- Remove the autocontext binding for field RPCs (see FieldManagerMixin)
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
This icon allows to control what types of notifications you want to receive.
That an icon typically used for "notifications" is better than an icon
typically used for "reminders" and "alarms". There is the risk of a wrong
expectation because reminders and alarms have a notion of time associated to
them: reminders in the future or alarms in the future at a given time. In the
case of a follow, there is no "future time" concept, whereas there is a
notification concept. It makes even more sense when we look at the placement of
this icon on the right side of the label "Following".
Closes#16170
The many2many_tags_email's internal value change logic fails to process
all its values. It is not concurrency proof either.
The internal value change logic is now replaced by a mutex and deferreds
are used for the partner's form view popups in order to allow concurrent
events.
When setting an activity as done in chatter users now have the possibility
to add a feedback. This feedback is added in the generated message that
already contains the activity name and note.
Moreover users now can also immediately schedule a next activity. This is
very useful for chained activities and speeds up activities use.
- On a model, log a note and ping User A
- Go in the inbox of User A, and reply to the message
The reply is a comment (therefore sent to all followers of the
document), not a note.
opw-710326
The former URL took way too many steps to resolve
`www.odoo.com(odoo-odoo-odoo)`, more than 1 minute
according to the case, and it stucked the web client
(the entire browser actually),
and it ended matching the whole sentence as a link,
included `(odoo-odoo-odoo)`
This new regex is much simpler, resolve the above case,
and does not match `odoo-odoo-odoo` as part of the link
opw-715797
Currently when scheduling activities, duplicate logs are created. Indeed
a message is posted when scheduling an activity, editing it and marking it
as done. This leads to a lot of noise being created on records.
This commit remove logs when scheduling and updating an activity. A sole
message is posted when the activity is marked as done.
Scheduled activity display in chatter is also improved to better
differentiate the user creating the activity from the user who is
assigned to the activity.
Currently using channels and inbox notifications is impossible because
browsing a channel marks all related notifications as done. If an user
has a lot of pending notifications, he cannot go on a channel linked to
documents he is working on. Indeed in that case he looses all notifications.
Auto-read of notifications is therefore removed. The only way of managing
notifications when working by inbox is either in the inbox menu or either
on documents, as reading a document marks related notification as done.
Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
When a message is not part of any channel, the message counter is
incremented while the message won't appear in any channel. This leads to
an inconsistency between the number of messages displayed in the status
bar and the actual messages in Discuss.
opw-706884
- Install a language other than English, set it to your user.
- On any model, send a message (the recipient should be a user, not a
simple portal user).
- The recipient receives a notification with a primary button half
translated, for example "Vue Task".
When the call is performed to method `message_post`, the sessioon
context is not added to the RPC request. Therefore, when the model name
is read (method `_message_notification_recipients`), it is done in the
default language.
Note that this is the case for any RPC request using the `call` JS
function.
opw-707678
Former implementation tried to retrieve the model in the 'model' and
'res_model' attributes of the widget, but both of them were undefined.
The model being required for some of the RPCs performed by the widget,
there were bugs (e.g. the messages weren't refreshed after the creation
of a new activity).
Fabien Pinckaers