* website_forum
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the website 'animation' system was 'extended' to vaguely use a
'Registry' instance instead of an object. This was however left
undocumented, with a require in the middle of a file, restarting all
animations when used, only used by website_forum... with more code for
no reason at all, ...
This commit restores the system to the way it was before and re-adapts
website_forum:
- No need to check if website_forum is in the DOM as it is already
checked by the animation system (on top of that... the new code was
checking the DOM before it was ready...).
- No need of a dynamic add on a registry, this is always done before the
DOM is ready, so before the animations are started.
- No need to know the root instance in website forum, just use the
animation as the Wysiwyg instance's parent.
The goal of this commit is also to avoid useless conflicts with
https://github.com/odoo/odoo/pull/29442 (that should not have had any
conflict at all as totally independent of the editor task...)
closesodoo/odoo#30478
* website_forum, website_gengo, website_mail_channel, website_sale
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the web_editor.context module was moved to website without being
renamed. This commit renames it to website.context but also merge the
website extension that was made to that context directly within its
definition.
closesodoo/odoo#30409
* auth_password_policy_signup, auth_signup, website, portal, survey,
web_unsplash, website
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775
web_editor.base has been moved to website while it was still used by
frontend pages which do not depend on website (especially portal).
This commit moves web_editor.base to portal while waiting for
https://github.com/odoo/odoo/pull/29442. It also removes the unnecessary
dependencies to it in non-portal pages (in survey for example).
* web_editor, website_blog
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the media dialog was refactored but the code which used it outside of
the editor was not adapted at all. Also, the selected image was not
saved correctly anymore, making the media dialog useless outside the
editor in the current implementation.
- Adapted SEO image uploading and body image background choice which
were not working anymore
- Adapted blog cover choice and gallery snippet which were strangely
still working even though there were sending wrong parameters during
media dialog initialization
closesodoo/odoo#30416
* web_editor
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the editor dialog and the switches crashed on their use in website.
This is because the merge split some xml files without adapting xml
dependencies... this commit only takes care of code which depended on
'/web_editor/static/src/xml/editor.xml'.
closesodoo/odoo#30408
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the customize theme dialog was not opening anymore.
This was due because, somehow, the editor's merge changed the theme
dialog code for no reason.
closesodoo/odoo#30365
The refactoring also had to be done in order to create a set of unit
tests.
Each behavior can be tested, including the behaviors performed as a
consequence of keyboard interactions (for instance: Enter, Tab...).
This commit also contains some changes to test_utils that were
necessary given the new structure of the wysiwyg editor.
Co-authored-by: Gorash <chm@odoo.com>
* Creating a new structure by transforming all the plugins in the
library using the odoo inheritance system. Plugins are easier to
implement with the AbstractPlugin to add Odoo behaviors.
* From now on, the methods of the library (in this case Summernote) can
no longer be called by other modules or files. Only the wysiwyg
widgets can access it, to simplify the updating process. The wysiwyg
object serves as an interface.
* Depending on the options the snippets will be loaded or not, the
editor will be in an iframe or not... all of this is transparent from
the outside.
* Regarding iframes, all controllers related to editing have been
removed: the new API no longer needs them. This speeds up loading,
eases testing and removes complexity for the same
features.
PUBLIC FEATURES
There are several public methods on the Wysiwyg class:
* Wysiwyg.prepare (WidgetParent): returns a deferred resolved when the
library (xml, lazy, assets...) is loaded.
* Wysiwyg.getRange (DOM): returns the range (selection in the dom)
* Wysiwyg.setRange (startNode, startOffset, endNode, endOffset): creates
a range (selection in the dom)
* Wysiwyg.setRangeFromNode (DOM, options) that creates a range from an
element (option available to select all, start or end)
A jQuery selector was added: :o_editable, which indicates whether the
current element is editable. That is, if it is contained in a tag with
the attribute 'contentEditable = "true"' or in a tag with the class
o_editable.
Several methods are also present:
* focusIn: makes a focus and places the cursor at the beginning of the
element
* focusInEnd: makes a focus and places the cursor at the end of the
element
* selectContent: makes a focus and selects the content
HTML FIELD
The HTML field can receive different options:
* style-inline: {boolean} transforms a class into an inline style when
saving and vice versa when reading.
* no-attachment: {boolean} prevents the use of attachments (in media
dialog)
* cssEdit: {xml_id} to use a template containing the css to loaded in
an iframe when editing
* cssReadonly: {xml_id} to use a template containing the css to load
into an iframe when viewing in readonly
* snippets: {xml_id} snippets template (can be used with or without
cssEdit)
* wrapper: {template} qweb static template (containing a tag:
id = "wrapper") that will include the content during editing (removed
on save)
MASS MAILING
A widget was created for mass mailing. There are now two fields:
body_html and body_arch.
body_arch contains the code with the class without conversion into
inline style, useful when editing and one with the inline style that is
visible in readonly mode and sent by email.
Advantage: no spreading errors, able to update css/theme, able to do
more changes when converting to inline style so that a maximum of mail
clients have an impeccable rendering.
Co-authored-by: Antoine Guenet <age@odoo.com>
The refactoring of the wysiwyg editor and 'html' field allows us to
move some of the code that was in web_editor but only used in website or
in mass_mailing. Some parts are still in web_editor but will be
moved at a later time.
- Improve the website tour (typo, tip positions, etc) and added new
steps to publish a new page
- Make close button of 'Mobile Preview' more visible
- Fix the overflow for long menu names in menu editor dialog
- Change the menu string from 'Affix Top Menu' to 'Fixed Top Menu'
- Change theme customization dialog's title to 'Customize Theme'
from 'Customize this theme'
- Improve strings for Google Analytics
task-1895287
closesodoo/odoo#28199
Currently, res.partner has:
1. `website_id` field hardcoded in website module
2. `website_published` field from website `website.published.mixin` in
website_partner module.
At the end, the res.partner model has all the field of the mixin
`website.published.multi.mixin` without having the mixin.
As a result, we have all the multi-website fields but we don't have access to
the mixins methods & computes.
Now, we use the `website.published.multi.mixin` on res.partner in website
module even if `website_published` is not needed if website_partner is not
installed.
+ add tooltip to `website` field to prevent warning since 2 fields would have
the same label
closesodoo/odoo#29711
Since 12.0, some modal footer button order were changed. The primary button
would not be the one in the modal footer corner.
This is against bootstrap but more annoyingly, users are intuitively clicking
on the secondary button, ending up closing the modal and losing form
information they entered.
This commit simply fix the regression from 12.0 as before 12.0 these buttons
were positionned correctly.
Note that a commit in master (saas-12.2) will fix all the other ones that were
wrongly positionned before 12.0.
Step to reproduce:
- Go to an event having the possibility to register.
- Click on 'Register Now', a modal is shown to write details (name, email..)
- You intuitively click on 'Cancel' as it is the bottom right button
|________________________________ CONFIRM _ CANCEL _|
- The modal is closed, if you try to open it again your infos are lost
Closes#29884
task-1922120
* portal, web_editor
Anchor Link:
- Some visual improvements of the link dialog.
- New 'Page Anchor' field.
- System by default: top and bottom.
- Shows existing anchors.
Creation of the anchor:
- New option 'Anchor Name' to be able to create an anchor.
task-1913458
closesodoo/odoo#29150
Modal primary button should be the one in the corner (left if buttons aligned
left, right if buttons aligned right) as in the Bootstrap doc.
More than a simple guideline, the user will intuitively click on the button in
the corner as it is supposed to be the primary one.
Plus some DOM fixes (o_technical_modal was missing, H2 was too big especially
since BS4)
Closes#29890
task-1922120
* = account, sale_management, website
Settings that are using groups internally should not appear on the user form
without using debug mode.
The admin should not get the idea that he should configure those per user,
because they are going to be reset if/when changing the general setting.
closes#29842
PR: #29860
With multi-website support, the key field is more important than ever as it
kind of replace the xml_id behavior.
Thus, on the ir.ui.view list view it is usefull to see the key.
closesodoo/odoo#29419
to ControlPanel/Search view refactoring.
The ControlPanel being now inside the DOM of client actions, those
existing widgets needed to be adapted (in the way they define if
and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
*: tools, web, website, website_forum, mail, im_livechat
This commit refactors ir_http to make it more readable
and flexible.
Move the resize function of web/image to odoo.tools
Co-authored-by: XavierDo <xdo@odoo.com>
Co-authored-by: Antony Lesuisse <al@openerp.com>
closes: #28563
task: #1908896
With multi-website, activating a customize option (customize_show view) will
actually duplicate the customize view to make it specific.
By doing so, the duplicated view will have a higher ID than the original, and
the original's siblings customize options.
Before this fix, two issues could be seen:
1. When toggling a customize option, it would appear last in the dropdown
afterward. This is because of the views being sorted by (priority, id)
(if the views have the same priority).
2. When toggling, sometimes the views header would be duplicated. This comes
from the JS code that loop through the returned views and create the DOM
by adding a header when the view inherit_id is different than the previous.
Obviously, as 2 views with the same inherit_id could not be grouped together
now that the specific one has a bigger ID, it will create twice the DOM.
=> Check tests in this commit, they have schemas that will explain it clearly
Note: We don't take priority into account for customize menu view order as it
would create the same problem as (2.)
We could have sorted by (inherit_id, priority, name) to avoid the issue
and give the user possibility to order options in header but it was
decided we dont.
Closes#29347
Before this comit:
The `_views_get()` method would be called recursively for every
`inherit_children_ids`.
At the end of the method, we would get the complete view hierarchy, including
duplicate hierarchies for website specific copies (COW).
Then, the `get_related_views` that is calling `_views_get()` would be overriden
in website module to keep only most specific views.
But this would not be enough as it would leave orphans from other trees:
- Have a base view 'B'
- That has an inherited view 'I'
- That has itself an inherited view 'II'
- Now make the hierarchy specific on a website from 'I'
- And add another inherited view to 'I' on the generic tree
This become:
B
/ \
/ \
I I'
/ \ |
II II2 II'
As explained, filtering duplicates would not be enough as it would correctly
remove 'I' and 'II' from the generic tree but would not remove 'II2'.
At the end, it would return "B", "II2", "I'" and "II'".
Now, we correctly return only "B", "I'" and "II'" by ignoring generic trees
when there is a specific one.
Closes#29347
In a particular case, `_views_get` was mixing apples and oranges, ir.ui.view
and theme.ir.ui.view.
This was the case if a theme has a theme.ir.ui.view t-calling another
theme.ir.ui.view.
(Only theme's sale bridge cause this issue, eg theme_kea_sale.products)
Then, having that theme installed on a website would make all other website
without that theme to crash when opening the /shop customize menu.
Indeed, the theme.ir.ui.view would have the xml_id theme_kea_sale.search.
The generic view `website_sale.products` would have `theme_kea_sale.products`
as inherit child which is website specific and t-call `theme_kea_sale.search`.
Then, on a website witout theme_kea installed, opening the customize menu would
call `get_related_views` that would call `_views_get` that would loop through
inherit children calling `_view_obj` that would not find a view with that key
and would fallback on self.env.ref, finding the theme.ir.ui.view.
Note: `_views_get` might return specific view for another website but that will
be filtered on `get_related_views` override in website.
Step to reproduce:
- Have at least 2 websites and website_sale installed
- Install theme_kea on a website, it will also install theme_kea_sale
- Go on the website that has not theme_kea installed
- Go to /shop
- Open Customize menu, it won't load because of python crash
opw-1914576
Closes#29347
When there is a website with traduction (for exemple, Spanish and
French). In the Spanish website, at the SEO menu, you can add keywords
using any of the languages (Spanish or French), but these keywords are
only added to the Spanish website.
To avoid misunderstanding between the website language and the keyword
language a tooltip is added.
closesodoo/odoo#29683
Now forum only allow to post message of type 'question'.
New 'modern' UI with Bootstrap 4
New moderation modal for bulk spam
Co-authored-by: qha <qha@odoo.com>
Co-authored-by: qsm <qsm@odoo.com>
Co-authored-by: jke <jke@odoo.com>
Thanks to @qha-odoo for UI
Thanks to @qsm-odoo for reviewSsss
closesodoo/odoo#29235
Before this commit, the social media popover (used in forum but
available everywhere) may break over multiple rows if used on a relative
positioned small button. This however never occurred in standard <= 12.0
so we will consider this not a bug fix. This will however occur with
the upcoming forum refactoring, so we needed a fix for master.
This commit forces the social icons on one row and take the opportunity
to refactor the template to make a simpler and more beautiful popover
by using conventional icons and social media own colors.
closesodoo/odoo#29327
qsm-odoo