We would like to make the "no item found" screens more appealing.
Before this commit, it shows a small help tip in the top-left
corner of the screen, just below the "Create" button.
With this commit, these help tips have been replaced by onboarding
screens, which consist of a picture and some text below, both of which
are horizontally centered.
The texts have been slightly changed, so that they are shorter and clearer.
Considered modules:
(A)
account,
account_asset,
account_budget,
account_test,
account_voucher,
analytic
(B)
barcodes,
base,
base_automation,
board
(C)
calendar,
contacts,
crm
(D)
delivery
(E)
event
(F)
fleet
(G)
gamification,
google_drive
(H)
hr,
hr_attendance,
hr_contract,
hr_expense,
hr_gamification,
hr_holidays,
hr_payroll,
hr_recruitment,
hr_timesheet
(I)
im_livechat
(L)
l10n_fr_sale_closing,
link_tracker,
lunch
(M)
mail,
maintenance,
mass_mailing,
membership,
mrp
(N)
note
(P)
payment,
point_of_sale,
post_mercury,
pos_restaurant,
product,
project,
purchase,
purchase_requisition
(R)
rating,
repair,
resource
(S)
sale,
sale_timesheet,
sales_team,
stock,
stock_account,
stock_landed_costs,
stock_picking_batch,
survey
(U)
utm
(W)
web,
website,
website_blog,
website_customer,
website_event_track,
website_forum,
website_quote,
website_sale,
website_sale_digital,
website_slides
Those fields are prefixed by default_ which now strictly means they
should be linked to a default value for a given model. Their name
is updated so that it does not conflict with the strict verification
done recently for settings.
This test couldn't be executed within the classic JS web suite,
because it relies on mobile specific files that are rejected in
desktop. Now that a second web suite (for mobile) has been
introduced (see 9bc500948), we can activate this test.
First purpose of this commit is to limit access on activity types.
Employees can now only read activity types. Indeed defining or modifying
activity types should not be done by employees as it impacts daily work
of all other employees. Specific app-based rights are added for project
and sale managers. Those have a specific menu to configure activity
types, meaning they should also have the access rights to do so.
Also including :
* ease default computation for res_model_id of activity types: using
default_res_model in context it is possible to specify a default
res_model_id. It is useful for example to give a specific context
in configuration menus;
* add a domain on res_model_id field in order to limit it to models
inheriting from mail.thread and not being transient;
* various improvement in activity type form view to ease configuration
notably the # days renamed to planned in;
Purpose
=======
Users often log an activity and want to schedule another one immediatly.
We should limit the number of clicks
Specification
=============
- Mark as done should be a secondary button
- Add a new secondary button : DONE AND SCHEDULE NEXT
- It should mark the activity as done and close the modal
- It should open a new activity modal
Behavior and available options are now the same in the Chatter modal and
the wizard itself. It implies correcting the crm_tour flow
The rev. odoo/odoo@ab900bb fixes an issue in mail which needed an include
on BasicModel and FormController. As this rev. has been done in a stable
branch, the includes have been done in an existing file.
This rev. correctly separates the includes in different files.
Purpose
=======
The attribute name isn't required on the <filter> tag. If not set, it can't be selected with a xpath and it can't be overwritten.
A lot of PR are coming from the community just to add a name on a filter because:
- It can't be selected with a xpath.
- It can't be used with `default_search_foo` on an action context.
Specification
=============
Make the atttribute name required
- Extract mobile specific code for the client action to a specific
file
- Massive clean of less rules
- Unify channels preview of the systray dropdown and the mobile UI
of Discuss
- Ensure to only load the last message of each channel in mobile,
as this is not used in desktop (unless the user opens the systray
menu)
- Make livechat available in Discuss mobile UI
- Brand new UI for Discuss client action (with tabs for Inbox,
chats, channels...)
- In mobile, conversations always open in Chat Windows
- Chat window UI improved (both mobile and desktop)
- Channels preview (used in the systray menu, and now in the mobile
UI of Discuss) improved
- Other minor less tweaks
This commit improves the use of mail activities by allowing their
integration with the calendar. Activity types now have a category
field that can be used to trigger some specific behavior. First
specific behavior is to have activity types of meeting category.
Creating activities of this type trigger a jump to the calendar to
schedule the meeting. Meeting activities and calender events are
linked to be able to easily navigate through the document, its activities
and its meetings.
Configuration is done using a category on activity types instead of some
hardcoded "meeting" activity to avoid issues with master data and to be
able to choose which activity type should trigger this behavior.
As of saas-16 and the new web client views, the "display value" for a
record's ID is now formatted with thousand separators.
This breaks a few kanban views where the ID was inserted into a
dynamic URL. Using `raw_value` is correct too and fixes the problem.
Note: This might affect other kanban views using integer field values,
but a quick search did not yield anything. Many2One fields already had
different "display values", so `raw_value` is already used when needed.
Other integer fields, such as computed counts and sums are often
displayed but not inserted into URLs or technical values where
the problem would occur.
Since the new views, `record.id.value` contains the formatted value of
the ID, meaning it can contain separators. For example, by default,
`1234 => 1,234`. Since this value is used in the image URL, using
`value` won't work anymore.
This commit improves the use of activities through various applications
by adding a counter of activities displaying next activities grouped by
application. For each application activities are divided into late, today
and future activities in order to achieve a better management.
This commit also merges Inbox and Messaging icons in topbar to keep only
one displaying All / Chat / Channels messages.
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
When a journal entry is created automatically from an invoice
validation, that logs an internal note with the text
"This account entry has been created from:". There should be
a clickable invoice's reference after but there was only an empty space.
The problem come from the method that call the template
"message_origin_link" with the selected invoices as arguments.
The template use the attributes id, _name and name. But for the
invoice object we want to use the number attribute instead of
name. The name of an invoice is empty by default and thus is
rendered as a blank in the template.
This commit modify the template and use the property display_name
instead of name. "display_name" use the number for the invoice and
is still correct for other object.
The invoice name is just a reference and is not required, so if you
use the field name of the invoice it can return an empty string.
The name_get method returns the invoice id + invoice number and
eventualy the invoice name.
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.
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
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.
Otherwise by default their alias are public. This makes no sense for
private groups to have by default public aliases.
Field is set as invisible on the view because it makes sense to configure
only the channel and not details of its alias. Anyway it is always
possible to tweak the alias configuration under Technical menu.
Using a m2m to partners does not allow a real management of members
because it allows to create partners, and require access rights on
partner model. Instead it now uses the o2m to channel members
allowing creation, update and removal of members without having
to work on partner records.
Currently tweaking or defining new activity types is difficult to achieve
as menu is hidden under technical settings. This commit eases the activity
types configuration by adding a menu allowing to customize them directly
under Emails section of General Settings. By the way it is renamed to
Discuss to better reflect its purpose.
This is an improvement but considered as an usability fix, therefore
targeting a stable version.
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.
The boolean field `is_mail_thread` on `ir.model` allows to create custom models
that inherit from model `mail.thread`. The selection field `track_visibility`
on `ir.model.fields` allows to add tracking on custom fields.
Also change the order on model `ir.model` to make mail thread models appear first.
This merge changes the way odoo handles notifications. Previously
notifications were sent to the odoo inbox and forwarded by email
depending on a parameter on the partner. Now users choose whether to
use odoo inbox or email but not both. Customers only work using
emails from now on.
This merge also features side commits linked to notifications and mail
like making mail tests less dependent on channels, the removal of auto
read in channels, limitation of assigned emails and project subscription
improvements.
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.
Christophe Simonis