PURPOSE
Settings allow to change colors used in emails (primary and secondary colors).
Those are used for headers and buttons. They are currently shared with colors
used for base documents and reports layout: changing email colors change
documents colors, which is not expected nor clearly indicated.
SPECIFICATIONS
Split configuration: colors used in documents may differ from colors used in
emails. Duplicate color fields (primary and secondary). To ease setup when
updating documents colors, update mail colors accordingly. Inverse is not
true as we consider documents being the main configuration, and emails a
more fine-grain configuration.
Task-3346388
Part-of: odoo/odoo#123678
- Improve performances, as the ir.rule restricting private partners
visibility is also applied on res.users by inheritance, on each
prefetch.
- Solve the issue of partners set as followers on records (eg: application
form) and then made private, making them impossible to contact via the
chatter.
- Solve the multiple access issues when trying to access the bank
account, or the private address for non HR people like the accountants
forcing the usage of sudo in the business code.
TaskID: 3101400
THese are rarely intended for all users but often intended only for
employees.
account:
account.incoterms: only used within internal business models
account.journal.group: same as account.journal, add sudo in computed field
account_edi: need access to accounting objects
base_address_extended:
res.city: only employees should access address data
board: only employees uses this (old) module
crm:
crm.stage: internal users business object
hr_recruitment: employees can read
im_livechat: apply same as for the steps
l10n_ar: used on partner, not only invoices
l10n_ec: accessed only through account.move
l10n_latam: accessed on res.partner
mail:
publisher.warrenty.contract: no data, only static models
mail.channel: group_user has already his own rule
mail.group: group_user has already his own rule
mail.message.subtype: group_user has already his own rule
mail.message.all: remove, already has a portal and employee rule
partner_autocomplete: no interaction with public
project:
project.tags: only needed for project sharing
sale_management:
sale.order.option: same as sale.order
utm: employee already has write access
web_editor: test models that have nothing to do here
web_tour: only employees uses tours
website_sale:
product.ribbon: add sudo for access
base:
ir.default: only employees uses set (could probably be converted to group_system)
ir.ui.view.custom: same as ir.ui.view, add sudo when needed
report.*: portal users don't configure reports
res.users.log: create in sudo, no access needed (adapt test to use another model)
res.lang: still needed for public
closesodoo/odoo#118701
Related: odoo/enterprise#41285
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Currently, only stable releases see their translations updated. This has
resulted in master accumulating outdated stuff for years, which can be
confusing for users testing master on runbot.
This one-shot commit resynchronizes master translations based on the
content from 16.0 and removes empty PO files (i.e. no longer containing
translations).
closesodoo/odoo#121629
Related: odoo/enterprise#41171
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
*: account, crm, hr_recruitement, im_livechat, point_of_sale,
project, sale_management, website_sale
Purpose
=======
Now, the KPI are computed based on their `company_id` and not based
on the current company. If no company is set on the digest, we compute
it based on the current company.
The KPIs are computed based on their company. Most of the time, they
will all belong to the same company so we can improve the performance
by computing them in batch.
Task-2827996
See odoo/enterprise/pull/27658
Part-of: odoo/odoo#91945
As those are mainly demonstration data and heavily linked to some design
choices better force their update to avoid having badly designed tips.
Mose digest tips are updatable data, just some modules are still having
them as noupdate.
task-2717426
Part-of: odoo/odoo#89549
The digest currently includes a CSS variable for the company's
secondary color, but Outlook does not support it.
This commit replaces the CSS variable in the digest with the QWEB
variable. Apart from that, if the secondary colour of the company
is available, it sets it into the colour property header of the
"mass_mailing_kpi_link_trackers" in email marketing and revert the
changes in commit[1] because border-start/end is an invalid property in CSS.
commit[1] - odoo-dev@1fcd098#diff-faee7192e5f6cf07658d2ceae16380c4b5d54035ecfb9bb4848608db3f429c69L263
tast-2717426
Part-of: odoo/odoo#89549
With this PR, the `digest_data` template is changed, so many test cases fail.
This commit adapts the test cases by changing the `data-field` from `div` to
`table`.
task-2717426
Part-of: odoo/odoo#89549
With this PR, the `digest_data` template has been changed, so the `digest_tips`
is not compatible with the new changes.
This commit changes the `digest_tips` data to be compatible with the new changes.
Below are the modules affected:
- account
- crm
- digest
- hr_expense
- hr_timesheet
- im_livechat
- mrp
- project
- purchase
- sale_management
- stock
- website
task-2717426
Part-of: odoo/odoo#89549
igest emails are currently not always correctly displayed on several
email readers. Notably using Outlook feeling is quite bad. This is
notably due to the support of "div" tags in outlook that far from
being perfect. Outlook notably does not support margin nor padding in
div, as well as many "modern" CSS properties.
Digest layout is updated to fix its display. We therefore get back to a
more hardcoded table-based display. It gives a better and more robust
layout cross readers.
Note that this globally reverts odoo/odoo@fd8709515c that was probably a bad idea.
task-2717426
Part-of: odoo/odoo#89549
According to Wiktionary, French spacing is "the archaic practice (though
still current in French) of inserting a space around colons, semicolons,
question marks, and exclamation marks". This is not standard practice in
English and most languages of the world.
The purpose of this commit is to start purging the code from this typo,
as it may reflect poorly on the software for some people.
closesodoo/odoo#114533
Related: odoo/enterprise#37853
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The text and the image were overlapping in the digest tip about "Tip: Speed up
inventory operations with barcodes". This solves the problem.
Technical note: actually, the layout has been broken in 15.2 because the image
has been updated with another ratio (from that version the CDN is used instead
of an image on the server). To support more client and as it looks ok even on
small device even with the 2 columns (text-image), we have used a table for the
layout.
Task-3097167
closesodoo/odoo#111737
X-original-commit: 7b6c82f2bc0f0d3931d6bd7c571cf4854eb4bd86
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
* = digest, hw_posbox_homepage, im_livechat, mass_mailing, web_editor,
website, website_slides_forum
Since the migration of Bootstrap 5 [1], some CSS rules was automatically
converted (`border-left` and `border-right`) when it shouldn't be.
These conversions were made because the CSS rules was embedded in
HTML/XML code and the REGEX for the conversion had no protection for
these cases.
This commit restores the old correct value.
Ref:
[1] odoo/odoo@1fcd098af5closesodoo/odoo#110141
X-original-commit: 0cbf7c00ecc307fc725da345415647828e771bb4
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Signed-off-by: Romeo Fragomeli (rfr) <rfr@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Due to recent improvements (Jinja -> Qweb, safe rendering) rendering API
supports several ways of giving options to the rendering process. Those
have mainly two usage
* ``preserve_comments`` : keep comments in rendered HTML, used notably
in mass mailing or digest to keep browser-specific comments;
* ``post_process`` : perform a post processing on rendered HTML, used notably
to process local links and add tracking to shortened links;
All those are now given directly inside an optional ``options`` parameter
given to ``_render_field`` and its sub-method ``_render_template``.
They can also be defined as field level, using ``render_options`` field
parameter. Some fields are updated
* composer mixin body (which impacts all inheriting models, notably
mail composer, survey and elearning invite wizards as well as appraisal
and appraisal feedback): post processing is now always done by default.
It was already done manually in calls that can be simplified;
* mail template body_html: post processing is now always done by default. It
was already done manually in calls that can be simplified;
* mailing body_html and preview are now post processed by default. It was
already the case in testing wizard. Preview is updated to avoid post
processing of links, as it was before. Remaining use case is the sending
which uses the mail composer, therefore was already post processed;
Finally some 'compute_lang' are explicitly added in _render_field calls in
order to be explicit on what we want, instead of being unsure.
Task-2710804 (Mail: Clean MailThread API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#106072
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Changes the background color of the digest to follow the
company color theme the same way it has been done for
the email layout.
task-2944770
X-original-commit: 1e9db93967ee76e21dd95e7500339d1de6914fbd
Part-of: odoo/odoo#101730
Ease the way people can unsubscribe from a digest by adding information
to the email enabling a user agent to present a button to the user that
automate the unsubscription.
Technical notes:
To ease the way people can unsubscribe from a digest, we have followed the
advice of rfc8058 by adding the following header to the email:
- List-Unsubscribe: https_URL_to_unsubscribe
- List-Unsubscribe-Post: List-Unsubscribe=One-Click
The https_URL_to_unsubscribe
- must work with the POST method but not the GET. The GET version is disabled
to avoid unintended unsubscription that could be triggered by an anti-spam
accessing the URLs in the headers.
- must unsubscribe the user without any additional steps (one click)
- should contain an opaque identifier hard-to-forge to identify the list and
the user (our token fulfills that goal). The goal is to avoid that someone
could unregister someone else easily.
- must fulfill other conditions like no cookie, no redirection, ...
It requires also that List-Unsubscribe and List-Unsubscribe-Post be covered by
a DKIM signature.
Task-2800499
closesodoo/odoo#86934
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Before this Commit, while sending the digest emails, the tip description was
incorrect due to sanitizing. Some jinja was also badly converted into
inline qweb instead of regular qweb.
After this Commit, we have fixed the tip description field value. We do the
html_sanitize after rendering the QWEB template. So, we get the proper values
of conditions and aliases. Replacing jinja with qweb template, should use
<t t-out="variable"/> to print the dynamic value so, remove the inline_template
expression `{{` and `}}` and put the <t t-out="variable"/>.
Task-2704083
closesodoo/odoo#88937
X-original-commit: c08cdc39965df1941b12a98dc80a015673f502e0
Related: odoo/enterprise#26293
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose
=======
Pictures from the digest emails are currently stored on the database
itself, meaning that if the database expires (e.g. after trial expires) all
pictures from previously sent emails won't be visible.
This is an issue since digest tips are meant as a marketing tool to bring
people to Odoo after trying a database.
Digest pictures are now taken from Odoo's server
(https://download.odoocdn.com/digests) so that the pictures will still
be visible after the database has expired.
From this commit onwards, it should not be allowed to change a digest
picture with the same name (to display a gif of a newer version), since
all databases with previous versions would receive pictures of a version
that does not correspond to theirs.
This also means that everyone client's Odoo server will contain pictures
that are never used. This could be fixed if Odoo stored them somewhere
else and didn't make them dependent from the git repository.
Task-2372195
closesodoo/odoo#87343
X-original-commit: 35157677a2a63a2559a72aff21e62e23a3c671a2
Related: odoo/enterprise#25654
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Currently while sending a digest, if a company does not have an email
address set, the "From" field for the mail is blank and so trying to
send digest fails.
With this commit, if a company does not have an email address set, it
will fallback to logged in user's email address as a "From" value.
In most cases, it will be the Odoobot email address (if the digest is
sent with the CRON) but if the admin send manually the digest, we will
use the admin email address.
TaskID-2729780
closesodoo/odoo#86507
X-original-commit: b9f8b8c721cbe56ebec5e43f96e478107d0c30ff
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
For email design in the context of Microsoft Outlook, we want to keep
some magic Microsoft comments (Outlook conditional comment), which -
until this commit - were skipped by QWeb. These allow us to change the
rendering exclusively for Outlook so as to overcome some of its
limitations. This commit introduces a qweb rendering option
(`preserve_comments`) for when - like in mass mailing and digest - we
want to keep comments.
Part-of: odoo/odoo#80621
Purpose
=======
Give the user a more organized view of the digest KPIs in the backend and
improve global wording of digest sections and KPIs.
Specifications
==============
Reorganize order of KPIs in digest view. Fix some typos, move buttons in
list and form views.
Task-2582128
closesodoo/odoo#77507
Related: odoo/enterprise#21340
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Fix spelling mistake in unsubscribe actions now that unsubscribe with token
has been merged with odoo/odoo@0ac3de1 .
Task-2582128
Part-of: odoo/odoo#77507
Currently digest sending is toned down when being sent if subscribed users
did not connect since more than 3 days. It allows to avoid spamming people
not being active or present anymore.
This is currently limited to daily digests that are set to weekly. However
it may continues to send digests each week until the digest is de-activated.
In this commit we tone down the digest from daily to quarterly depending
on users activity. It is still based on overall activity and not individual
users to avoid complex computation on heavy digests. This will be done in
further cleaning of digests.
Task-2688856 (Digest tone down improvement)
X-original-commit: f916354baec5bb69511069a829ab1648a5ebaccd
Part-of: odoo/odoo#79877
Purpose of this commit is to ease usage of unsubscribe button for periodic
digests for non-admins. Users land on page that says "You have unsubscribed
from ..." and not on digest form view anymore.
It is done using a public route with a token, allowing to unsubscribe even
when being not logged, for example when receiving digest emails that are
unwanted.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onboarding and usage improvement)
X-original-commit: a4b98a82d04b398406958d82f466c09f6021a989
Part-of: odoo/odoo#79877
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Body is used in statistics as an additional content to digest layout. However
it is strangely located after Odoo mentions (Send by, ...). Currently link
trackers statistics are therefore at the end of the email. They belong to
the "core" section of the emails.
Task-2686586 (Repair mailing statistics email)
X-original-commit: c9a503eec9a40809b6a88d56f84c06a66ad6dbeb
Part-of: odoo/odoo#79877
Mailing statistics emails are build on digest layout. This layout contains a
reference to the digest unsubscribe mechanism, which obviously does not work
with mailing statistics emails as they currently have no opt-out mechanism.
This commit fixes that part of the template so that unsubscribe is displayed
only with digests.
Task-2582128 (Digest onboarding and usage improvement)
Task-2686586 (Repair mailing statistics email)
X-original-commit: febe4506cf14ba9308d85538515eb61c4638b18d
Part-of: odoo/odoo#79877
A wrongly-placed t-if prevented from displaying unsubscribe link (and the
"Sent by Odoo" sentence by the way, even if less annoying).
Task-2582128 (Digest onboarding and usage improvement)
X-original-commit: 669209b473d1e9581518033b74064fff7f677393
Part-of: odoo/odoo#79877
Purpose is to ensure behavior of digests and prepare future fixes and
improvements. Tone down and unsubscribe links are currently not tested.
This commit fixes that by adding relevant tests.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onbarding and usage improvement)
X-original-commit: f340859a3508ebb369b7116f64c81d8f03774e61
Part-of: odoo/odoo#79877
When there is an issue updating digest state (concurrent access, or some other
error that may happen), digest emails may be sent in loop. Indeed they are
currently sent in the same transaction that the one that updates digest state.
This means that emails may be sent even if digest update fails.
As we do not think timing is so important, we now use the email queue to send
digest emails. That way email creation is rollbacked and they are not sent
if digest update fails for some reason.
Tests are updated to take into account we now create outgoing mail.mail. Some
tests are also added about mail values and subscription, and cleaned in a more
general way.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onbarding and usage improvement)
X-original-commit: 96a14816cb48d9324482eec3de0ed3fccc0d7ecf
Part-of: odoo/odoo#79877
Currently subscribed field is not computed again if user_ids field value
changes on a digest. This has probably few consequences in current code
but better be sure this field is correctly updated in a given transaction.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onboarding and usage improvement)
X-original-commit: 3a7c1348750d0977a663e50be05bad9f2679f8ff
Part-of: odoo/odoo#79877
Purpose is to ease digest management and testing. Public methods still work
as before this commit, simply calling the private implementation. New private
methods allows to better manipulate subscribed users. Those will be used
notably as shortcuts in tests.
Task-2641394 (Digest emails sending improvement)
Task-2582128 (Digest onbarding and usage improvement)
X-original-commit: 3045c49f0e10bd50757fcbaa75f9aaad49a966ce
Part-of: odoo/odoo#79877
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
Purpose
=======
Purpose of this commit is to add a new group for the mail template designer.
Goal is to make roles clearer: managers edit templates, users use them. This
commit allow some designers / managers to make email template and to let
others users use those email templates.
Specifications
==============
When this feature is enabled in the Settings page, a new group is required to
modify email templates in a composer like wizard or to make dynamic content.
This allows to separate managers editing / composing templates from standard
users that use them.
If the current does not have this group, the email body will be in readonly
mode if he selected an email template. That way we force him to use the email
template that the manager made.
Technical
=========
New Group
---------
Only users in this group will be able to create / write email template or
to write Jinja code in the mail composer (including other fields like subject
in mailing).
By default, all internal users have this group. Mass mailing users also have
this group as writing mailings is about the same management level as writing
templates.
Mail Composer Mixin
-------------------
In comment mode, the template is rendered and then saved on the body field
so non-"Mail Template Editor" users can load email templates.
But in mass mode, the body of the template is saved and then rendered and
many things change the body (HTML sanitizer, web editor move inline CSS
properties, add / remove spaces...). So in this case, we can not know if
the user changed the body or not. That is why we put the body field in
readonly mode so, it is not modified by the web editor.
Jinja code detection
--------------------
To detect dynamic Jinja content, we compile the template, and we browse the
AST. If we do not have a single "Template Data" node, we assume that the
template is dynamic.
When we detect the template as static, we do not render it. That way we
avoid unnecessary rendering.
Code cleaning
-------------
Move Jinja import into tools so that it is outside of mail framework code.
Task-2187263
closesodoo/odoo#75840
Related: odoo/enterprise#20547
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Gorash