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
When portal is not installed and `auth_signup.invitation_scope` is "b2c",
visitors can create an account, leading to a blank page. Still, accounts can be
required for several use cases in apps that do not require portal (such as
survey).
We here add a landing page for users that created an account but have no
requested redirections and cannot be redirected to a customer portal either.
auth_signup_uninvited is also updated in model to be consistent with config
data.
Tests are added to check this behavior.
Task-2762102
Part-of: odoo/odoo#85703
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
Purpose
=======
Change all masculine nouns in Odoo's code to neutral nouns (when
possible), making sure that demo data is correctly handled. This is
particularly important since our code is open source, and nowadays lots
of machine learning models are trained on open source repositories.
With this small change we contribute to training more "fair" models, and
teaching models that "employee" or "user" != "he".
This also affects some text visible by the user, hence making it more
inclusive for Odoo users.
Task-2853046
closesodoo/odoo#91292
Related: odoo/enterprise#27302
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Before this commit, when the chatter was displayed on a portal page (with
the customer preview button) one could see the internal notes with a button
for toggling his visibility... which was ineffective because a portal user
could never see internal notes and on the opposite internal users could
always see them. This commit adds another informative (disabled) button for
internal notes.
SPECIFICATION
Adds a 'is_message_subtype_note' param on the message in the
_portal_message_format method.
LINKS
Task-2817892
closesodoo/odoo#89775
X-original-commit: 705af2c24e99b8f24482722cb4795c141330b1c6
Signed-off-by: Hoste Patrick (pko) <pko@odoo.com>
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
A Portal User (PU) cannot edit his contact details once they are logged
in.
Step to reproduce the issue:
- Go to the Contact module
- Create a new contact (as an individual) and link him with a company
- From the newly created contact, click on Action > Grant Portal Access
- Retrieve the registration link of the newly created user by going to
Settings > Users & Companies > Users. You will find the new user when
removing the default Internal Users filter.
- From the Portal main page, go to the contact details and update some
field (e.g. the phone number).
Upon submission, you will get an error related to the edition of the
company_name while no change was done.
Solution: In a previous commit [1], a change was done on the
`company_name` input. This modification changed the JSON that was sent
upon form submission.
Indeed, previously the `company_name` field was not sent (thanks to a
<p>) but now this field is sent, causing an error.
To mimic the <p> behavior and keeping the idea of the first change, the
attribute "disabled" was used in the input, allowing to not send this
field upon form submission.
[1]: https://github.com/odoo/odoo/commit/beb50e8047f4dbe148933edd52cceadb2d5cccde
opw-2754584
closesodoo/odoo#89740
X-original-commit: d3912aad67e5a519df3b355e962ce9d2e7894133
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Desausoi Laurent (lade) <lade@odoo.com>
The odoo.addons.web.controllers.main python module have been splitted
over multiple files on the basis 1 controller = 1 file. In this work we
adapt all modules to use the new imports.
A non-exhaustive list of where stuff have been moved:
* main.Home --> home.Home
* main.Session --> session.Session
* main.WebClient --> webclient.WebClient
* main.clean_action --> action.clean_action
* main.ensure_db --> home.ensure_db
The complete list is accessible in odoo.addons.web.controllers.main.
closesodoo/odoo#87571
Related: odoo/enterprise#25746
Signed-off-by: Raphael Collet <rco@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Gorash