As a stable fix, to not touch XML templates and break existing
translations, the ⌙ character was automatically replaced by └ which
makes more sense for the usecase and should work properly in all
browsers. The ⌙ character is actually rendered mirrored on Windows 11
Chrome (and others) as the font used for those unicode characters is
left to the browser. We could force a font of our own but it's probably
not worth it.
A better solution with a SVG or CSS solution has to be done in master.
That would unify the look of the symbol across all browsers and
also prevent special characters to be placed in translations.
With this forward-port commit, we'll start first by using └ via a CSS
rule. Three new classes have been created: o_we_sublevel_1,
o_we_sublevel_2 and o_we_sublevel_3. Adding any of them on a widget
automatically adds the └ character. Then choosing 1, 2 or 3 controls
the indentation, which was previously controlled by placing the  
HTML entity directly inside strings.
This commit also takes the opportunity to fix some of those level
indentations (sometimes 2 was used instead of 1 or 1 was used instead of
2, etc) and also review some related labels.
closesodoo/odoo#97361
X-original-commit: e5d45643598671077ade7e41f0dbfe2b502665b8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
* website_forum
Portal users cannot insert images in the WYSIWYG, eg in a forum post.
Steps to reproduce:
- Install website_forum
- Connect as portal
- Go to the forum and create a new post
- Type '/image' and try to insert an image
- An Access Error is raised preventing the portal user from inserting an
image
History:
- It was possible in version earlier than 15.0 before the new editor, as
it was using a base64 inplace image upload to bypass the access rights
and avoid creating an attachment.
- It was broken in 15.0 with the new editor which doesn't have such a
mechanism. The image upload was then disabled for those users in 15.0
with [1] to avoid that bad UX with those errors/tracebacks.
- It was decided to implement a clean solution in master and see from
there was will be done with 15.0 (as being able to upload an image on
a forum seems quite critical).
Solution here in master to be able to use the media dialog:
- First issue, about opening the media dialog:
It fetches attachments, which is raising some access errors. We now
catch the error silently and return an empty list.
- Second issue, about upload an image (and thus creating an attachment):
We now create attachments with sudo to allow access to portal users,
but only if he has write access on the model.
[1]: https://github.com/odoo/odoo/commit/e453d4c119a69f285d9a014babe485492bbe9c40
opw-2648770
task-2811325
closesodoo/odoo#82612
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Merlin (megu) <megu@odoo.com>
> 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
* data('bs.popover') is not a jQuery data anymore
-> fetch data from the instance instead.
* use the new class name 'popover-arrow' instead of 'arrow'
* website_forum: offset is not a number anymore
-> Convert to string instead.
* BS5 event listener: 'focus' -> 'focusin'
* use `mouseover` event to show and `mouseout` to hide.
* disable at some point the animation to avoid remaining listener
in the DOM.
Ref:
https://getbootstrap.com/docs/5.1/migration/#popovers
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>
A forum tag is always linked to a forum.
But some flows are not considering that part and are returning/using
tags from other forum too.
Step to reproduce, having 2 forum `Cats` and `Dogs`:
- Create a `Food` tag on the `Dogs` forum
- On the `Cats` forum, type `Food` in the tag input
- First error: the `Food` from `Dogs` incorrectly shows up
It means that the user can't create a new one from the `Cats` forum
but will actually have to select (without know it) the one from the
`Dogs` forum.
- Select that tag anyway
- Second error: The tags displayed on the post is redirecting to the
wrong other forum, ultimately not showing the post from all forums
(and the one you just came from).
- Third error: The /tags page won't list the `Food` tag on the `Cats`
forum.
Note that there is probably some access traceback involved in a multi
website and/or multi company setup.
After this commit:
- only the tags from the current forum will show up and be selectable
when creating a post.
- it will be possible to create a new tag for a forum is another forum
already has a tag of that name
- the tag on the post (next to its title) will not redirect to the
incorrect (and possibly not accessible) forum
Note that the method was already reading multiple properties of `self`,
it was already not an `api.model` method anymore.
closesodoo/odoo#94917
X-original-commit: 4ff52d0b9a71d3072f5973d8e900d802e6b129c0
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: hoangtiendung <hoangtiendung070797@gmail.com>
*: website, website_blog, website_crm, website_event, website_forum,
website_hr_recruitment, website_mass_mailing, website_sale,
website_sale_loyalty, website_slides
This commit adds the current website displayed view xmlid outside of the
iframe, on its container, so that the tours registered with
registerThemeHomepageTour can continue to prepend their triggers with
the view xml id.
Introduce registerEditionTour: this function will allow tour maker to
more easily register a tour that needs to start in the iframe's backend
and go in edit mode.
See merge commit for more information.
task-2687506
Co-authored-by: Benjamin Vray <bvr@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
*: web, web_editor, web_unsplash, website_blog, website_event,
website_forum, website_hr_recruitment, website_links,
website_livechat, website_sale, website_slides, website_twitter
This commit fixes two issues related to the loading the wysiwyg and
editor assets.
The media dialog components are now defined in a new assets_media_dialog
bundle, to make them available both in the frontend (needed to post
comments on the forum for example), and in the backend (used in the
context of the wysiwyg edition or in the seo dialog). Ideally, The media
dialog component would lazy load its own bundle, but right now, it is
not possible when used in a ComponentWrapper.
The wysiwyg assets are now completely loaded in the frontend, after
creating the website root, when the frontend is displayed in an iframe.
It would be better if the frontend loads only what it needs of the
wysiwyg assets (some editor classes and the drop zones css), an
improvement would be to create an assets_wysiwyg_frontend or
assets_wysiwyg_minimal bundle.
The website edition components are moved to the assets_editor bundle.
For now, this bundle is included in the backend and the edition menus
are hidden from the users that are not website publishers. Ideally, the
client action would lazy load the assets_editor, only if the user is a
website publisher.
Many optimizations regarding assets will be done post-merge.
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_links,
website_livechat, website_slides, survey, web_editor
This commit removes the website navbar root widget, as the edition is
now handled in the backend through the client action and custom menus.
It removes associated widgets and their css.
See merge commit for more information.
task-2687506
*: website_crm, website_crm_partner_assign, website_customer,
website_forum, website_hr_recruitment, website_membership,
website_slides, website_slides_forum
This commit adapts "customize show" options from several website modules
by creating new options available in edit mode.
See merge commit for more information.
task-2710582
*: 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 add dialogs to create new website content
using a 'target:new' action on the form view and an overridable
"website" form controller.
See merge commit for more information.
task-2687506
*: website_event, website_forum, website_slides
As the first commit of the merge of this work at [1], this moves files
without modifying them to preserve code history and ease forward-ports.
This part is about moving static XML to non-static files where the
XML will be changed into view definitions (as some UI now become normal
backend views). This cannot be a standalone working move of course.
So it was not done in the first commit but here, just before the
relevant commits of the merge.
[1]: https://github.com/odoo/odoo/pull/89223
See merge commit for more information.
task-2687506
*: website_blog, website_event, website_forum, website_hr_recruitment,
website_livechat, website_sale, website_slides
The NewContentModal component is added. It displays tiles, which will
install a module if not already installed, or perform an action defined
by the module otherwise. So that modules can patch that component to
define an action when installed (for example, website_sale will handle
the logic of creating a new product), the elements to displayed and
their state (NOT_INSTALLED, INSTALLING, INSTALLED) are listed in the
state of the component.
A key 'isDisplayed' is added on the new content elements that should not
be displayed to the user, depended on his security groups.
By default, the new content elements are displayed to the system user.
See merge commit for more information.
task-2687506
*: web_editor, web_unsplash, website_event, website_blog,
website_event_meet, website_forum, website_links, website_livechat,
website_sale_slides, website_slides
With [1], many files will move as the website UI is moved in the
backend. This commit moves all the static files (JS/CSS/XML) to their
final destination without modifying them, in an attempt to preserve
some history and ease some forward-ports.
After this commit, everything works as before as the files are simply
renamed and the references to them adapted.
However, technically, many files will actually be split into multiple
files by the work made with [1]. While it is theoretically possible to
preserve history over multiples files, this would require inner merge
commits, which does not go well with robodoo. In those cases, the "main"
file of the split was chosen. Mainly, 4 worth-noticing splits were
detected (and so the history moved only to the first file):
move: addons/web_editor/static/src/js/wysiwyg/widgets/media.js
to: addons/web_editor/static/src/components/media_dialog/file_selector.js
- addons/web_editor/static/src/components/media_dialog/search_media.js
- addons/web_editor/static/src/components/media_dialog/image_selector.js
- addons/web_editor/static/src/components/media_dialog/document_selector.js
- addons/web_editor/static/src/components/media_dialog/icon_selector.js
- addons/web_editor/static/src/components/media_dialog/video_selector.js
move: addons/web_editor/static/src/js/wysiwyg/widgets/upload_progress_toast.js
to: addons/web_editor/static/src/components/upload_progress_toast/upload_progress_toast.js
- addons/web_editor/static/src/components/upload_progress_toast/upload_service.js
move: addons/website/static/src/js/menu/content.js
to: addons/website/static/src/components/dialog/edit_menu.js
- addons/website/static/src/components/dialog/page_properties.js
- addons/website/static/src/components/wysiwyg_adapter/page_options.js
- addons/website/static/src/js/website_page_list.js
move: addons/website/static/src/js/menu/edit.js
to: addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js
- addons/website/static/src/systray_items/edit_website.js
- addons/website/static/src/components/editor/editor.js
Notice that as those moves were made post-work and the rest of the work
(80+ commits) rebased on top of it, some commits may remove more than
they should in a moved file to then reimplement some of what was
removed in a later commit... ideally this should have been avoided of
course but keep in mind that the final files are just entirely rewritten
and split as converted to OWL. It seemed however worth it to keep most
of the inner history of the work made here to see step by step what was
done. [1] will obviously be merged with a merge commit, binding the
whole work together.
[1]: https://github.com/odoo/odoo/pull/89223
task-2687506
Purpose
=======
In message_notify, when called on a recordset, call model methods instead of
base one defined on MailThread. This allows to use internal methods overrides.
Also perform some linting on calls to ``message_notify`` in order to better
spot calls, parameters, ...
Task-2852908
closesodoo/odoo#92868
Related: odoo/enterprise#28038
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Using lazy values allows you to not do query when the content is not
displayed or if it is already cached. Adding `t-cache` only reduces
render time, but combining it with lazy values saves browses, computes
and query.
Thus for the `/shop` page the page is displayed in 60ms (before: 250ms).
Part-of: odoo/odoo#88276
Users with 30 karma cannot use images in their forum post
Steps to reproduce:
1. Install the Forum app
2. Change the portal user's karma to 30 (you can use this command in
psql: `UPDATE public.res_users SET karma=30 WHERE id=7;`)
3. Connect as portal
4. Go to the forum and create a new post
5. Add a title and an image to the post and validate it
6. An error message is displayed preventing the user from posting the
image even though he should be able to
Solution:
Adapt the condition on the user's karma
opw-2648770
closesodoo/odoo#92556
X-original-commit: 43c2cbab6947628f58b5edc33d618e50d927f624
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Merlin (megu) <megu@odoo.com>
Currently all iterations share the same dictionary. We have to copy the
default dict in order to have a distinct copy for each id in the loop.
Task-2826303
closesodoo/odoo#89934
X-original-commit: ae145e0909d5f37964eace75053eadf9e8b80c36
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Order of karma needed is ascending now.
closesodoo/odoo#89087
X-original-commit: b29bfd65c6f55cd9ff4f8a899d8648bb8ba000ca
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Currently, when accessing a URL with a sorting encoded value,
the system will raise an error with a specific message, which
feels unfriendly to the user as well as saves unnecessary logs
in the log file. So we decoded that value, if except then sort
a page without sorting.
closesodoo/odoo#89072
X-original-commit: 33356fcc9867ee23fee2a032dcca7daea1ada4c5
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The website_forum_share_templates does not exclusively contain templates
to the forum share widget since the addition of the toolbar template.
Renaming the file to public_templates arguably makes more sense.
task-2749467
closesodoo/odoo#85998
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
An extra xml dependency was inadvertently added in the ForumCreateDialog in
commit [1] by inheriting the web_editor.toolbar template, since the file where
it is inherited is an xml dependency of the ForumCreateDialog widget. While the
dependency is correctly loaded in the public widget it is not in the creation
dialog widget, resulting in a crash.
Furthermore, the ForumCreateDialog widget does not actually need this template
and neither does the public widget need the other templates already present
in the same file at the time of the mentioned commit. Moving the extended
toolbar template to the website_forum_share_templates file, allows for removing
of the unnecessary dependencies. This includes the missing dependency of the
ForumCreateDialog, preventing the crash.
[1]: 740168ce8d
task-2749467
X-original-commit: 4ad966de67278c2081c1896c354b9b1782cf6dc1
Part-of: odoo/odoo#85998
This commit modifies most of the usages of read_group and uses
_read_group instead. _read_group doesn't join automatically on the
many2one fields when no order_by is specified, making it more performant
when the "name" of the many2one is not relevant, which is the case for
most back-end cases
closesodoo/odoo#84908
Task-id: 2479334
Related: odoo/enterprise#24877
Signed-off-by: Raphael Collet <rco@odoo.com>
Remove str from IdType, because those kinds of ids are no longer
necessary, and lead to unusable recordsets.
Because IdType now only contains int and NewId, simplify (and speed up)
the conversion of the parameter of browse().
Preferably wrap single NewId into a tuple instead of a list, as tuples
are faster.
closesodoo/odoo#83687
Signed-off-by: Raphael Collet <rco@odoo.com>
Reduces load_menus answer size by 32% (between 20kb and 200kb savings
for the initial loading of the backend, depending on the number of apps
installed). Support for SVG icons in the web client for menus/apps.
Reduced PNG icons for apps list (8 bits PNG instead of 24 as our icons
don't need more colors as they are flat designs)
closesodoo/odoo#84280
Related: odoo/enterprise#24200
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Purpose of this commit is to make ``get_access_action`` private as it is not
necessary to expose it directly. Website management is also made explicit
using a ``force_website`` parameter instead of relying on context key of the
same name. This allows to better understand the method code flow.
Contains also some code fix / improvements :
* Website forum: update code to better skip the frontend redirection if the
forum is not active and frontend is not forced;
* Website slides: respect force website parameter in redirection;
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
PURPOSE
Global purpose is to rename some methods and add some docstrings to clean
API of notification methods used in mail thread. Notably use _notify_thread
prefix for main methods, and _notify_by_'mean' for tool sub-methods.
SPECIFICATIONS
Remove unused arguments coming from old implementation and usage. They were
introduced notably for performance reason when cache was more often invalidated
which is not the case anymore. Anyway when parameters are unused it is always
better to remove them.
Remove ``notify_by_email`` parameter in ``_notify_thread``. It is only used
in channels to avoid notifying people of some automated notifications. The
same behavior has been cleanly implemented at odoo/odoo@018820d .
Rename methods, starting with ``_notify(_records)`` to ease their grouping
and understanding. Add some additional prefixes like ``_notify_by_'mean'``
and ``_notify_get_recipients`` for recipients related computation. Add some
docstrings, notably when parameters usage is not clear.
Some linting is also performed in updated actions, just to lessen styling
issues notably on runbot.
This commit should not change anything functionally as it contains only
some renaming and docstrings updates as well as some outdated parameters
removal.
Task-2710804 (Mail: Clean Mail.Thread API)
Part-of: odoo/odoo#82167
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
website{_*}: website, website_blog, website_event, website_forum,
website_sale, website_slides
Since the generic search bar was introduced in [1] all text fields were
truncated in search results.
This caused problems for long URLs which were truncated as well, and
therefore could become invalid.
After this commit URL fields specify `'truncate': False` in their search
detail metadata, which informs the rendering to skip the text truncation
step for that field.
Also added previously missing controller-level tests of the
autocompletion.
Steps to reproduce:
- start odoo with website_forum and demo data
- go to the Help forum
- search for "configure" in the Help forum
- click on the auto-complete suggestion
- => redirected to a 404 page because the URL was shortened
To test the fix on other models, use a long enough name that causes the
problem. E.g.: "This product has such a long name its URL would have
been truncated without the fix contained in this branch".
Note that the problem did not occur on blogs because the URL does not
contain the name, but the same fix was applied for consistency.
[1]: https://github.com/odoo/odoo/commit/7559626c54e34b41e1549e28276a650accec6986
task-2727788
closesodoo/odoo#82621
X-original-commit: 045f741be35e62f5e3a636490c6c1d475b5d78eb
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
The enterprise module website_helpdesk_forum changes the demo data
karma_answer value to 0 for the default Help forum thus breaks the tour.
odoo/enterprise#19870odoo/upgrade#2681closesodoo/odoo#74353
Taskid: 2499623
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The origin parameter must be an absolute link (starting with a /)
To be consistent and always have a leading slash (and avoid relative
links if the developer forgot to add a leading slash)
Since #45352, the dropdown actions "Edit" / "Close" / "Delete" were no
longer working; clicking on them was not submitting the form like it was
supposed to.
closesodoo/odoo#81156
Taskid: 2499623
X-original-commit: 2e7cb0e19a81598f3e52660753b925b3f2216a6d
Signed-off-by: Kevin Baptiste <kba@odoo.com>
This commit improves forums and forum posts list views. The changes are listed
below.
Forums list view:
- optional hidden `total_answers` and `total_favorites`
- added `slide_channel_id` and `visibility` fields
- added sum for `total_posts` and `total_views`
Forum posts list view:
- added badge widget on `state` field for better decoration
- added sum for `views` and `child_count`, updated their label to
'# Views' and '# Answers'
- removed `favourite_count` field
- moved `website_id` field at last as optional hidden
- added title for the demo data in which title was missing.
TaskID-2607467
Part-of: odoo/odoo#76930
Currently, when user open the question from helpdesk ticket and
user clicks on the back button of the forum page,
it redirects the user to the app switcher. It happens because the
back button contains the homepage URL as httprequest.referrer
does not support the fragment url with hash(#).
so this commit fixes the issue by binding the onclick event on the
back button so clicking on the back button redirects the user
to the helpdesk ticket.
task-2602604
closesodoo/odoo#77458
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Purpose
=======
This commit is enhancing the website_slides module.
Specifications
==============
It changes placeholders for certain fields, it changes helpers in some
of the views.
It updates some of the main views of the menus and corrects wordings
inside of them.
It activates the Graph and Pivot views for the reporting of
Courses, Reviews and Quizzes.
It cleans up some of the measures inside of the Pivot and Graph views
of each menus where it is available.
It also merges 2 models: slide.slide.link and slide.slide.resource into
slide.slide.resource with a type Selection field.
This is done in order to create a single table for the additional
resources of a Content.
It also improves the front-end of the module with minor changes.
It fixes the problem of long names inside of breadcrumbs.
It also adds a message when there is no leaderboard in /profile/users.
task-2597345
See odoo/enterprise#20480
See odoo/upgrade#2784
Part-of: odoo/odoo#75646
Before Odoo saas-14.4, one should call `_get_http_domain()` on website to get
its domain. Indeed, that method was in charge of cleaning that domain, as it
was done with commit [1].
Since Odoo saas-14.4, that cleaning is automatically performed on domain before
saving it into database, thanks to commit [2].
Thus, we can now remove the `_get_http_domain()` and use directly the domain as
it is considered clean.
Note that migrated databases coming from version older than Odoo saas-14.4
could still have an incorrect domain (trailing slash, no scheme..).
This will be handled during migration with [3].
[1]: https://github.com/odoo/odoo/commit/3ad775aab717b395a5d11527aeb3596af66afa99
[2]: https://github.com/odoo/odoo/commit/042c95b0219bb0aa13e73385e092fa76ff1a1b0a
[3]: https://github.com/odoo/upgrade/pull/2951closesodoo/odoo#78766
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
qsm-odoo