- removed message_summary, a field that computes html containing the number
of unread messages. This field was used only in kanban views. Probably that
in earlier versions of the kanban view this field had a use; however now
we can directly use a counter and use it in the kanban templates.
- message_unread_counter is added, a counter of unread messages computed
in the same time as message_unread. It is now used in kanban views.
Views of several addons have been updated.
for channel-related stuff. mail.channel views as well as timeline views
and actions have been renamed. Now the names follow the guidelines and
will be used in the upcoming refactoring of mail and chat.
model has been renamed to mail.channel to prepare the slack modeling.
In future commits the mail.group model will be merged with the channel
model from im_chat. The first move is to rename mail.group into
mail.channel to have a model that will unite both features.
renamed to mail.channel.
At this point no model has been renamed; only files have been moved.
n mail, mail_group files have been renamed to mail_channel. The
website_mail_group addon has been renamed to website_mail_channel.
Some internal references have been updated (templates, linked files).
to define custom light workflows on opportunities.
Activities are linked to mail.message.subtype through inheritance.
This means that the follow mechanism works for activities. When
an activity is done, a message with the matching subtype is posted
on the opportunity.
Activities are internal by default. They are only visible by
employees.
A shortcut in the 'log a note' chatter option allows to post a
note linked to an activity (subtype).
Adds the option clear so that, if set to false, only some elements of the
control panel can be updated while keeping the other ones unchanged.
The breadcrumbs can then be updated by simply calling update_control_panel(),
instead of triggering a specific event to do it.
A bit of documentation and refactoring as well, mainly for the
breadcrumbs to be handled as other control panel's elements.
In edit mode, if this field is readonly and empty, its main div has
height 0 but its border is displayed. This rev. simply hides the field
in this case.
Make XML/HTML fields translatable like views
Add support for translating fields not as a whole, but as a value containing terms to translate:
- for such fields, the table `ir_translation` contains a set of (term, translation) for each record;
- use this support for the `arch` field of views, and convert translations of type 'view' into those;
- add "fuzzy" remapping of translations when English value of such a field is updated.
Convert translation types 'field', 'help' into corresponding translated fields of `ir.model.fields`.
Note: We do not translate `<a>` elements inline. Translating `<a>` elements is
triggering issues in the website editor tool: menu items are screwed up. The
menu items are handled by bootstrap, which expects menu items to be `<a>`
elements inside `<li>` inside `<ul>` elements. The introduction of a `<span>`
in the middle of this hierarchy breaks its functionality. Therefore we decided
to not translate `<a>` elements inline.
When invoking `read()` with `'website_editor`' in the context, missing
translations are automatically created, so that translated terms are always
wrapped as `<span data-oe-translation-id="...">...</span>`.
In view inheritance, selecting an element based on the attribute `string` is
broken, since this attribute may be translated before the inheritance is
applied. This fixes existing views to avoid such selections.
Also add constraint to prevent using translated attributes in view inheritance.
You may no longer select elements based on attributes 'string', 'help', etc:
<page string="Stuff" position="inside">...</page>
<xpath expr="//page[@string='Stuff']" position="inside">...</xpath>
Thibault Delavallée