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>
HTML phrasing elements (like `<a>`, `<b>`, etc.) should be included in
translations. This avoids splitting phrases when translating HTML content.
Note that elements with qweb-related attributes (t-*) are not translated
inline.
Add tests on xml_translate().
Using `field.translate(callback, value)` returns the translation of the given
field value by using the function `callback` to translate simple terms in
`value`. In practice, the function `callback` uses a translation mapping
retrieved from `ir.translation`.
* add missing columns in base.sql
* add missing fields 'help', 'readonly', 'required', 'selectable' in reflection
* add field 'help' in `ir.model.fields` views
* do not patch registry with translated field string and help upon `ir.model.fields` update
* add the necessary fields in `ir.model.fields`
* when loading translations, convert types 'field', 'help' into 'model'
* add specific methods to retrieve translations of field string and help
qdp-odoo