Keep the manifests as light as possible, to easily see custom behavior/content.
Complete the work of previous commits cleaning the manifests content:
* 42bad1a6d2
* ef7005f524
and make sure this kind of cleanup commit is not necessary in the future
because it is now automatically verified by a dedicated test.
closesodoo/odoo#107735
Related: odoo/enterprise#34903
Signed-off-by: Julien Castiaux <juc@odoo.com>
Since this commit [1], the "avatar" image of the logged user is no
longer displayed on the "boxed" header template.
This is due to the "t-nocache" attribute which was forgotten for the
"_avatar" parameter in the "user_dropdown" template.
[1]: https://github.com/odoo/odoo/commit/b0a2a41d78292cb8b9e53788d40c6dc5915a466d
task-3063878
closesodoo/odoo#107861
X-original-commit: 484f0acade527e38e9569fc066b4647a8d70e397
Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Purpose of this commit is to try to make code a bit easier to follow using
dicts, sets and tuples, as well as updating some variable names.
Also rename the method to be clearer. Tools methods may omit the namespacing
to avoid too much confusion in naming.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
PURPOSE
Purpose of this task is to cleanup attachment management done in generic mail
models overrides and move it in account as model overrides.
SPECIFICATIONS
Accounting holds code to handle attachments linked to their custom composer
(``account.invoice.send``) that uses through inheritance the mail composer
(``mail.compose.message``) that has a specific processing of attachments
to link pending composer attachments to the right records.
Indeed attachments linked to the composer are pending attachments, and are
linked to the record when posting the message. This allows to know which
attachments have been added by the user, have specific rules for access
rights, ...
However this code has been wrongly added directly at mixing level at
odoo/odoo@bdcc012004. Instead ``_message_post_process_attachments`` method
should always be called based on a record, allowing to locate the override
at model level.
Task-2792146 (Mail: Move model-dependent code from composer / template)
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#106658
*: auth_totp_portal, mail_group, portal, survey, web, website_event,
website_event_track, website_mail, website_mail_group,
website_mass_mailing, website_payment, website_sale
Although this is deprecated since 5 years with [1], new occurrences of
`this.$target` in widgets kept being introduced. `this.$el` can be used
just like in any other widget, or even better: `this.el` to not rely on
jQuery.
For now, this still keeps the definition. This just removes the bad uses
to prevent more copy/paste... let's delay the decision to remove the
definition entirely to another day.
[1]: https://github.com/odoo/odoo/commit/2972976962617d4b8a0113bae58c640ab41cdff8closesodoo/odoo#106437
Related: odoo/design-themes#618
Related: odoo/enterprise#34343
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
When mail_action_view() calls this function, the model may not be a valid
one or even be missing. So we check if the model exists before checking its
type.
We also correctly add kwargs parameters propagation.
Add tests.
Task-3025143
X-original-commit: b5d9f42ddc2dfde21714544add72023004069815
Part-of: odoo/odoo#103378
Co-authored-by: Krzysztof Magusiak <kmagusiak>
The recent switch from tables to css grids for form views `group` nodes
has introduced several inconsistencies/issues with several views accross
modules - these will not be the last fixes.
closesodoo/odoo#102174
X-original-commit: 836568dfd59886a6d52f15e0e2109709903b6803
Related: odoo/enterprise#32295
Signed-off-by: Bouvy Damien (dbo) <dbo@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Make it possible to override both before and after execute actions on
all view controllers using `useViewButtons`.
This avoids having to change a value in the env to override the function
being called when clicking on a button.
closesodoo/odoo#101310
X-original-commit: 9f6c2b8e969635f35786d58ee89ca767ff57144d
Related: odoo/enterprise#31860
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
Currently using the ``chatter_post`` route to post a message implicitly checks
for access rights on related record. It is done manually in ``message_post``
that is called by the route. It is done because record name is accessed as
sudo and an explicit access has been added because of fear of information
leak.
However this is a bit out of scope for ``message_post`` to perform that check
at that point. As the underlying record is accessed numerous times, adding
an explicit check just adds queries.
In portal, users may have a token and/or a hash and a partner_id, in which
case they enter sudo mode if valid, and an error is raised otherwise. However
when not using a token and/or a hash and a PID access check is now done
directly in the controller helper. Moreover this allows to have the access
error directly instead of being possibly hidden by another error, which was
the case before this fix (was actually raising about missing email_from).
In this commit we add an explicit check on record access before entering
the post computation. That way access errors are directly raised.
A fix in accounting is necessary to ensure the right error is raised. Indeed
otherwise it currently raises due to non existing email_from, and should
raise due to ACL instead. Tests are now more inlined with classic flows.
Task-2710804 (Mail: Clean MailThread API)
Part-of: odoo/odoo#99654
We now display only the lines that have documents linked to them.
In case, we want to display a line even if there are no doc, we
can do so by updating the list of counter to keep with
"getCountersToKeep()".
In case, there are no lines, we display a small message.
For now we always display the quotations, sale orders and invoices.
task-2947778
closesodoo/odoo#99373
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@odoo.com>
* 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
The new structure of X2manyField stores ListRenderer in its components.
PortalUserX2ManyField is not using that structure properly. Therefore,
PortalWizardUserListRenderer it is not found nor used correctly.
This commit correctly places that List Renderer in the components.
Task-2968411
closesodoo/odoo#99320
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The portal's granting access / revoking access / reinvite actions
return the wizard modal opening action in order to keep it open
and allow the user to keep browsing and managing portal access.
However, this can return the modal opening several times and execute
them all, generating several (unsynchronized) modal view instances
that the user sees and has to close one at a time.
Therefore the user field in the portal wizard receives a small widget,
that only allows one of these actions at a time. Clicking on other
buttons in the list while an action is ongoing will not do anything
since buttons are disabled for the time the action is being done.
Buttons showing the email_state will not do actions when clicked.
A short scss file is also added to the widget in order to make the elements
of the user_ids tree view as close to each other as possible. This prevents
in most cases the loss of buttons going off the list's width view and
generating a scroll bar, a situation to avoid since it does not show the
user the (dyamically appeared) action buttons. (e.g. when hiding buttons
if no valid email, then editing to a valid email, button reappearing out
of visible range)
Task-2613780
Part-of: odoo/odoo#74911
BEFORE THIS COMMIT :
When using the action "grant portal access" on contact, it opens a wizard.
When trying to granting access, an error is raised if email is not properly
formatted or already used by another user, in a modal. The modal of error
message is superimposed on the one of the wizard. This looks very unpleasant
and not very readable.
AFTER THIS COMMIT :
Therefore, the error messages due to an invalid email (bad format or already
used) are simplified and displayed inline in portal wizard user tree view
instead in the form of colored fa-icons buttons, with details as title.
In order to have the tooltip service detect mouse events, we make them
non-disabled: if clicked, the modal will simply be refreshed. Also, there
will be no display of reinvite / grant access buttons as long as an error
on email remains.
To do so, a new selection field sets the email validity status for each
portal_wizard_user : 'ok' / 'ko' / 'exist'. Errors are still thrown if method
is called directly, except for the revoke access method. Indeed, we want to
be able to revoke access, independantly of the email status. However, the
partner's email is only updated if the email is valid.
TESTS :
Tests are updated accordingly. The last assert of test_portal_wizard_error
is repaired. The previous one raised an error as expected but not the good
one. As the email had a wrong format, it was detected and error was raised,
and not because the user was internal, as supposed to. The portal user is
updated as it should be.
--- LINKS ---
Task Id - 2613780
COM PR - odoo/odoo#74911
Before this commit, the pager was on the left or centered.
Now, it is always centered regardless of the website pages (portal or
not).
closesodoo/odoo#97967
Related: odoo/enterprise#30343
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Purpose
=======
When a user receives an email to activate their account, allow them to
click on the "Activate Account" button after the account has already
been activated instead of showing a "Invalid signup token" error.
Specifications
=============
Add a parameter p_id to the sign up url to check if the partner has
already activated their account (if their user_ids state is not new) and
redirect them to login otherwise.
Task-2680414
closesodoo/odoo#79936
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Each cookie binds to a domain name, multiple cookies can be set for the
same name if they are for different domain name. In this case, two
`session_id` cookies were set: (1) the first set right on the opener at
`opener.cookies[...] = ...`, (2) the second set upon inside of
`http.Request._save_session` because the session was rotated upon login.
The problem is that the former cookie (the one set on the opener, the
one *not* rotated) was used instead of the second cookie (the one
holding the registered user) in the subsequent queries. There is a long
comment explaining the same problem inside of
`odoo.tests.common.HttpCase.authenticate`, we used the same solution as
they did inside of `authenticate`: we diched the previous opener.
closesodoo/odoo#94773
Signed-off-by: Christophe Monniez (moc) <moc@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
- new prefix `bs-` for the root CSS variables
As some website snippet relay on these values we need to restore the old
behaviour by setting this prefix to an empty string.
- restore negative margins disabled in BS5 by default
- restore BS4 behaviour for setting element content
Fix some cases when we want to render more than one node on the root
level.
In BS4 the jQuery was using all node but in the jQuery compatibility
layer in BS5 it takes only the first node if the jQuery Element is used
in the function. This hack try to restore the old behaviour wrapping all
element in a DIV element (to be single root node).
PS: this can break some querySelector and some CSS selector if they are
too fragile.
e.g. of element that break before this hack:
Popover content for PaymentPopOver XML in ShowPaymentLineWidget
- restore old value from BS4 and adapt to new value
$table-cell-padding -> $table-cell-padding-x
$table-cell-padding -> $table-cell-padding-y
$table-cell-padding-sm -> $table-cell-padding-x-sm
$table-cell-padding-sm -> $table-cell-padding-y-sm
- restore BS4 smooth-scroll behaviour
- restore `text-X` from BS4 that use text-emphasis-variant
In BS5, to generate the text utilities `test-X` its use BS5 utilities
(See $utilities SCSS variables). To restore the old behaviour we replace
with the custom `text-emphasis-variant` mixin.
See odoo/odoo@e111cfd35e
- restore border and background of table
In `_reboot.scss`, BS5 add `border-style` to all element of a table.
In some case we customize the table with CSS rules (e.g. `listview`),
these rules set a size of border. The mix of all rules made that the
border of the `td` in `tfoot` are visible and make a black line.
- reset block quote Y margin to 0
BS5 add a spacer and we reset that by puttin margin-y 0
- In BS5, border color is linked to the text color in it. We doesn't
want that and we restore the same behavior as un BS4 by putting
border-color in grey.
- restore HR style like in BS4
Since in BS5, the height matter we remove the padding and added into the
margin.
Also, we restore the color of BS4 for the HR tag
> <hr> elements now use height instead of border to better support the
> size attribute. This also enables use of padding utilities to create
> thicker dividers (e.g., <hr class="py-1">).
https://getbootstrap.com/docs/5.1/migration/#content-reboot-etc
- restore old value for grid gutter to avoid calc error
In BS5 `$grid-gutter-width` is set in rem and in BS4 it was in px.
So SCSS compiler generates error when it tries to calc rem and px.
- restore badge, navbar paddings like in BS4
- restore link decoration in frontend (Portal) whiteout website
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
* 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>
As result of moving the "website into the backend" [1], two new entries
have been added in the user-dropdown: one that redirects to the
backend ("Apps") and another one to edit the current page ("Configure
this page").
This commit removes the one to edit, since the same action it's already
in the floating nav (.o_frontend_to_backend_nav) and keeping two
actions would have be redundant.
For the same reason the "Apps" one could have been removed too, but it
has been decided to keep it to ease lambda users' efforts to find their
way to the backend.
This commit refines the design too, adding icons for all entries and
adapting the user-dropdown layout.
[1] https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-2898212
Part-of: odoo/odoo#95002
In some cases, empty messages can be displayed in the portal chatter.
For instance, if a customer sends a message with no body and just
an attachment, and the attachment then gets deleted, it will still
be displayed as an empty message in the portal chatter.
To solve this, this commit filters out empty messages from the portal chatter.
Task-2833919
closesodoo/odoo#94828
X-original-commit: 10d2a3e01a0fb62860e502cc67e5311b9420a684
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
Purpose
=======
Allow portal users to deactivate their accounts from the portal view.
After the deactivation, they are redirected to the login page, so
they can verify that they can not longer login with their credentials.
We first archived the record and remove sensitive information (password,
login, so he can not log in again with the same credentials).
After the deactivation, we blacklist the email and the phone of the
user, so we are sure that we never send him again email / SMS.
Then, we create a <res.users.deletion> to delete the user and the
partner in a CRON because this operation can be heavy (write_uid,
create_uid field on all models).
Task-2629544
Part-of: odoo/odoo#78298
Steps to reproduce:
- Create a sale order
- Set a very long message in the chatter
- Clink on the customer preview
Current behavior:
There is a empty space in the top right corner
Expected behavior:
The preview is a usual
Explanation:
The very long word in the chatter created at the
bottom of the page a very long message that increased
the page width, modifying the usual view. To fix that
we allow long words to broken to keep the same width.
opw-2880050
closesodoo/odoo#94802
X-original-commit: 775290e186f5dfdaae8a5b28e9ed20c6b307429e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
Signed-off-by: Fockedey Martin (mafo) <mafo@odoo.com>
Default value for attachment_ids / tokens is None. However a check method consider those
as lists and check their length. When calling chatter_post without giving at least a void
list there is therefore a crash that can be easily avoided.
closesodoo/odoo#94695
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce
------------------
1. Create two partners A and B.
2. Create a shareable record, e.g. a sales order, and set A as the customer.
3. Share the record with B.
4. Use the share link sent to B and comment on the record.
5. Your comments will be sent with A as the author.
Expected behavior
-----------------
Share links sent to a customer should make you comment as that customer.
Task-2883044
X-original-commit: df162acc589b74b0e3c1e9687ce6a1980233f5f1
Part-of: odoo/odoo#94695
*: auth_signup, knowledge, mass_mailing, portal, survey, test_website,
test_website_modules, test_website_slides_full, web, web_editor,
web_tour, web_unsplash, website_blog, website_crm,
website_crm_partner_assign, website_customer, website_event,
website_event_exhibitor, website_event_meet, website_event_track,
website_forum, website_hr_recruitment, website_knowledge,
website_links, website_livechat, website_mail_group,
website_mass_mailing, website_membership, website_sale,
website_sale_autocomplete, website_sale_comparison,
website_sale_loyalty, website_sale_slides, website_sale_wishlist,
website_slides, website_slides_forum, website_twitter, base
A new client action is introduced, to display the website in an iframe.
This allows to remove the "frontend" Odoo UI entirely. Everything
related to the website configuration (and especially the edit mode) will
now be done on the backend side.
The idea behind this mainly comes from the fact that we needed the
website in an iframe during edition to be able to render a mobile
preview properly. It was also required so that options which reloads
the page... are able to only reload the page and not the entire editor
with it. From there, it was decided that actually, since the website is
in an iframe, it could be in the backend and every website UI could
rely on this.
In the end, this comes with many functional and technical advantages.
Here are some of them (a few of them are not entirely done with this
merge but will follow the merge in the upcoming weeks, see this as a
non-exhaustive list of possibilities that are unlocked by this work):
Technical:
- No duplicated logic for website UI and backend (purple navbar is the
backend one, slightly customized).
- No conflicting logic for website UI and website content (like dialog
opening, ...).
- No forced CSS for our website / web_editor UI, no conflict with
website themes.
- Everything converted in OWL, in backend code (no special OWL for
frontend).
- "Legacy" code moved as frontend code or removed.
- No website content CSS for the case "when there is the Odoo purple
navbar at the top".
- Backend views & features available (e.g. creating a new event -> form
view instead of custom code with onchanges, validations, etc)
Functional:
- All website features available while editing your website (product
configuration, settings, etc), no switch backend/frontend, no
redirection, no reload (just the iframe).
- All other app features available while editing your website (discuss,
calendar, all other apps, ...).
- Typing a website URL in your browser reaches your website (very small
Odoo UI overlay at the top left as a connected user).
- Mobile preview: directly resizing the website rendering, in edit mode
too and with a better phone image.
- Editor: mobile view edition (the editor is instanciated around the
website content instead of inside of it (iframe))
- Can reload the website without reloading all the tools (editor, html
editor, menu edition, etc) (customize_show options for instance ->
moved as standard editor options which reloads the website only)
- Website UI in your language instead of website language
On the backend side, some customizations were done so that the UI feels
like it works as before (note that it will be reworked in upcoming weeks):
- A `website_systray` registry is defined to replace the systray items
with the website's one when previewing the website.
- The webclient's navbar is patched to display additional dropdown menus
related to the website edition.
- A website service that holds the global state of the website is
introduced. Components from the systray and the dropdown menus can
access and modify it.
- A component adapter for the wysiwyg (that will display the snippets
menu) is added, that allows for caching the wysiwyg libraries, thus
improving editions responsiveness.
See sub-commits for details. This work is known to not be bug-free and
will be bug-fixed, improved and reworked in the upcoming weeks.
task-2687506
Thanks to the whole team for reviewing and testing !
(ARD, BVR, BSO, GDI, MOU, PDE, QSM, RDE, SOBO, YOL)
closesodoo/odoo#89223
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: Younn Olivier <yol@odoo.com>
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: Mehdi Outagant <mou@odoo.com>
Co-authored-by: Benjamin Vray <bvr@odoo.com>
The documentation page for the external API was moved elsewhere with PR
odoo/documentation#2026.
closesodoo/odoo#94488
X-original-commit: 99eb55e14782bd32c4b2281681a62eb5f3d34407
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
*: auth_signup, portal, web, website_knowledge
When navigating in the iframe, only same origin redirections should be
open in the iframe contentWindow. External redirections should be done
in the top window.
Some internal pages had to be served with X-Frame-Options header set to
SAMEORIGIN, and Content-Security-Policy to "frame-ancestors 'self'" (see
[1]).
All the links that are redirecting to another host, and the client
actions, are opened in the top window.
Exemples that will be opened in the iframe's top window:
- Clicking on a link google.be that should not open in a new tab
- Clicking on the language selector and adding a new one, or
clicking on "logout".
[1]: https://github.com/odoo/odoo/pull/78298#discussion_r898853383
See merge commit for more information.
task-2687506
Co-authored-by: Arthur Detroux <ard@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
*: portal
The user dropdown (containing link to /my and a link to logout) now also
contains two other links (provided the user has the access rights):
- Link to the backend (app switcher for enterprise)
- Link to the website client action to configure the current page
See merge commit for more information.
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>
No method was readily available to know if a user is `internal` (has
group `base.group_user`), which was inconsistent with other base groups.
_is_internal is now used in the codebase where it is clear that
`.has_group('base.group_user')` is called on a single record.
Part-of: odoo/odoo#85703
Victor Feyens