Purpose of this commit is to rename and reorder data by main model. It
allows to better understand module organization and find data one may have
to update.
Task-2678295
Part-of: odoo/odoo#79599
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
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
In this commit we replace report_footer and report_header field of
"base.document.layout, res.config.settings" model as
they are related fields of res.company models field
report_footer, report_header.
Task Id: 2499504
X-original-commit: 4c474d0d2055efe81fdc21502aa5957fe80af7ef
Purpose is to have all mail template into a mail_template_data.xml file
when possible. It eases maintenance and update when having to work globally
on template records.
Also update some ``body_html`` declarations still using ``xml`` instead of
``html``.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
Prepares Task ID-27033 (QWeb in templates)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Trying to improve the resources used by the challenge update cron
operation.
Before this commit some count-based goals and all sum-based goals were
computed with one select count or sum per user.
After this commit each count or sum based goal is computed in a single select
for all users. The goal form now also allows to enable batch mode for
sum computations. Other changes include:
- adding an index on the challenge_id of goals after verifying the
positive impact of such an index on high volumes on a staging server
- introducing additional intermediary commits to allow massive crons to
catch up over several attempts.
task-internal
closesodoo/odoo#63265
X-original-commit: 0f9411d10753aa96103ce77702dbdc0516e9969a
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
Before this commit, when checking the gained karma per month or per week in
/profile/users route, the users gained more karma than they actually have.
This is due to the way demo data are loaded : karma tracking history is added
but when the final karma is set on the user, a new line of karma tracking is
created on the DB (via write or create method). But as the transaction with
karma tracking demo data is not commited yet, the old value is still 0.
That leads to add a new karma tracking line that have old_value = 0 and
new_value = user.karma. At the end the users 'gained' as addition the amount
of the karma they have.
E.g : Mitchell Admin has 2500 karma and his karma tracking history is the
following: 0 -> 1000 then 1000 -> 1500 then 1500 -> 2500.
In total, Mitchell should have gained 2500 XP: (2500-1500)+(1500-1000)+(1000-0)
But, before this commit, as there is an additional 0 to 2500 karma tracking
line, Mitchell Admin gain in total : (2500-0)+(2500-1500)+(1500-1000)+(1000-0)
= 5000 karma.
This commit clean that additional karma tracking line to get a correct karma
tracking history.
Task ID: 2209743
PR #48042closesodoo/odoo#48061
X-original-commit: 858f80e2529b17d1857d77f372c378ae235443de
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
* Code cleanup
* Avoid a safe evaluation of the field value when loading those records.
closesodoo/odoo#44883
Related: odoo/enterprise#8283
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Purpose of this commit is to improve model of followers, notably management
code and its use in routes. Indeed it is quite an old model and code had
to be cleaned a bit to improve code readability and maintenance.
In this commit we
* remove unnecessary code examples in gamification about followers: using
that model as example of code for goals is probably not a good idea as it
is technical;
* rewrite routes called by JS are simplified to better match JS
implementation;
* introduce computed fields to fetch related partner or channel name,
email (partner only) and active status;
LINKS
Task 1933771
Task 2078313
closesodoo/odoo#39808
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Remy Voet <ryv@odoo.com>
Co-authored-by: jgi-odoo <jgi@odoo.com>
Co-authored-by: Xavier-Do <xdo@odoo.com>
PURPOSE
Allow karma gain tracking enabling notably display of top users based on
weekly / monthly gain in website profile.
SPECIFCIATIONS
Each time a user gains karma a record is created in the gamification karma
tracking model. Scheduled activity runs to consolidate the records into
monthly gain records to avoid having crowdy table and unnecessary noise
in karma gain.
This model is made private and only accessible through some dedicated
compute methods / controllers used in website profile.
In website profile module buttons are added to see users ranking based
on their total karma (like before) but also by last week and last month
gains (using the newly introduced tracking model).
LINKS
Task ID 2003505
PR #34594
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
The following models are already using big images, or they might need big images
in the future:
- partner
- hr employee
- shop category
- lunch product
- gamification badge and karma rank
PR: #34925
image_original => image_1920 (now resized to 1920)
image_big => image_1024
image_large => image_256
image_medium => image_128
image_small => image_64
image replaced by image_1920 (when writing) or by image_1024 (when displaying
what was previously the big size)
+ add new intermediate format:
image_512
PR: #34925
For some strange reasons, the e-learning ranks are created in data but
the demo data override their motivational message fields.
Unfortunately, the demo data were ok but the normal data had broken
images in them.
closesodoo/odoo#34282
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This fix correctly displayed motivational of next rank to achieve depending
on current karma. Indeed description_motivational field is not the
motivational to reach next rank but to reach the current rank, taken from
previous rank point of view. That way a given rank is configured by modifying
only 1 data.
When not having any karma points (newly created user) the next rank is computed
as being the first available rank. Motivational phrases and badges are updated
accordingly. This commit partially reverts 489c8623e2.
Result
* new user with no karma: next rank is the first rank;
* user with karma and next rank: as currently;
* user being at final rank: next rank is just current rank with a 100%
circle;
Linked to task 2005840
Related to PR #34220
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
In order to se the 'next rank card' and the user karma on user's profile page,
not only the first rank is needed but also higher ranks. Otherwise everyone
will be 'Newbie', even the admin.
Moreover it is easier to update existing data for things like rank than having
to figure out how it works.
Task ID : 1941250
PR #31697
If a new user try to access the elearning platform or his porfile, if he has
no karma, has it is the case for new users, he won't get any rank. So that
the next rank karma minus current rank karma equals zero.
To avoid this, next_rank will always be first one existing if the user has no
karma. Also, the current rank will not be displayed if the user has no karma.
finally, next rank will not be displayed if the user reached the last existing
rank.
Task ID : 1941250
PR #31512
Purpose of this commit is to clean motivational capabilities of gamification
ranks[1]. It makes more sense to store a motivational to achieve on next rank
itself. We therefore rename the field and provide nice demo data that will be
used in elearning use of gamification ranks.
Commit linked to task ID 1941250 and PR #31133.
[1] task ID 1922159 (landed at 91ee6ba5a7)
Purpose of this commit is to add challenges related to slide / elearning
module. 5 new challenges with their badges are added. Portal user partner
is now also published to have bioutifoul demo data. Commit linked to
eLearning tasks [1][2]
Co-Authored-By: David Beguin <dbe@odoo.com>
Co-Authored-By: Thibault Delavallee <tde@odoo.com>
[1] new homepage task: ID 1936153 and PR #30770
[2] new user profile / gamification task: ID 1922159 and PR #30514 and #30988
Since 56645335b7, when a user get a badge,
an email is sent. The subtype is not used anymore, so the alert
mecanism in forum to display a message to the user to show him
his new badges can not work.
This commit removes this dead code.
Task-1922159
As gamification karma-based features can be used outside of forum let us
move demo and data directly in gamification. It will be used notably for
eLearning.
To encourage forum and slides users to be more active ranks are now added.
They are directly linked to karma. The more the user has karma the more his
rank will be high.
The default rank is Newbie, with 1 point of karma. Users with 0 karma are
considered as inactive on forum or slides. When a user reach a new rank
a mail is sent to him to congratulate him with his new rank.
To add a button in the mail template to allow users to go directly on
a website section (like forum or slides) simply override
get_gamification_redirection_data to add the target url.
Partial commit linked to eLearning project. Main specifications related
to gamification and user profile can be found on task 1922159 (PR #30514).
Main specifications related to eLearning can be found on task 1902304
(PR #29876).
Notably
* remove cdata and fix html code when necessary;
* re-order fields declaration to have globally the same order in various
template definition;
* remove unnecessary reply-to, make user signature and auto delete fields
explicit when necessary;
* improve some name to ease template ordering and understanding in the
template list view;
Related to task 1972615
Linked to PR #32872
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Purpose: use more email_formatted when possible, clean and simplify
email_from, email_to and partner_to computation.
Next step is to try to extract some common patterns in tools or methods in
order to simplify template creation and customization.
Related to task 1972615
Linked to PR #32872
A challenge with less than 3 participants was failing with a key error
The challenge line has only one 'goal' result per participant
As the template is set in a noupdate, even a module update does not fix the bug
Generate fake goals that will be displayed in the top 3, e.g.:
1 Bob $100 42%
2 Alice $50 21%
3 0 0%
closesodoo/odoo#28363
- Add a method for generating an image data URI, and expose it in QWeb context
- Fix reports, website templates or mail templates with data hardcoded
data URIs, to use the helper (Python cases), or the existing
kanban_image helper (for JS cases)
This will gracefully handle SVG support in addition to classical image
formats.
Closes#26635
[NEW] base: show enterprise module, with an 'upgrade' button
[IMP] *: some modules renaming, and improved copywriting of manifest
[IMP] *: utm on links to odoo.com
Purpose of this commit is to enhance quality of templates proposed by Odoo
and make them use notification layout when send by emails. Those emails
are cleaner and more up to date compared to other emails.
Including
* calls to message_post now use the light notification layout. It is
given as parameter to the message_post process;
* some cleaning in templates;
This commit is related to task ID 51122 (and PR #24052).
* [FIX] Gamification: email template
- realized that the pictures of users were not public by default,
which means src with an url won't work if not connected to the database.
This is fixed by embedding the pictures directly in the mail.
* [FIX] Gamification: challenge template
- fixed layout problems with what works in the renderer.
The purpose of this commit is to handle code execution only in server
action and delegate schedule management to ir_cron model.
ir.cron model now inherits from ir.actions.server. Fields model, function
and args are removed as well as the logic to handle them. There is no
more code manipulation and evaluation in ir_cron, only a call to the run
method of ir.actions.server.
Cron form view use server action form view as primary view. This way
automated actions use the same base form as server actions with
cron details added.
Thanks to @fpodoo for the original idea and preliminary work. Thanks to
@jpr-odoo for first developments. Thanks to @jem-odoo for reviewing.
* base_action_rule, gamification, mass_mailing
1) Create the independant DomainSelector widget
- Allow to build a prefix char domain
2) Replace old FieldCharDomain with a new FieldDomain which uses the
new DomainSelector widget
3) Create the independant ModelFieldSelector widget
- Allow to build a valid field chain for a specific model
(e.g 'partner_id.name' for a 'res.users')
- Used by DomainSelector widget
---
The DomainSelector widget uses a tree-like representation with
user-friendly buttons (ALL/ANY/+/-/...). Any domain can be built,
except those containing the "!" (not) operator or some operators
like "like", "child_of" (@see DomainSelector). However, if the
user enters these in the debug input, the widget can handle them.
Note: these widgets had to do unusual stuff the widget API does not
allow to handle efficiently right now but it will be adapted to the
new widget/field API in a further update.
Note2: the widgets also have possibility of other improvements like
supporting m2o input instantiation in DomainLeaf, etc.
---
This work is an adaptation of the original code made by @pga-odoo.
Give some details about the badge: its description, its image, who granted
it, ... Otherwise it is quite complicated to understand the email content.
Thanks to @mart-e who reviewed and tested.
Therefore, the template could be seen from
the Discuss module, when clicking on "Send Mail",
but, when attempting to use it, it failed
(as it was not applied on the right model).
opw-670546
Thibault Delavallée