Purpose
=======
Change the logic of the KPI "Day-1" to "Last 24 hours", so new freshly
created data in the free trial are included in the statistics (same for
last week and last month logic). This requires to change from date-based
computation to datetime-based.
Change the URL of the "connect" button from "/web/login" to the root
URL (so the user is not stuck if he didn't activate yet his database).
Task ID-2359406
closesodoo/odoo#60166
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit fixes several issues
* there are still some jinja references although the template is now done
in QWeb;
* put preferences content inside the same paragraph to avoid unnecessary
blank spaces;
* fix hardcoded company name (olé);
Followup of fd8709515c
Task ID-2338930
closesodoo/odoo#58577
X-original-commit: fd838a3d87f5bd326921dd15c2a41c3d1d3dd131
Related: odoo/enterprise#13591
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Used in external tools.
LINKS
Task ID-2274264
COM PR: odoo/odoo#53580
ENT PR: odoo/enterprise#1139
X-original-commit: 6e2a50c06beae8433753f49f0acf07fdede3b7fc
PURPOSE
Review the tips and digest layout design to make sure they have a WOW effect
and increase trial conversion/retention.
SPECIFICATIONS: LAYOUT
Besides changing the tips, a cleaning of digest layout was performed. Emails
were reported to look not neat in Outlook and somewhat random in mail.com or
gmail.com.
Most recent HTML CSS cannot be used to make HTML emails because each email
provider renders emails its own way. This means a given email may renders
differently in gmail.com and outlook.
The layout of the email was composed of several levels of embedded tables
which means huge maintenance effort. So it was totally rewritten with divs
and CSS, but some properties are not taken into account.
A lot of page component improvements were done. It consisted in replacing most
of the style attribute in tags with CSS classes and ids. This step is
especially useful for tip formatting because before, if a style modification
was needed, it had to be performed on each tip individually.
SPECIFICATIONS: TIPS
“Speed up your workflow with shortcuts”
“Click on an avatar to chat with a user”
“A calculator in Odoo”
“How to ping users in internal notes?”
“Knowledge is power”
LINKS
Task ID-2274264
COM PR: odoo/odoo#53580
ENT PR: odoo/enterprise#1139
X-original-commit: 04aa36da30c107e482935b1673374c9302e4cf6a
Spotted when working on event fixes.
Task ID 2244487
PR odoo/odoo#52998
FwdPort of odoo/odoo#52923
X-original-commit: f5440420b07baf32e9a6b9f84fead4f140fb921a
Purpose
=======
Provide a follow-up/overview of the Mailing 24 hours after its been sent.
Specifications
==============
Send an email to the responsible of the mailing 24 hours the last email
of the mass mailing.
During the link trackers creation, extract the button label if exists
(so we can display them in the statistics email).
Technical remarks
=================
The statistics email is sent to the responsible of each mailing in the
CRON of mass mailing.
Task-2227411
closesodoo/odoo#49836
Related: odoo/upgrade#1094
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Digest now use qweb views instead of a standard mail.template record for
rendering as
* template is very custom;
* probability of breaking it while edition the mail template is high;
it is easier to maintain and extend in qweb;
* only body was really used, other mail-related fields were not used;
We therefore remove the mail template data and the field used for it on
the digest model. Template is now forced to a Qweb view.
We can also remove the template_id field. Indeed we think that having
different templates for digests is a really advanced use case we do not
want to support.
Finally kpis and action computation is rewritten. It now returns an unique
structure containing all information in a more neutral way, holding values
for 3 columns. Purpose is to be less date-oriented in data construct and
allow people to use digest qweb template to display a 3-columns KPIs content
even if not related to yesterday / last 7 days / last 30 days.
LINKS
Task ID 2197417
Community PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Add a daily digest option, allowing to send digests on a daily basis. It
will be the default settings to help users coming back to odoo.
Add a slowdown heuristics. If not any user targeted by a daily digest logs
himself within 3 days, digest is slowed down to a weekly setting to avoid
spam.
Add a preference section in template, to hold notably links to some
configuration steps sent mainly for admin / CEOs.
Improve access on models.
LINKS
Task ID 2197417
PR odoo/odoo#51619
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Improve template according to FP specifications, aka
Header
Tip
KPIs
Preference text
Want to customize?
Mobile Tip
Footer
LINKS
Task ID 2197417
PR odoo/odoo#51619
Upgrade PR odoo/upgrade#1256
Co-Authored-By: Elisabeth Dickinson <edi@odoo.com>
Co-Authored-By: Thibault Delavallée <tde@odoo.com>
PURPOSE
Make digest email and tips more appealing. The goals of these tips are
* to encourage the adoption of other apps (Did you know ?);
* to make Odoo look more fun (Fun tips and tricks, young and dynamic style);
* to show social proof and increase trust (emphasis on already existing
projects / customers to);
SPECIFICATIONS
Slightly reorganize code to ease future changes, notably in KPIs computation
that will be made a bit more generic.
LINKS
Task ID 2197417
PR #51619
Currently only digest planned "today" are sent. Which means that digest that
missed a cron tick are not sent anymore. We fix that by making the cron run
on all digest whose scheduled date is in the past or today.
LINKS
Task ID 2197417
PR odoo/odoo#51619
Instead of triggering one has_group by user (one sql query/user if not already ormcached),
and potentially filling the `has_group` cache with new users data (we don't know if and when this data
will be used anyway), compute this field from the groups information already in cache.
X-original-commit: d771d7e9c8503543d29fdbf2ab961c2a32cc3bac
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
We also have to update code calling directly the rendering itself. Indeed
some code bits does some rendering directly on jinja-enabled input and not
through templates. Those calls have to be updated accordingly.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Clean and rename code about language management and template rendering in mail
template model.
SPECIFICATIONS
Clean method naming and try to make code easier to understand and call. Also
add and/or clean docstrings of rendering methods.
Notably
* ``_classify_per_lang``: for each lang-contextualized template, give the list
of record ids;
* ``_render_template``: now working only on a valid list of IDs instead of
allowing both int / list and having a return type depending on the input
type. It allows to simplify code and delegate some processing to callers;
Introduce new API method
* ``_render_lang``: for each record id return the lang matching it;
* ``_render_field``: render a field of mail.template, on given set of record
ids. Usage: template._render_field('body_html', records.ids). Language
computation is available for this method;
Remove the "multi mode" support of rendering that either returned a rendered
value, either a dict based on given ids. Now all methods always work in batch
and caller have to fetch the correct result if necessary.
LINKS
Task ID 1963529
Community PR odoo/odoo#32397
PURPOSE
Ease edition of digest tips by adding a name.
SPECIFICATIONS
Add a name on digest tips. Even if technical and not send to customers it
allows to see them at a glance in list view without having to guess their
content.
LINKS
Task ID 2214325
Com PR odoo/odoo#47416
Related: odoo/upgrade#933
Related: odoo/enterprise#9167
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the computation of kpi for last week, last 30 days and
previous period comparison was wrong due to cache. Indeed as first value
was in cache, other values were taken directly from cache itself instead
of recomputing each value based on start_date and end_date of the computation
timeframe.
As digest fields are computed fields used a bit off-side, let us manually
invalidate the cache before computing a kpi so that it correctly computes
the timeframe values.
Task ID 1883428
closes odoo/odoo#40861
Closes: #40834
X-original-commit: 2966ee59cabc2bbae91e4ac4701fc393bc3770ae
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
The goal is to be coherent with the user property.
Actually, company_id and company_ids on the environment are no fields.
Calling env.company_id returns a browse record, not an id.
Purpose
=======
Allow the user to select the allowed companies for which he wants to see records
on top of selecting his current company.
It is confusing for users to see the records from the company he is connected to
and the records of the children companies.
Instead of using the hierarchy of companies to access records across companies,
the user can now select (from his set of allowed companies) the companies for
which he wants to access records.
/!\ This means that the user will interact with records from company A when in
company B.
Example: a SO has been created and confirmed in A. When in B, I create the
invoice from it.
Specifications
==============
1/ Deprecate the parent/children hierarchy on the res.company model. The fields are
kept on the res.company model to ensure the retro-compatibility, but won't be used
accross the standard code anymore. The only functional usage for this mechanism
was to allow to see records from several companies by creating a virtual parent
company, which will be possible with the new mechanism.
2/ By default, a user will only see the records of the company he is connected
to (or records without a company). (It is still editable by the user if needed).
For that, put this information in the user context, to allow having different
configurations on different browser tabs. Instead of having domains like
['|',
('company_id', '=', False),
('company_id', 'child_of', user.company_id.id)]
you'll have something like
['|',
('company_id', '=', False),
('company_id', 'in', company_ids)]
Note that the 'company_ids' is a value that is passed in the evaluation
context on the record rule, as we already have user, or time.
company_ids is a list of the ids of all the enabled companies in the
user's context.
3/ Out of the generic improvements brought by this task, this will illustrate
issues that could exist since several versions. For example, it should not be
possible to create a scrap order for the company A with a package of the company
B, or it should not be possible to create an invoice on the company A with
payment terms from the company B. Before the version 12.0, it was easy to
encounter this kind of issues as the admin was the SUPERUSER_ID. A positive side
effect of the fact that the SUPERUSER_ID has become an inactive user was to
make it more difficult to introduce mismatch on the records, but haven't solved
the issue, as it was still possible to do it with parent companies
configuration. Some of these issues have been fixed in this commit, but all the
business flows should be re-tested to check if an ir.rule should be introduced
(eg: a multi company rule for stock.quand.package), if the company of a record
is correctly transfered to another record created from the first record (eg:
From a SO, create an invoice and a payment, the company of the sales order
should be transfered on the invoice and the payment, even if the company of the
sales order is A and I'm logged into the company B with the company A enabled.
4/ Currently, if I click on a button on a notification email (example 'View
Task'), I face a traceback if I'm not logged into the company of the record.
Now, if you click on a button and if you have access to the record, the correct
company will be automatically set.
5/ If I display a kanban view with several records from several companies (and
an image), all the images should be displayed.
6/ Currently if you copy paste an url, this will crash if you're not in the
correct company. This won't be fixed because it's quite impossible to do it in
a clean way. This task brings a workaround. Copy/Paste -> Traceback -> Log into
the correct company, re-copy/paste -> Ok.
7/ 2 property methods have been added on the environment to retrieve the company
on which the user is logged in and the companies the user enabled, on a specific
tab.
That way, when creating a record, instead of doing
default=lambda self: self.env.user.company_id
do
default=lambda self: self.env.company_id
On the other hand, to retrieve the enabled companies, do
companies = self.env.company_ids
8/ Modify the Company Switcher widget to allow to log into another company
WITHOUT writing on the res.users (and thus bringing cache invalidation issues
and so on). Also allow to enable several companies and see records from several
companies, and independantly of the other browser's tabs.
9/ When focusing on a tab, save the current company configuration on the local
storage. That way, when doing 'CTRL+T' or a middle click, the context is
propagated to the new tab.
10/ Improve the error message in case of multi company access errors. Now, when
the user is in debug mode, display the related names of the records and the name
of the user who brings the issue.
11/ Remove the context erasing when writing on a res.users
This is probably coming from the migration to new API of the base module.
The context was not propagated at this moment, which was a common mistake at
that time. When migrating the module, probably by using the 'black box' method,
as the context was not propagated, it was erased on the new version. This is
now an issue because the context (i.e. the enabled companies) was erased when
writing on a res.users, leading to tracebacks.
See: https://github.com/odoo/odoo/commit/7eab8e26d3d46c53f4be924d6a34e80a66e74960#diff-4c2e738ee8f64f11806c889ea097b5e7R624
12/ Fix the crash manager on redirect warnings. The issue is the following
- Create an invoice on a company without a configured CoA.
- Set a partner
- On the onchange_partner_id, a redirect warning is raised to propose you
to configure a CoA
- Click on 'Go to the configuration panel'
- A generic warning says something like 'Do you want to discard your changes?'
- Click on yes, the page refreshes, but not on the redirect action.
Now, set correctly the action on the hash, and reload instead. The breadcrumb is
lost for example, but you reach the correct action at least.
13/ Introduce a res.group to enable/disable the multi company per tab
feature.
14/ To help the users to know which tab is in which company, add the
possibility to have a favicon per company. When creating a company,
the classical 'O' icon is colored by default in a random color.
15/ Remove the company switcher on the frontend. This was mainly there
to allow a user to swicth to the company linked to the website.
This behavior is now transparent to the user. If the website A is
activated, then the company set on the context is the company of the
website.
16/ Deprecated the _company_default_get method on the res.company
model. Remove the method _get_company on the res.users model.
17/ Add 'allowed_company_ids' and 'current_company_id' on the pyeval
context. You can now use those variables on domains in the views to
access directly to the activated company.ies on the current tab.
TaskID: 1960971
closesodoo/odoo#32341
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Purpose of the task is to improve the usability of digest email layout.
- Click on Connect button to connect to the database.
- Use same left padding in the header as in the section title.
- 2 decimal digits for monetary amounts, no space with currency symbol.
- Count real messages only, not notes or notifications.
- Add new tips for video tour.
- Moved recipients to a new tab.
- Changed email author to company's email.
- Some minor layout fixes.
Task-1918364
m2m ORM operation (4, id, _) was not correctly used, resulting in an
unexpected behavior. Instead of adding the record, it would add the record and
also the res.user(4,).
As that used is generally the public user, without an email address, that bug
would not be that critical but if that res.user(4,) does not exist (eg deleted),
then the code simply crash as it tries to read user 4 from db.
closesodoo/odoo#32425
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
The `company` context is explicitly set by `action_send` while the
template previewer doesn't set it. This inconsistency leads to
error when previewing the digest template.
opw-1939007
closesodoo/odoo#31195
This commit fixes the following bug:
* On a new DB, install account
* Settings > Technical > Email > Digest emails
* Open Weekly Digest, set Next Send Date to current day
* Settings > Technical > Scheduled Actions > Digest Emails
* Run manually
AttributeError: 'res.company' object has no attribute
'resource_calendar_id'
The field resource_calendar_id is added in the module resource.
The module digest does not have resource in its dependency.
In stable version, have a silent fallback on UTC if the field is not present.
The right dependency should be added in master.
closesodoo/odoo#28244
Purpose
=======
Remove the method 'render_template' in mail.compose.message as the indirection
is not useful. Call the method on the correct model (mail.template) directly.
This commit adapts the business code to changes introduced by
the parent commit in order to keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Studio fields are prefixed by x_studio, not only x_ which are simple custom
fields. This commit update the field name check to correctly include fields
created through studio.
As studio automatically add x_studio as prefix help is updated to tell
users to only use kpi_ as prefix for their digest fields. Result will
be x_studio_kpi_foo and x_studio_kpi_foo_value which are the value digest
needs to run.
This commit is linked to task ID 1887619.
This commit adds a new digest module allowing to send recurrent digests by
email. Those contain a summary of the activity and display various KPIs
allowing to see the activity at a glance. It is also a great tool to improve
user engagement.
Digest module contain the core implementation of digests emails as well as
first basic KPIs. Future commits will gradually add KPIs in various main
addons.
Digests consist in email templates that have to call some methods on digest
module (compute_kpis, compute_tips, compute_kpis_actions) and render it
accordingly. A default digest is given in data allowing to tune it or to
duplicate and modify it.
Frequency is configurable on the digest; digests can be weekly, monthly or
send every 3 months. New employee users are added to the default widget.
KPIs are computed for each subscribed users so that results match its
groups and related access rights. Default digest therefore work for all users
as displayed results depend on their right without having to define separate
digests just for that purpose.
Implementation is done with Studio in mind. KPIs are computed fields on the
digest model. It means using Studio custom computed fields can be defined
to add customization to the digests, using fields named x_kpi_... .
Digests also holds tips to remind and warn users of features to activate
or configure like mailgateway.
KPIs can be linked to actions so that the section contain a link allowing
to directly jump on a given menu, allowing to directly link reporting
menus for example.
This commit is related Task ID 30655 and PR #18318.
Co-authored-by: Siddharth Gajjar <sga@odoo.com>
std-odoo