This commit e84779749b factorize the check of
special access to post a message using a token mecanism, but it breaks the
case without token. Indeed, on some models, it is allow to post a message
on a document when having a certain access. This is handle with the
`_mail_post_access` attribute on model inheriting mail.thread.
Using this mecanism, a user that can read (or write) the document can also
post a message. This is used in the eShop to review product and in blog to
comment blogpost.
This commit restore posting a message without token. the normal access rights
will be applied by message post and raise if the user can not post message,
taking `_mail_post_access` into account.
The balance is now restored in the universe.
Task-1902304
Add a new widget for binary fields. It open a dialog box and the user can sign manually,
or an signature can be draw automatically or he can upload a picture of his signature.
Move fonts, controller, scss,templates about signature from portal to web to avoid redundance
closesodoo/odoo#30222
* portal
The user can now choose the font-size of its header menu items through
the customize dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
* portal, web
This commit introduces the first of many-to-come non-color website user
values: the logo height. Now, the user can choose it in the customize
dialog.
PR https://github.com/odoo/odoo/pull/29624
task-1904244
To post a comment with a signed token, we compare tokens with the pid.
The token is signed with the pid, which is an integer. When checking
access, we compare the token with a pid as char. Obviously, the comparison
failed, and posting the message is refused, as the 2 'pid' does not
share the same type.
This commit cast the recieved 'pid' into an integer before checking
special access.
closesodoo/odoo#30906
When a portal user post a message to review a channel, we
want to allow him to edit its own comment and rating.
This commit modifies the special check access method in
portal to extract the security check and reuse it to
allow user to update its comment on slide.channel only.
We decided to reuse existing widget (new rating popup
composer) to do the message modification.
Task-1902304
Before this commit, it was possible to post a message on a document
the user has no access, thanks to a token. In addition to this token,
if a hash (signed token with a partner id), the author_id of the message
was forced.
This commit change a little bit that logic by distinguish 2 cases:
1/ Token only: anyone with the token can post a message on the document. If
the user is not logged (public with token), the author_id will be the
customer of the document (or the public user). This case is moslty used
for business document, through the portal or with the "share link" for
instance.
2/ Signed token: user has no write access to the document, but can post a
message on it. The user have to be logged, as the token is signed with its
identifier. The goal here is to avoid leaking the access token's document
to all visitors. This case is mostly used for public content, such as blog
posts, slides, ...
The token case was already existing. The second is now working with this
commit. To do so, it was required to
- move `_sign_token` from the portal mixin to mail.thread.
- transfering 'pid' and 'hash' parameters from the controller to template
to js widgets.
This commit also change the `_message_post_helper` signature by making
the 3 first parameters required, as to post a message you need at lease
res_model, res_id and the message body. The optional argurments and kwargs
are here to check the bypassing access rights mecanism.
Task-1902304
Rating document available on a website will become more common, but
we want to do it with different UI widget. This commit introduces a
new "popup rating composer": the idea is the rating average is
displayed with stars, and when clicking on it, a popup with the
composer appears. The user can so submit its review.
To do so, we factorize the Portal Composer into a dedicated widget
(instead of natively inside Portal Chatter).
Task-1902304
Before this commit, it was possible for the user to click on the Sign button
even when the signature area was empty, which would lead to an error message.
Now we disable the button when the area is empty.
Related to enterprise PR: https://github.com/odoo/enterprise/pull/3535
PR: #30653
BS3 used to add ::before and ::after elements on all containers so that
margins and floats are cleared inside containers. As lots of current
odoo layouts may rely on this for some alignments, this is restored (at
least for a while) here only for main containers of the frontend.
In master, we should use proper layouts to avoid the need of this.
task-1889238
closesodoo/odoo#30510
Before this commit, BS4 color for active list-group-item (white) would always
be overriden by our portal custom css to the BS4 color for inactive one.
Part of #29884
When using:
```
t-field="res_company.logo" t-options="{'widget': 'image'}"
```
the widget generates a `/web/content/` URL, which ultimately checks the
access rights in method `binary_content`. This means that if the user
doesn't have the `read` access rights on `res_company`, the logo won't
be displayed.
We use the `/logo.png` route instead since it bypasses the access
rights.
opw-1913665
Some features are common to portal and backend, such as the sign modal in
enterprise.
This commit uniformize the width of the modal to make it more consistent between
the two by default. Of course themes can still customize this behavior.
closesodoo/odoo#29521
* portal
In our default theme, when hovering links (or .btn-link elements), the
text is underlined. This effect is however not desired for links which
contain only an icon, especially in the forum.
This commit removes that underline effect for all icon buttons in the
frontend (at least by default, this is a theme choice). Icon buttons are
defined as link or .btn-link elements which directly use the "fa" class
on them.
This commit also solves the flag button of the forum which did not have
any effect because of bad bootstrap use.
closesodoo/odoo#29434
* payment, website_sale
This commit solves the problem described in the issues mentioned below
by using the new system introduced by the parent commit.
That new system is even more integrated with website "animations" but
the mentioned issues' features are not yet converted to use those (this
will be a master task to make "Website Widget" be defined in portal to
use all of those integrated features). This commit however converts an
already protected behavior of website_sale using that "animation"
integration.
Closes https://github.com/odoo/odoo/issues/27976
Closes https://github.com/odoo/odoo/issues/28704
Use a very very very light gray as body background color for
the website so that default white cards have some contrast with the
body. Also adapt the portal system to use the portal colors when the
body bg color is equal to that very very very light gray (while it was
compared to $white before).
closesodoo/odoo#29318
- The value returned by the method `_portal_ensure_token` is False due
to a cache issue.
The value is generated written using the `sudo` environment while in
the current user environment the cached value is `False`.
After generating the value, the cache is not cleared, thus letting the
method return `False`
closesodoo/odoo#28836
Purpose
=======
The goal is to avoid duplicate code between portal and sign (enterprise), and
also to allow the user to use the signature mode 'auto' and 'load' in portal
(before this commit only 'draw' was available in portal).
The sales order signature (currently the only portal signature) has been changed
to use this new code.
This signature widget has been improved:
Improved style:
- better structure and use of BS classes
- removed most of custom CSS
- made it more responsive
Changed code to follow guidelines, added JSDoc.
Technically
===========
New widget NameAndSignature common to portal and sign (enterprise).
Reworked existing portal signature form to use new widget.
Related to enterprise PR https://github.com/odoo/enterprise/pull/3266
task-1894903
closesodoo/odoo#29453
* base, portal, website, website_event_sale, website_event_track
- The previous event registration form was not clear on mobile
- Review some layouts to match the new design general idea, using cards
(see forum refactoring of https://github.com/odoo/odoo/pull/29235)
- Use correct bootstrap components (like a menu instead of a breadcrumb
on event pages)
- Review options to be able to disable the left / right column and
choose the exact options you want to appear in them
task-1858034
closesodoo/odoo#30559
Following the new editor's merge at https://github.com/odoo/odoo/pull/29775,
the 'web_editor.ready' module was moved to website without caring about
where it was used.
Fortunately the only non-website app which uses it is portal in a module
which in fact does not need it.
It would probably make more sense if it was in portal though (see
https://github.com/odoo/odoo/pull/30409) but as an upcoming PR is about
to fix those problems (https://github.com/odoo/odoo/pull/29442), this
can stay in website for now.
closesodoo/odoo#30473
* 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).
* 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>
* 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
* portal, theme_bootswatch, web, web_editor, website
With less2sass and bs3tobs4 tasks, the assets structure was reviewed to
handle the specificities of both framework and to prepare for our next
odoo tasks. In particular, the assets_helpers and bootstrap overrides
were basically split into 4 parts: utils, primary variables, secondary
variables and bootstrap variables.
(see https://github.com/odoo/odoo/commit/6e4db7d13a926845bf82f5b035afede42d6d5a89)
Using the !default system for the bootstrap variables parts seems now
a good improvement. This is part of what this commit does: adding the
default flag for all bootstrap variables overrides and inverting the
order of the files in the _assets_backend_helpers and
_assets_frontend_helpers templates. This allows to avoid code like this:
portal:
```
$body-bg: white;
```
website:
```
@if $var != null {
$body-bg: $var;
}
```
This code makes the body white with portal or equal to $var with website
if $var has a value. The same behavior in the new file order is achieved
with:
website:
```
$body-bg: $var !default;
```
portal:
```
$body-bg: white !default;
```
This order is now also followed for the _assets_secondary_variables
templates (there are only a few).
This commit also make better assets hierarchy by making website inherit
from portal assets (instead of web) and portal inherit from web_editor
assets (instead of web) (thus relying on strong dependencies instead of
installation order which is not always right for migrated databases).
closesodoo/odoo#29757
Ics file generation should be possible even when only event is
installed as it is a basic feature of events.
Moreover we need to be able to generate such files in order to replace
the old outlook api used in the event templates, api which is not
supported anymore.
We decided to use ics files because it is supported by most calendar
schedulers hence working with outlook.
Linked to task #1853063closesodoo/odoo#28477
jem-odoo