Steps to reproduce the issue:
- Create a presentation in a course (model `slide.slide`)
- Create an entry referencing the presentation in `slide_embed` table
- Remove the presentation from the course and save the changes
Bug:
A validation error was raised
opw:2902062
closesodoo/odoo#99468
X-original-commit: e5c239fcef2ee29856428c8f0d337fffc0a22e56
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Simon Goffin <sig@odoo.com>
We don't want any padding in those dialogs. The presence of the
padding was a consequence of the rewritte of that dialog in owl.
It is a frequent usecase to remove the padding from the body of
dialogs. We thus introduce a new props on Dialog and when this
props is set to `true`, we do not set any padding on the body.
This commit refactors other usecases to make them use the added
props.
closesodoo/odoo#100045
Signed-off-by: Géry Debongnie <ged@odoo.com>
A typo fix is added.
Fix error from loading xml while widget is destroyed. Now that the xml
templates are loaded in the bundle, the error appears more frequently.
Part-of: odoo/odoo#95500
We remove the `field_float_rating` widget in this commit
as is was not used anymore. Its use was dropped at an
earlier PR, however without deleting it.
For reference, we mention here the PRs in which the widget
was firstly introduced and when in was made redundant.
- introduced: #33255
- removed: #55698closesodoo/odoo#99983
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Since 5b375d6 `viewed_slides` are now
stored in a set. This is causing issues post migrations because people
still had the list format in their sessions, and this results in a crash
when `.add()` is called on the list.
While deleting the sessions would likely solve the issues, this fix will
spare some troubles for people migrating in the future.
via p/feedback
closesodoo/odoo#99954
Signed-off-by: Florian Charlier (flch) <flch@odoo.com>
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With the integration slides-knowledge,
slides can be set on the team, so that the user can be redirected
to them when searching for help.
We want to use the same view as for all slides,
but limit the records presented to the user.
With this commit, we create two distinct methods:
one that prepares the values
one that renders them.
This way, we can hook into the first one to replace the records
before rendering them, when the `/helpdesk/<team_id>/slides`
route is used.
task-2890043
closesodoo/odoo#97739
Related: odoo/enterprise#29283
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
*: test_website, website_blog, website_crm, website_event,
website_forum, website_hr_recruitment, website_mass_mailing,
website_sale, website_sale_wishlist, website_slides
- Make sure that all website tours reaching the website preview before
their first step use the related website util to register their tour.
- Rename the website util to register a tour starting on the website
preview from `registerEditionTour` to `registerWebsitePreviewTour`.
Having a method using "Edition" in its name and having a boolean
parameter named `edition` was a bit... strange.
- For both non edit mode and edit mode as a first step, ensure the util
sets a high timeout for the first step. Indeed loading both the
backend and the frontend (in the iframe) and potentially starting the
edit mode can take a long time in automatic tests. We'll try and
decrease the need for this high timeout of course.
- Review the implementation of those utils to be more consistent and
also fix one or two mistakes in them.
closesodoo/odoo#100024
Related: odoo/design-themes#588
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
- adapt the html field and mass_mailing_widget to be owl components
- adapt the mass mailing view to be an owl view
task-2898432
closesodoo/odoo#94875
Related: odoo/enterprise#30915
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
*: event, website_event, website_sale, website_sale_stock,
website_slides
With [1], new list views were created in the website app to display all
key models in the "Site" menu. Each view is based on the related model
base view in their related app, with some more website-related fields
(like the content URL, the SEO optimization, ...), etc. This commit
simplifies those views by removing some columns (make them optional) to
not make them feel bloated. Some changes were done in the base views.
- Products: simplify the website view by hiding 5 columns. Two were
stock related so it had to be done in a new view in
website_sale_stock.
- Events: simplify the website view by hiding 3 columns. Also move the
"stage" column at the end, in the base view too.
- Courses: simplify the view by hiding 1 column, this change is done
in the base view.
[1]: https://github.com/odoo/odoo/commit/da3f4c2aff92cca23ca2d7a87fa0eb5b1d7ce5feclosesodoo/odoo#99937
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
When the admin installs an app, he should see it directly, without having
to give himself the app rights on his user form.
Finetuning of #91909
Task ID - 2936569
Part-of: odoo/odoo#98542
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_sale, website_slides
As indicated by previous commits, new custom list views are created to
fill the "Content" area of the main website menu with key app models:
blog posts, events, forum posts, jobs, products and courses (+ some in
the enterprise version, see related commit).
Those list views will act as the page manager one: a click on an item
redirect to the website iframe, the create button acts as creating a
record via the "+ New" systray button while being on the iframe, the
delete button will in the future allow to know the page that mentions
the related object before deleting it, etc etc.
task-2889981
closesodoo/odoo#98937
Related: odoo/enterprise#30782
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_slides
After [1], the website "new content" dialogs were replaced by formView
dialogs of targeted content (blog, slides, product,...).
The goal of this commit is to restore the "course layout image preview"
on the "New Course" dialog for the "channel_type" field (as on the old
frontend dialog).
Remarks:
- The field was added on 'website' module so it can be used on other
website related modules if needed.
- Some CSS related to the old form was removed in this commit too.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
closesodoo/odoo#96346
Related: odoo/enterprise#29922
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
*: website_blog, website_event, website_forum, website_livechat,
website_sale, website_sale_slides, website_slides, website_slides_forum
The goal of this commit is to adapt the website "new content" form
views to OWL.
Follows the merge of the "website in backend" task at [1].
[1]: 31cc10b91d
task-2687506
Part-of: odoo/odoo#96346
PURPOSE
Globally improve user experience when sharing content from the e-learning app.
This includes new sharing options, allowing to share to multiple emails, split
the sharing template from slide and course, etc...
SPECIFICATION
- added two more options 'WhatsApp' and 'Pinterest' to share snippets.
- we converted the email type of input for 'Share by email' to text,
so we can enter multiple emails to share and also add validation
in the controller for this input text input.
- We improved the design of the share modal by making sure that the full URL
for sharing link is visible and rearranged the UI fields of
'Share' nav-tab on non-fullscreen content (if there is
embed code, the sharing by email and embed code will still be on
the single row).
- Improved the share modal of the channel by adding an email field in it to
Share the channel through the mail.
- New field name 'share_channel_template_id' for channel template
in 'slide.channel' modal and also added _send_share_email method
in it and email template for sharing channel through the mail, and
also added the dedicated route for sharing the channel.
- New share button is added on the top of documents in the slide (which
previously was in the tab below the content).
task- 2627364
Part-of: odoo/odoo#78139
* = test_website, website_blog, website_event, website_forum, website_sale,
website_slides
`_search_get_details` extension in other modules can now be performed with
fewer lines of code by updating a search type-to-model mapping, without the
need for method override.
This will also have the benefit of slightly reducing the call stack length,
avoiding some unnecessary `if` statements and list lookups at runtime.
Task-2957361
closesodoo/odoo#98423
Related: odoo/enterprise#30946
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* website_event, website_slides
Note that `restricted_editor` is the new technical name used instead of
`publisher`
Before this commit, the `is_restricted_editor()` method was actually
checking for `designer` rights and not `restricted editor` ones.
Indeed, a restricted editor (previously publisher) never had the write
right on ir.ui.view.
Despite the method name being wrong, it was still correctly used where
we actually checked for designer rights and not publisher/restricted
editor ones.
Also, the method was checking for write access on ir.ui.view instead of
checking directly if the user had the related group.
While it wasn't really wrong, it was also including people who would
have the write right on ir.ui.view but were not part of the designer
group.
This doesn't really makes sens, as we don't want someone which received
that write right on ir.ui.view from another module (not related to the
website) to be considered as a website admin -> we don't want to show
them website admin UI and stuff like that.
The method could have simply be renamed to `is_designer()` and could
have just checked for `has_group(designer)`, but having such an helper
seems overkill, we would end up with as many utils as there is groups.
At the end, this PR:
- removes the confusing util method
- replace it by has_group checks
Part-of: odoo/odoo#98200
* portal, web_unsplash, website_*
This commit renames the `website.group_website_publisher` into
`website.group_website_restricted_editor`.
While the change in itself might look unuseful, it will help the dev and
tech community figuring which group is related to which feature.
Even internally when we discuss specs, we always have to remind which
group is the restricted editor: the publisher one or the designer one?
While it is probably, after all those years, now anchored in some dev
mind, there is no easy way to directly figure which of those 2 groups is
the restricted editor one.
Note that I myself always got confused about it.
Now, the "Restricted Editor" right will be reflected in its technical
name `group_website_restricted_editor`.
Same as for the "Editor & Designer" which technical name is
`group_website_designer`.
As we would like to have a fully working and ready system in v17 for the
community to be able to build themes easily, removing that dubious part
is a nice to have.
Part-of: odoo/odoo#98200
Followup of odoo/odoo@1a3e713
Bug
===
If the user doesn't have the template editor, he cannot open the template
preview.
Technical
=========
The reason for that is because the web editor moves some CSS properties,
and so when the user tries to open the preview, an access error is raised.
Ideally, the template form view should not be editable if the access
rules do not allow it. But in _postprocess_tag_field, we only check
for access right because we don't have the record. So a user without
write access rules, but having write access right can edit the template
in the UI, and gets an error when saving.
Also, the web editor should not save the HTML value if no change are
made on the field (like all other text / char field).
To mitigate the issue in stable, we add a computed field that check the
access rules and make the body readonly if he can not edit the template.
So the web editor is not loaded, the CSS properties are not moved. Other
possible solutions are way to complex technically speaking (editor internals
to update in frontend, complex comparison of html blobs in backend, cache
usage making fields_view_get override not working in all cases, ... )
As the HTML body look weird in readonly mode, add the same border as the web
editor.
Task-2845877
X-original-commit: dcf3ab5fb41aa9ef6e59b2155bfd192e551b6476
Part-of: odoo/odoo#99256
The goal of this revision is to get rid of the `groups_id` field of the model `ir.ui.view`.
- This feature wasn't really known or used by most developers,
and not straight-forward to understand.
Removing it allows one less complicated thing to learn for developers.
Besides, thanks to odoo/odoo#95729,
changing the behavior of the `groups=` attribute,
we can easily get rid of this `groups_id` feature
by simply adding `groups=` in the elements of the views
using the `groups_id` field, it will have the same effect:
adding the elements in the view only for the users part of the specified group.
- By getting rid of the groups_id many2many field on ir.ui.view,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the groups_id groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
Part-of: odoo/odoo#98551
This commit converts the old "slide_category_one2many" field to the new
WOWL field API.
Part-of: odoo/odoo#97984
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
The `ratio` class used for embeds creates a static context.
Using `position: relative` for the subsequent element makes sure it doesn't
end up 'under' the embed on large viewports sizes.
For simplicity, we chose to not test for the actual presence of an embed
or window size before applying position-relative on the next div.
Task-2663320
Part of odoo/odoo#79615
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
* = blog, forum, slides
For performance reasons, allow to increment multiple fields of the same record
within the same query.
With python tests.
Task-2663320
Part of odoo/odoo#79615
The layout of slides needs a little freshening-up.
### Comments and slides
* The ratings are only showed once, and only for "documentation" contents
* Indications of why the user cannot post a comment are added (signing up,
Karma, commenting not allowed), and the portal template is not called if
there is no comment and commenting is not allowed (for user or course).
In addition, the "Comment" tab is never hidden anymore, to not hide
the available/activate-able features.
* Detailed view statistics are now shown only to selected users.
* Slide public views represent views by the public and all users that
are not members of the course.
* When channel/slide images are not set or inaccessible, a default image
is used (instead of plain background or unauthorized requests).
* These images are now editable on frontend.
* The 'Additional Resources' subtitle is hidden from the detailed slide view
for invite-only courses as nothing else was shown with it.
### Misc.
* This commit also fixes the "unresponsive" `total_views` count after public
views, by manually incrementing it too. This is required because `public_views`
is directly updated via SQL query and does not trigger model _computes.
* We also adjusted the test in survey that used a public user while in all
cases users must be logged-in (and therefore get portal privileges) before
they can participate.
Task-2663320
Part of odoo/odoo#79615
Just doing the summer file cleaning. Move mail data into files named based on
their model, easing maintenance and searching for those data.
Spotted during Task-2207626 (Rating: Delay rating notification to ease feedback)
Part-of: odoo/odoo#98661
Currently, bold style intensity on text is lost when switching from default
browser mode to full-screen mode for viewing e Learning Course content.
This happens due to the use of the `fw-light` class in full screen.
This class property is font-weight: 300 !important, so it overrides the
font-weight style property in the child element of this class.
This commit solves this issue by removing the `fw-light` class in the
full-screen record set.
task-2850325
closesodoo/odoo#91732
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
With the conversion to the new views, legacy x2many fields go through a
thin and incomplete compatibility layer to talk to the new model. This
compatibility layer is not very robust and as such most custom x2many
fields are broken in this configuration, in this case the field
"slide_category_one2many".
The proper fix is to convert this field widget, but in the mean time,
the simple fix is to force this view to keep using the legacy view
instead of the new view.
closesodoo/odoo#97936
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Reproduction:
1. Install Website and eLearning
2. Add new language Dutch
3. Modify the course responsible’s name as “Gertjan Kleinbloesem” in
eLearning
4. Open the course page in the website app and switch to Dutch, the
responsible name is over flowed
Reason: The background container doesn’t adapt to the length of the text
Fix: Add text break to the responsible's name so it won't break the
style
opw-2862250
closesodoo/odoo#97839
X-original-commit: bb2045f77ee7383af85b2d65c015d91f92b20647
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Liu Jinjiu (jili) <jili@odoo.com>
The navigation bar inside the Courses main page and the courses list
are forced to white with an inline style.
When a dark palette is used it makes the text color white as well.
Because of this the texts in those navigation bars cannot be read
anymore.
This commit removes the forced white background so that colors can
automatically adapt to the palette.
Steps to reproduce:
- Pick a dark palette.
- Go to the "Courses" page.
=> "All courses" and its icon were not visible anymore.
task-2855511
closesodoo/odoo#97148
X-original-commit: 852acad7585fa884f365dd2fc10348446d56d4e9
Related: odoo/enterprise#29995
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Adapt the wording since the edit button is not always on the top
right corner but can also be on the top left one. Also make the
info alert non editable, and add a placeholder to indicate the
editable area.
Task-2924229
closesodoo/odoo#96371
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
> Media query mixins parameters have changed for a more logical approach
> media-breakpoint-down() uses the breakpoint itself instead of the next
> breakpoint (e.g., media-breakpoint-down(lg) instead of
> media-breakpoint-down(md) targets viewports smaller than lg).
> Similarly, the second parameter in media-breakpoint-between() also
> uses the breakpoint itself instead of the next breakpoint (e.g.,
> media-between(sm, lg) instead of media-breakpoint-between(sm, md)
> targets viewports between sm and lg).
https://getbootstrap.com/docs/5.1/migration/#sass
Task ID: 2766483
Part-of: odoo/odoo#95450
Due to the removal of btn-block we need to change the display to grid
> Dropped .btn-block for utilities. Instead of using .btn-block on the
> .btn, wrap your buttons with .d-grid and a .gap-* utility to space
> them as needed
https://getbootstrap.com/docs/5.1/migration/#buttons
Task ID: 2766483
Part-of: odoo/odoo#95450
> Data attributes for all JavaScript plugins are now namespaced to help
> distinguish Bootstrap functionality from third parties and your own code.
> For example, we use data-bs-toggle instead of data-toggle.
https://getbootstrap.com/docs/5.1/migration/#javascript
Task ID: 2766483
Part-of: odoo/odoo#95450
- BS5 uses native inputs instead of pseudo-element for some
input like checkbox, radio, ...
in BS5 input checkbox don't have "virtual visual" checkbox anymore
(::before), so we remove the relative's rules
- removed `.custom-control` class
- `form-switch` use a new layout system in BS5 we adapt the code to
match the Bootstrap approach (inline SVG).
- In tests, we don't check the exact value of the background as it
change in community/enterprise, and it's difficult to check the value
of an SVG.
- Overflow in progressbar is now hidden.
-> we had to restore it.
- In BS5 margins in forms/inputs has been changed
-> we had to restore it (e.g. 'mb-3')
- .form-group, .form-row, .form-inline
> Dropped form-specific layout classes for our grid system.
> Use our grid and utilities instead of .form-group, .form-row,
> or .form-inline.
- .input-group-append and .input-group-prepend
> Dropped .input-group-append and .input-group-prepend.
> You can now just add buttons and .input-group-text as direct
> children of the input groups.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#forms
Task ID: 2766483
Part-of: odoo/odoo#95450
- modal 'show' option doesn't exist anymore
-> We need to call .show()
- by default, show is not the default
-> we need to call .show() explicitly.
- generic close button for dismissing content like modals and alerts.
- BS5 modals needs `modal-dialog` class to work
- normally we need also to add `modal-content` class but as the original
XML don't have this nested level of div we don't use it, but instead
we add `pointer-events: auto` for all children `DIV` of `modal-dialog`
-> See DocumentViewer
Task ID: 2766483
Part-of: odoo/odoo#95450
From [1]:
> Dropped all .badge-* color classes for background utilities
> (e.g., use .bg-primary instead of .badge-primary).
We now have to manage constrast for some badge. It's why we
add 'text-dark' at some point.
Note:
Due to the backport of 'text-bg-#{theme}', we can use this to
avoid to use 'text-dark'.
Ref:
[1] https://getbootstrap.com/docs/5.1/migration/#badges
Task ID: 2766483
Part-of: odoo/odoo#95450
* restore position relative:
> Columns no longer have position: relative applied, so you may have to
> add .position-relative to some elements to restore that behavior.
https://getbootstrap.com/docs/5.1/migration/#grid-updates
Example:
Favorite widget isn't shown on the right location due to change
in Boostrap 5, so we restore the old positioning of the `.col`
PS: another fix is to simply remove the position absolute of
`.o_favorite` but its break the favorite in kanban project.
* remove usage of `width` in kanban image when `col` is also used:
The class `o_kanban_image` is
```css
.o_kanban_image {
width: 64px;
}
```
In BS4 the col rules are:
```css
.col-4 {
flex: 0 0 33.33333333%;
max-width: 33.33333333%;
}
```
and in BS5:
```css
.col-4 {
-webkit-box-flex: 0;
-webkit-flex: 0 0 auto;
flex: 0 0 auto;
width: 33.33333333%;
}
```
So `width` overrides the `col` rules.
To summarize:
In BS4
```css
{
max-width: 33.33333333%;
width: 64px;
}
```
In BS5
```css
{
width: 33.33333333%;
width: 64px;
}
```
e.g. where there is the case:
Helpdesk > Reporting > Customer Ratings (Kanban card)
Task ID: 2766483
Part-of: odoo/odoo#95450
The logic not identical in BS4 -> BS5
The color contrast system in BS5 relies on WCAG 2.0 contrast algo.
So color-yiq is converted to color-contrast.
Note that there are some "texts/buttons/other visuals" elements
which will not have the same contrast as before.
$yiq-text-dark and $yiq-text-light are respectively replaced with
$color-contrast-dark and $color-contrast-light.
Note that we had to use '$min-contrast-ratio: 2.2' for .o_tag_color_X badge.
Task ID: 2766483
Part-of: odoo/odoo#95450
Co-authored-by: Stefano Rigano <sri@odoo.com>
This commit is a hack for Bootstrap 5
In Bootstrap 4 these variables was used with map-merge()
In Bootstrap 5 these variables has set only if they don't exist before
PS: Another fix will be to reorder all bundle to follow Bootstrap
documentation and do another logic that wasn't use before.
Ref:
https://getbootstrap.com/docs/5.1/customize/sass/#colors
Task ID: 2766483
Part-of: odoo/odoo#95450
It allows to always have a OdooResponse Object and don't allow redirect
to external except when you allow it explicitly with local=False.
Always return to a local url:
/website/add
/slides/slide/<model("slide.slide"):slide>
/microsoft_outlook/confirm
Allow previously external redirect without reason, now blocked
/website/lang/<lang> -> open redirect
Allow external redirect for good reason and url is controlled by code.
/social_facebook/redirect_to_profile/
PS: HTTP Code 303 is a better default for generic redirects. It's not
historically the default for werkzeug.utils, but it is what we want in
general. Contrary to 302, there is no browser-dependent behavior, and
no risk of asking the user whether they want to accept the redirect if
the original method wasn't GET. It's always a non-permanent GET on the
target location.
closesodoo/odoo#95019
X-original-commit: 77f8d9c5d96a9274785ffc2ad83b95ea157d26ad
Related: odoo/enterprise#29000
Signed-off-by: Olivier Dony <odo@odoo.com>
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit makes various adapations in addons with respect to
the introduction of the owl kanban view. Mainly, some selectors
in scss and in tests needed to be adapted. Moreover, in some tests
that we haven't adapted yet, we must ensure that legacy form and
list views are still used (useLegacyViews).
It also contains some adaptations in kanban templates, e.g. the
replacement of moment by luxon, the removal of underscore...
Part-of: odoo/odoo#92475
Render safe option was used with Jinja rendering to tell Jinja that content
was safe and was not expected to be escaped. This was used notably in subject
as characters like ``&`` was escaped in email subject (e.g. `R&D News`).
This is now supported directly by the "inline template" rendering engine that
is used to render text-based templates since Odoo v15 [1]. This option is not
supported by code anymore anyway and leads to nothing.
Task-2088884 (MailComposer: Onchange to editable computed stored)
Task-2710804 (MailThread Api Cleaning)
[1] See odoo/odoo@68182baff4
Prepares Task-2088884 (Mail: Composer Onchange to Editable Computed Stored)
Part-of: odoo/odoo#94660
The createChatterContainer helper was used during tests to mount
a chatter container and test it. However, this approach is not
very realistic and blocks some waiting PRs. In order to get closer
from the reality, let's mount a webClient and open a form view
containing a chatter.
closesodoo/odoo#94175
Related: odoo/enterprise#28684
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Goffin Simon