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.
Purpose
=======
External links in the data sometimes open in the same tab, the users loses times as he has to come back (and looses the context).
Specification
=============
Any external links in data (planners, settings) should open in new tabs.
Main idea of this commit is to simplify the various options of
ir.actions.server model. Purpose is to make it a simple tool to
execute some actions or python code. This has two main consequences
* create and update server actions are simplified to update only the
current record. Complex options can always be achieved by python code
instead of error-prone option building mechanism;
* condition of server actions is removed. If a condition is necessary it
can either be included in a code server action, or integrated in an
automated action;
This commit features :
* remove 'client_action' server action type. Indeed this can be achieved
with a code server action returning an action;
* remove 'condition' on ir_actions_server model. From now on conditions
and triggers are managed in server action code or using automated
or scheduled action;
* clean 'create and copy a record'. Create and link are the proposed
options. Copy of the record or of a selected record is removed. Link
is simplified by removing the parsed expression that allowed complex
path update. It is simpler to write code than write python-like
expression in char fields;
* remove 'use_write' options. It now simply updates a record;
* remove 'write_expression' as it is replaced by code actions;
* remove 'ref_object' not used anymore with the removal of "choose
a record";
* remove helper to build an expression not used anymore with the removal
of "write expression";
* remove object ID finder;
* removed template display when choosing an email template; just go
on the template if you want more details;
* refactor server action form view to reflect changes. It will be used
in future commits as base view for automated and scheduled actions;
* add 'sequence' in list view;
* add new 'usage' selection field allowing to distinguish which model
uses the server action. Indeed as server action will soon be used
in scheduled or automated actions having a clue about the usage
is always helpful;
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo and @rco-odoo
for reviewing.
Group-based channels automatically add people belonging to user groups to the
channel. If a member leaves the channel he will be automatically added back
by the channel automatic subscription. This generates unnecessary changes and
messages in the channel.
We now prevent people from leaving group-based channels. All group members
have to be channel members. Unsubscribe buttons are therefore removed for
those channels.
This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
When uninstalling a module followers stay in the database because there is no
real link between ir.model and followers. Adding a m2o ensure followers are
correctly removed when uninstalling a module.
res_model fields is kept as a stored related field. This allows to keep
compatibility with almost all code using / searching on followers. Only
followers creation is changed a bit. As follower creation is done mainly
through a dedicated method few changes are required. Yey. Mat should be
happier now.
fix test
Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:
- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
translated
The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).
Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).
This commit correct all the external ids tagged as from base or other incorrect
modules.
When a user is assigned to a model on a user_id field an email is sent to him
containing a link to the document. This way the user is warned he is now
responsible of the task / issue / lead / ...
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
Purpose:
There are too many apps when someone starts to use odoo.
The user installs an app and see at least 6 menus -> too much !
Specification:
In mail module move contacts menu into new module 'contacts' to avoid this
useless app for new users but that can be useful afterward
PURPOSE:
The source document should be in the chatter and clickable
NEW MAIL TEMPLATE:
mail: new template 'message_origin_link' with clickable link to origin
Variables to pass:
- origin: the record from which the current record had been created
- self: The current record
Optional:
- edit: If true, the record has been modified. Otherwise it has been created
from the origin
SPECIFICATION:
Source Document is available in following models
1) After creating SO then Sale to Invoice -> Source Document (After creating Sales Order and then clicking on Create invoice)
2) When procurement is created after SO or MO or Order Point(procurement.order) - > Source Document
3) Stock.picking -> Source Document ( After Creating SO or PO)
4) When Manufacturing Order is Created (mrp.production) -> Source Document (Coming after creating a sale order of product)
5) Event -> Attendees(event.registration) -> Source Document
6) Request For Quotation -> Source Document (After creating Purchase Tender, SO)
7) In Purchase Tender(purchase.requisition) -> Source Document (When a new Purchase Tender is Created)
8) After creating PO then create invoice(vendor bill)-> Source Document
9) After creating Invoice from contract (subscription) - > source Document.
10) Refund invoice from Invoice --> Source Document.
11) Return picking from picking --> Source Document.
12) sale use POS to create invoice and picking --> Source Document.
MESSAGES TO DISPLAY:
-In Customer Invoice, there is a source document of Sale Order.
"This Invoice has been created from Sale Order(s): SO001, SO002"
-In Procurement, the source document can be either of Sale Order or Manufacturing Order or Order Point.
"This procurement is created from: SO001 or MO0001 or OP/0001"
-In Stock Picking, the source document can be either of Sale Order or Purchase Order.
"This transfer has been created from sales order(s): SO001 or PO0001"
-Create new Sales order of manufactured product , there will be Source Document with that Sale Order number
"This production has been created from procurement(s): WH: Stock -> CustomersMTO"
-When registering for Event from website, Sale Order is Created and it is stored in Source Document,
"The attendee has been created from Sale order: SO001"
-In RFQ, the source document can be either Purchase Tender or Sale Order or Order Point,
"This purchase order has been created from purchase requisition(s): TE0001 or SO001 or OP/0001"
-In Purchase Tender, the source document can be either of Sale Order/ Manufacturing Order/ Order Point.
"This Purchase Requisition has been created from: WH: Stock -> CustomersMTO"
-In Vendor bill, there is a source document of Purchase Order.
"This Vendor bill has been created from Purchase Order(s): PO0001, PO002"
-When creating refund of invoice
"This customer invoices refund has been created from customer invoices: INV/2016/0001"
-when create invoice and picking form pos.
"This invoce has been create from point of sale: MainXX"
- extended_chat_window feature in its own files: as it is only available in the
backend, we don't want it in the frontend assets (which contain the 'basic'
chat_window)
- move followers feature in its own files
- creation of the 'mail.utils' module in utils.js
- creation of systray.less to define the style of the mail item and dropdown
in the navbar
- use of chat_manager's search_partner function in PartnerInviteDialog
- some code linting
While this is important to read the replies
you get in the threads you follow, `Unread messages`
is more accurate to describe what these filters
displays.
opw-666739
Add the message_bounce field on res.partner. This allows bounced emails to increment
the counter and thus to filter / exclude / archive partners whose email is invalid.
Siddharth Gajjar