Before this PR:
The 'public_views' field is editable by the user.
After this PR:
The 'public_views' field is not editable from now onwards.
Task-3262249
closesodoo/odoo#118989
X-original-commit: b9b133dab12db9ec3d7231ea8d50f5188e98b5a6
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Replaced _.each() functions (average 235 occurences)
Description of the refactoring this PR addresses:
Current behavior before PR:
There are underscore.js function enumerated above used in odoo.
Desired behavior after PR is merged:
These functions has been replaced by native javascript
prototypes/methods/functions.
TaskId : 3246238
closesodoo/odoo#118565
Signed-off-by: Georis François (fge) <fge@odoo.com>
This commit adds the loading="lazy" attribute to every img tags compiled
by the kanban compiler and modifies some kanban archs in order to use
img tags instead of divs with background-image style to load images
(this allows again the loading="lazy" attribute to work).
The purpose is to avoid loading images that are outside the user viewport
at all time in order to reduce the load on the network when new images are
loaded.
Steps to test: find all views that are using the o_kanban_image or o_kanban_image_fill_left
class and ensure all the images in these views appear in the network tab of devtools
when they enter the user viewport. Example: res.partners, hr.employee, ...
task-3102207
closesodoo/odoo#117049
Related: odoo/enterprise#39560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Make the alignment proper between 'external sources' and 'additional resources'
by using the 'col' classes and add the spacing between them.
Task-3229139
closesodoo/odoo#116634
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit,
There is no way to see the next lesson of attendee.
After this commit,
User/Manager can see the next lesson from backend.
Also added 'is_published' field into course's tree view.
Added search for responsible, tag and content, also added 'Archived' filter.
Task-2199207
closesodoo/odoo#79119
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Before this commit,
- Attendee was deleted on leaving the course.
- Remove from membership subtracts earned karma points.
After this commit,
- we will only archive the attendee on leaving the course.
- Joining course again will continue the progress of attendee.
- User inputs also archived on the leaving the course and can continue progress on
joining again.
- Added Archived filteres for the User Input and Attendee.
- Remove from membership will keep the earned karma points as it is and after
rejoining that course will not affect karma points.
- Added 'published' ribbon for only published courses in the kanban view of all
courses.
Task-2199207
Part-of: odoo/odoo#79119
Co-authored-by: Mohammed Shekha <msh@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117456
Signed-off-by: Géry Debongnie <ged@odoo.com>
Steps to reproduce
==================
- Go to elearning
- On the "Trees, Wood and Gardens" card, click on "view course"
- Click on Main Trees Categories
The slide name is outside the view
Also, the XP badge is cropped
opw-3225999
closesodoo/odoo#117595
X-original-commit: 1d5a92a04ba8e52099715cf782cecbb2c73feb14
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit improves ux/ui by adding the slide
description on top of a quiz and offering links to additional
resources if the user gets questions wrong.
task-3246366
closesodoo/odoo#117530
X-original-commit: a551f956f05bf7b6782e04a95351bf2d0a0a6610
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
The mock server implementation does not exactly match the actual orm
implementation. It is not really a big deal, but it makes the test suite
less useful.
In particular, the onchange call should return a value for all fields
when we are creating a new record. Also, the default get implementation
was not exactly correct.
The motivation for this change is to prepare the future relational model
refactoring.
closesodoo/odoo#117434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
When uploading an image or a pdf content to a course, it was not uploaded. When
viewing it, as nothing was uploaded:
- for image, a default one was displayed
- for pdf, it kept loading for ever
This fixes the problem.
We also add tests checking the upload of a new image and a pdf.
Technical note: The file to upload is converted to base64 when the upload input
is changed and stored in file.data. When the user submit the file, it is that
preprocessed data that is being sent to the server. Following 542cb1dc,
nothing was assigned any more to file.data when the input field was changed so
submitted file was then always empty:
- for image, before this fix, undefined was always assigned to file.data
because the "dataURL" was split in 1 element and the second element was taken
for file.data. The submitted file was then always empty.
- for pdf, before this fix, only the preview was generated and file.data was
not assigned. Before that commit (542cb1dc), the file was read twice, one for
assigning the base64 content of the file to file.data and one to render the
preview. Here we read it only once in base64 to store it in file.data and then
convert it to binary for computing the preview using atob.
Task-3178726
closesodoo/odoo#117293
X-original-commit: 8a7453d9fc43cde13e2e07697e0b0b104a537b93
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
*: website_blog,website_event,website_forum,website_hr_recruitment,
website_livechat,website_sale,website_slides
Prior to this commit, elements inside the New+ modal had a `isDisplayed`
property that was meant to be changed by the patches done by each
module. Unfortunately, this was forgotten in the refactor done in [1]
and more precisely when the component was introduced in [2].
This commit fixes that by checking the access rights of the user on each
individual model used on the create form.
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
[2]: https://github.com/odoo/odoo/commit/ca2e143d54622d598201826a2cd669bad64b205d
opw-3198700
closesodoo/odoo#117206
X-original-commit: 58704cb7615addd7d40291431e05a894776320d8
Related: odoo/enterprise#39066
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
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#116167
Related: odoo/enterprise#38542
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>
Step to reproduce:
- Install E-learning module
- Go to any course and set `Display` to `Documentation`
- Click on `Go to website` and open editor
- Click on `Theme`, then in `Theme Colors` section, click on the
palette and select the first custom colors (black-white-gray)
Issue:
The background of the submenu (just under `Course` tab) is
transparent (while it should be black, like main menu) and the links
are not well displayed (white/light text color).
(Same issue with navbar brand and toggler when reducing screen width)
Cause:
The background of the submenu is always set to transparent but
the text color change depending if the top main menu background
is dark or light.
Lines that make the issue: https://github.com/odoo/odoo/blob/693092f2c90e36735c6896b6c6e7d795406453e9/addons/website/static/src/scss/website.scss#L240-L252
Solution:
Set the text color (and the background of the toggler) to
`light` color if background is dark (determined with
`has-enough-contrast($body-bg, $dark)`), otherwise use `dark` color.
opw-3086750
closesodoo/odoo#115910
X-original-commit: ee7fe74d6d839eb20b6165e475f49eeed0262fcc
Signed-off-by: Nasreddin Boulif (bon) <bon@odoo.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
They dates from < 2027 and are quite outdated. Favour the nl
translation instead.
n_BE is not on Transifex so it was not possible to correct bad
translations.
closesodoo/odoo#115845
X-original-commit: d04c8b7e484db8306d858c891a7a2b11885fdcd9
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
We have introduced a method that compute the download URL of a slide in the fix
odoo/odoo#113749 which we convert here into a computed field to simplify the
code.
Task-3196081
closesodoo/odoo#115267
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
* The tours are now run by the `MacroEngine` defined in `macro.js`.
* This is accomplished by converting (at runtime) the user-defined tours to
`Macro`s. See `tour_compilers.js` for the step (and tour-to-macro) compilation.
* API is kept the same as much as possible. Basically, declaring tours stayed
the same with some exceptions:
* `allowInvisible` can be provided in a step to allow consuming the trigger
element even if it is invisible.
* `isCheck` can now be used to replace the no operation `run` that is
traditionally signals the runner to only perform a check.
* Before, multiple `run`s can be called simultaneously. Now, each `run` method
is awaited before proceeding to the next step.
* If the trigger element is `disabled`, the tour runner will *not* proceed on
calling the `run` method and the runner will stay on current step until the
trigger element becomes `enabled`.
* However, the tour runner is okay with `disabled` trigger element if the step
has `isCheck = true`. As long as the trigger element is found for `isCheck`
step, the tour runner will happily move to the next step.
* Some tours are adjusted to properly run with this new tour runner.
* When the tour failed:
* The dom string is not logged anymore.
* However, a warning message containing the relative location of the step will
be logged. This is better in helping the author in locating the failed step.
**Some guidelines learned during the development:**
* Each step may trigger a dom mutation. It's a good practice to insert an
intermediate step that *checks* the existence of an element that result from
the action of the previous step.
* Refrain from using the `run` method for assertions. `run`, in principle, is
provided to perform actions that are not offered by the helper. Use the
`trigger` for assertions.
* During dev, find `SHOW_POINTER_DURATION` and set it to `250`. This will show
the pointer (pointing to the trigger element) for 250ms when watching the
tour.
closesodoo/odoo#107618
Task-id: 3082036
Related: odoo/enterprise#37560
Signed-off-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
To reproduce the problem:
- ensures python-magic is not installed. It is used to guess the mime type of
a file. The code uses an alternate solution if not present and this is that
alternate version that's unable to guess the mime type of an xlsx file.
- in website_slides, open a course
- open a content
- go to the "Additional Resources" tab
- add an xlsx file
- remove the extension of the file in the name
- open the public website and open that content
- click on the link of the file you just have added
- instead of a xlsx, you get a zip file
This fix solves the problem by using the extension of the file uploaded if it
is valid.
Technical note: prior version 16, the mime type stored in the attachment was
used to determine the extension of the file when downloading it. From version
16, if the extension is missing in the file name, the system tries to guess it
using python-magic if installed and a custom implementation if not:
_odoo_guess_mimetype. The custom implementation doesn't support the detection
of xlsx files (and other formats) while python-magic supports it. That's why
the problem described above only appends while python-magic is not installed.
To solve the problem we have added in the download URL the file name as the
the name of the resource with the extension of the file name uploaded
(extension not added if the name had already the same extension as the file
name).
Task-3200998
closesodoo/odoo#115273
X-original-commit: 3a7388a69991d968c349133be4ac52745bbac65b
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
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 last view in the odoo codebase has just been converted to owl,
meaning that we no longer have legacy views. This allows us to
remove a lot of legacy view related code: the abstract elements on
which the legacy views were built, the compatibility layers that
allowed to deal with both owl and legacy views uniformly, legacy
widgets that were only used in those legacy views...
closesodoo/odoo#114893
Related: odoo/upgrade#4420
Related: odoo/enterprise#38005
Signed-off-by: Géry Debongnie <ged@odoo.com>
This commit contains mainly code cleaning, docstrings and a small split
for notification tool methods. In this commit we
* make some notification groups variable explicit;
* move the filler of groups into its own submethod to ease being called
from other code (to be used soon);
* fix some strange overrides or code manipulation;
* propagate some additional parameters to ease future commits that will
improve rendering of groups-based notification emails;
* cleanup, fixup and improve docstrings;
This does not change anything from functional point of view, just preparing
further work.
Task-3046371 (Mail: Better Language Support in Composer)
Part-of: odoo/odoo#106177
The type fields of actions already defaults to
the model name in the base model definition.
Therefore, specifying `ir.actions.server`, `ir.actions.act_window`
& so on as type is useless (and adds noise since it's the same as
the action model).
closesodoo/odoo#114539
Related: odoo/enterprise#37855
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Purpose
=======
Some users found a way to farm karma points, so we want to be able to
track the source of the karma gain / loss.
Specifications
==============
Now, we added a reference field `origin_ref` which store the record
responsible for the karma gain / loss (e.g. a slide we just completed).
In addition to this origin, we also have a new field to store the
reason (e.g. "Slide completed") so we know exactly what happened and
how the user gains his karma.
Before, the `old_value` of the karma tracking has to be set manually,
but now it's done automatically based on the value of the previous
tracking of the same user. That way, it will simplify other part of
the code.
Add the karma reason in the website modules. Adapt those modules due
to the changes in gamification.
Task-2234179
closesodoo/odoo#76430
Related: odoo/enterprise#23702
Related: odoo/upgrade#3299
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Co-authored-by: std-odoo <std@odoo.com>
Purpose
=======
Remove the karma gain on vote, because it gives an incentive to like
all slides and to never dislike.
Task-2234179
Part-of: odoo/odoo#76430
**Before this commit**
- The optional "class" attribute set on the root node of a view arch
is ignored, except for the kanban view which has a custom
way of using it.
- The optional "js_class" attribute set on the root node of a view arch
does not have any impact on the class names passed to its controller.
**After this commit**
The content of the optional attribute "class" set on the root node of an
arch like in
<list class="o_custom_class">
...
</list>
as well as an additionnal class derived [1] from the value of the
"js_class" attribute set on the root node of an arch like in
<list js_class="extended_list">
...
</list>
will both be found in the prop "className" of any view controller.
[1] a js_class value of "xyz" yields to the class "o_xyz_view"
**Note on this commit**
The kanban view was already appending the root node class attribute
to its renderer element. This is no longer the case and some styling
rules has been adapted.
closesodoo/odoo#113014
Related: odoo/enterprise#37265
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit intends to add information about the number of slides,
as well as the time needed to finish said slides to the slide sections.
We now also round completion time values up to minute when getting said values
from youtube, google drive or vimeo.
In addition, we add responsible, course and tags options in the search bar.
Task-3054391
closesodoo/odoo#107507
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Various: im_livechat, rating, test_mail_full, website_{sale|slides}
Allows to rate any record extending mail_thread. This change was needed because
rating template could be created for any models, even those not inheriting from
rating.mixin. If sent on a record of such model, it was crashing when the
controllers using rating mixin features were used. This is no longer the case.
This commit moves the code from the mixin rating.mixin to mail.thread and
adapts the test for testing rating submission with and without the mixin.
Base behavior accepts rating and provides an access to ratings through the
'rating_ids' field. Rating.mixin inherits now from mail.thread to ease
computation, and adds statistics and some advanced capabilities.
Inheritance of some model have been reordered now that rating is build on
top of mail.thread.
Task-2674649
Part-of: odoo/odoo#103966
Before this commit, the field's description was stored on the
component and this component was then registered.
Now, an object describing the field is used on registration the same way
as it is done for views since https://github.com/odoo/odoo/commit/b828cfc72c587d0b73fcc5459695705640437671.
This split the component's description (props, template, ...) of
the field's description (displayName, supportedTypes, ...) and makes
it clearer.
closesodoo/odoo#112498
Task: 3171520
Related: odoo/enterprise#37105
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
*: base, http_routing, mass_mailing, web, web_editor, website_slides
In some situations `werkzeug.wrappers.Response` are used instead of
`odoo.http.Reponse` that extends it.
This is a problem because since [1] the calls to `set_cookie` expect it
to accept the `cookie_type` parameter, which is not the case in the base
werkzeug implementation.
This commit replaces the `werkzeug.wrappers.Response` by
`odoo.http.Response`.
[1]: https://github.com/odoo/odoo/commit/2cbda6c98ee947cea1d06c09880eee8c758304a8closesodoo/odoo#112827
X-original-commit: 28da08292b7028575e628c5ad846fc05d30498f2
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Purpose
=======
Prevent the 'Visits' stat button of the Course to
open any content action.
Task-3163777
closesodoo/odoo#112560
X-original-commit: ed064682a1e4aa8131665194a516a0a6652b74f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Following this PR odoo/odoo#97398 website_slides module was forgotten
This commit add 'sanitize_overridable' parameter to the html_content
field. This will allow one to use the embed snippet in an article
type slide.
Task-3134690
closesodoo/odoo#112534
X-original-commit: 627833e77eb8f7ef7850f1fdeeb115ee8870c7f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
The `member_values` argument of `action_add_member` is no
longer used in any call of `action_add_member`. We can therefore
remove it in standard, as it's completely unused.
Besides, after grepping the code for all calls to `action_add_member`
to check `member_values` was indeed unused, I saw this method
wasn't used by any views or Javascript code, but only
through Python routes, and therefore it can be converted
to a private method by prefixing it with `_`,
as our guidelines states to make private methods which are not used
by the web client.
closesodoo/odoo#111908
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
*: website_slides
In some cases, components had dark text over dark background (or light
text over light background) by mistake.
Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
body color instead of the expected boxed layout color.
Another example:
- Do the same thing (set up a dark color behind a boxed layout).
- Go to a shop / product page.
=> The inputs are dark with dark text.
This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the first case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.
In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs.
In previous versions, this fix focused on fixing a critical component:
nav-tabs, for which the fix was straightforward.
Starting from 16.0, this commit will fix everything at the small risk of
changing the `$body-bg` variable meaning in the case of boxed layouts.
Before this commit, its meaning was "the color used for the background
behind the boxed layout (the <body> background color)", so equal to the
Odoo value `o-color('body')`. After this commit, its meaning will be
"the color used for the background of the box itself", so equal to
`o-color('o-cc1-bg')`. The `<body>` background color will be forced by
using `o-color('body')` as the value for the related *CSS* variable
defined by bootstrap. This allows to have a correct CSS generation for
all components in case of boxed layouts: indeed, the components mix
their own color with `$body-bg` (or use it as it is) relying on the fact
this is the color which appears behind them... which was not right in
case of boxed layouts.
This commit actually fixes another bug that was found during adaptation.
It is 2-fold, and unfortunately, it does not make sense to fix one part
without the other as it would increase the problem without the other
part. The website_slides pages customize their default background color
to not be the one chosen by the user, but a mix of it with some
lightgray. Odoo default for the body being white, this makes it a
lightgray for website_slides pages. This is totally ok... but only in
"full" layout. In boxed layout, we have the 2-fold problem:
A. The mixed color is not applied to the boxed layout but on the
background behind the box. So if you have a white box above a black
background, in website_slides pages you won't have the black
background you expected to keep but a lighter version of it and the
website_slides box will not use the lightgray but stay white
(creating other inconsistencies as the lightgray would also be used
by other components like tabs, for that app only).
B. The mixed color is actually not mixing the right colors: it mixes
the hardcoded lightgray with the color of the background behind the
box, while it was intended to be the one of the content (the one of
the box), like in "full" layout.
The changes explained above about `$body-bg` naturally fixes (B). Not
fixing (A) at the same time would result in a big change for the color
which is behind the box. This commit fixes it at the same time by now
applying the color to the right element. In previous version, this could
be fixed as well but would require a different fix (not relying on
`$body-bg`). So it makes sense to merge this first and backport+adapt.
[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c
opw-3151962
closesodoo/odoo#112254
X-original-commit: 14c985af526602a88666714e716283650521e537
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit removes the legacy implementation of the form, kanban
and list views. It also removes the legacy view widget registry,
and all legacy widgets it contained. The legacy field registry
couldn't be removed yet as some fields are still used (e.g. in
client actions: FieldMany2One, FieldMany2ManyTags...), and
sometimes accessed from that registry (e.g. uom service). More
clean up will come later. Note that all tests using legacy views
have thus been removed, even though the tested feature might still
remain (e.g. FieldMany2One tests have been removed, but that field
is still there). However, those features are deprecated and
unlikely to evolve. They should be removed in the next saas, or the
one after.
Finally, this commit also removes the legacy view dialogs.
Task 3168640
Part-of: odoo/odoo#111809
Before this commit, in a form view, it was possible to open a record in
a x2many list field when the list is editable (`editable="top|bottom"`)
and the form view or the field is in readonly.
We want to disable the opening of the record in this case to stay
consistant for a better UX:
- when in a editable x2many list, the record form view never opens (even
if the form view or the field is in readonly)
- when not in editable, the form view always opens
This commit does not modify the behaviour of the x2many field kanban
view.
task-2964320
closesodoo/odoo#110838
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit,
the wording of the visibility options can be quite confusing.
after this commit,
- Visibility has been updated
- Visible to all: I see those training to the public
- Visible to logged users only: I am a B2B business, and I do not want the
public to see what I offer + the pricing I have on those
- Visible to members only: I am a school, I want to invite my students but
external visitors should not be able to enroll
- Move the field above the "enroll policy"
- Enroll Policy has been set to invite when visibility is set as a Course
attendee and hide the enroll policy
task- 2862003
closesodoo/odoo#102085
Related: odoo/upgrade#3946
Signed-off-by: Stéphane Debauche (std) <std@odoo.com>
In these two cases, adding and id (and editor message when it is visible)
enables
1/ to retain customizations when the view is updated
2/ to better signal that the section on slides is not meant to be
customizable per-record.
In particular, it was not clear that adding a block above a slide content would
make it visible on all slides. We therefore add this hint there, and not in
other places where that scope is obvious or where it isn't shown even if added,
or where it causes crashes (above covers).
Task-3120276
opw-3106887
closesodoo/odoo#111445
X-original-commit: 24977381fc54e258fa05724a9aa69c72656ece9c
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This is a step closer to a goal of avoiding dependence on asynchronous
modules. Starting from this commit, new tour definition should be
registered to `registry.category("web_tour.tours")` registry.
So, instead of the following:
```js
import tour from "web_tour.tour";
tour.register(name, options, steps);
```
We now do:
```js
import { registry } from "@web/core/registry";
registry.category("web_tour.tours").add(name, optionsWithSteps);
```
Notice the `options` and `steps` params are merged when registering
the tour definition. It should look something like so:
```js
registry.category("web_tour.tours").add("account_tour", {
test: true,
steps: [ ... ],
});
```
And if the `TourManager` instance is needed, one can get it from the
registry like so `registry.get("tourManager")`. Note however that
this instance is only available when the `TourManager` has been
instantiated -- so it's not available at top level of the module.
closesodoo/odoo#111103
Related: odoo/enterprise#36335
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit if you had a single course
and tried to open courses page on website, course
would stretch and fill in whole page.
it is tied to a bootstrap lib update. On bootstrap 4 col-xx-x has
max-width attribute and because of that it wasn't a problem before.
Now bootstrap 5 uses normal width attribute and flex-grow class
just ignores it.
This commit fixes that so that course behaves similar to how
it was in previous versions.
Task-3128895
closesodoo/odoo#110167
X-original-commit: 3171260cc1458e0789268c1425d332d4082743f9
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Update report_template field on template model to be a many2many field instead
of a many2one. It allows to attach multiple dynamic reports to a given template
instead of being limited to a single one.
Name should now come from the report itself, which should be considered as
complete by itself. Template cannot override report naming anymore.
Task-2868153 (Mail: Allow multi reports in mail templates)
Part-of: odoo/odoo#99482
RATIONALE
Improve usage of composer in comment or email mode: support batch-posting in
comment, support more configuration from templates, improve global model.
SPECIFICATIONS
Support a real res_ids field on mail.compose.message model. Instead of relying
on active_ids from context, store it once for all at composer level and use
it in code. Active_ids usage is still done at default_get level, using it to
populate the field.
Improve usage of domain, renamed to res_domain to match other document related
fields naming. Add support of a res_domain_user_id field allowing to set the
user from which the domain should be evaluated.
Composer now runs on a list of IDs. Mass mail mode and comment mode are now
distinct from running on a singleton or on more records. Rendered or raw
mode is not triggered by
* mass mailing mode: always display raw mode, whatever the number of records;
* comment mode: display rendered mode when having a single record (like the
previous comment mode). Display raw mode when having either no records
either at least two records.
Task-3035101 (Mail: Support batch-posting from composer)
Part-of: odoo/odoo#99482
Purpose of this commit is to extract attachments generation on template in
its own sub-method. As it contains code specific to attachments, better
have it separated from the main global generation method. Code is cleaned
to better support parameters and be easier to call. It can now be called
independently from the main ``_generate_template`` method.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Currently some value are always computed and added even if not asked by the
caller. As asking a template to render some fields is now used notably for
a subset of fields (subject and body, from / to, ...) there is no need to
automatically add other irrelevant information.
Main callers already filtered out returned results (notably composer). However
better avoid computing / rendering unnecessary stuff directly at template
level.
Task-2710804 (Mail: Clean MailThread Posting API)
Prepares Task-2088884 (Mail: Use editable computed stored fields in composer)
Part-of: odoo/odoo#99482
Rémy Voet (ryv)