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>
Due to the removal of btn-block we need to change the display to grid
> Dropped .btn-block for utilities. Instead of using .btn-block on the
> .btn, wrap your buttons with .d-grid and a .gap-* utility to space
> them as needed
https://getbootstrap.com/docs/5.1/migration/#buttons
Task ID: 2766483
Part-of: odoo/odoo#95450
*: 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>
Before this commit, the link "Manage Databases" was present in the
/web/reset_password screen, even if it is disabled.
Fixesodoo/odoo#93678closesodoo/odoo#93881
X-original-commit: 3a1f41f2c42957a10cdd96a59c62ddd83fbdecd8
Signed-off-by: Martin Trigaux (mat) <mat@odoo.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
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>
Install auth_signup, go to /web/login, 500 Internal Server Error.
auth_signup extends the /web/login template and in this extension calls
`keep_query()` which has been wrongly moved from base to http_routing in
commit 880954ebfc. Here, we restored `keep_query()` in the base module
but moved in ir_qweb.
closesodoo/odoo#87491
Related: odoo/enterprise#25754
Signed-off-by: Julien Castiaux <juc@odoo.com>
This commit is the 12th commit of a comprehensive refactor of our HTTP
framework. See odoo/odoo#78857 for complete historic, discussions and
rationnals.
The web module is twofold, on one side there are many controllers: /,
/web, /web/login, /web/database/selector, /web/dataset/call_kw, etc, on
the other side there is `session_info`: the method responsible to create
the web client's environ.
This module is kinda an exception as it is (with base) a server wide
module. In the case of the HTTP framework, it means that the controllers
of web are always accessible, i.e. going to / or /web/login will never
return a 404 Not Found even if the user is not connected to a database.
This is both a blessing and a curse. It is a blessing because the
controllers are always accessible it means that a new users can freely
access those routes. It is a curse because *any* user can access them,
even user who don't have a session yet thus who are not connected to a
database yet. From a developer standpoint, we have to put extra care to
correct serve users with and without a database. An example is the
/web/login route, the login/password pair is stored in a database,
without database it is impossible to validate a user login but users can
still access this route without db.
To solve this problem, there is the `ensure_db` function. This function
attempts to find a database using various sources (?db= query-string,
session db, mono db) and to save it on the user session. In case no db
is found, the user is redirected to the database selector. In a way,
this function grants a database to the user in a seamingly experience.
In a way, this function brings a welcome differentiation between
`auth='none'` with a database and `auth='none'` without a database. Such
differentiation only matters for the server wide modules as "regular"
module controllers are only accessible via the ir.http routing map, i.e.
it is not possible to declare a nodb controller outside of server wide
modules.
An important changement is the `session.authenticate` method, before it
was possible to call the method when the cursor was not yet initialized,
authenticate would open a cursor against the given database, setup a
registry and an environment and ultimately save everything on the
current request. Because the cursor is now greedily created, it is no
more possible to update the request environment when authenticating on
another database.
PR: odoo#78857
Task: 2571224
Purpose
=======
Several actions are done even if nothing has changed on the configuration.
Example:
Writing on a cron the same value makes a dummy write-lock on the table
...
Part-of: odoo/odoo#82999
Purpose is to have a white background like templates used in SO, invoices, ...
Task-2712450 (Mail/Sale: Improve 'Pay Now' notification template)
Part-of: odoo/odoo#82167
RATIONALE
Currently we can specify email used for notification layouting through context
use in mail composer. It is then propagated to message_post, stored on
mail.message and used to encapsulate emails sent based on posted messages.
SPECIFICATIONS
On template model: rename ``notif_layout`` parameter of ``send_mail`` to
``email_layout_xmlid`` to be coherent with naming used in other parts of the
code. Moreover it better indicates we expect an xml id.
On rating model: rename ``notif_layout`` parameter of ``rating_send_request``
to ``email_layout_xmlid``, for the same reasons as above.
In various wizards: support ``email_layout_xmlid`` context key when no field
is available, notably because this is still done manually in some wizards
like survey invite. Keep a fallback on ``notif_layout`` but remove support of
``custom_layout`` deprecated since quite a long time.
Task-2621326 (Mail: add 'view' button in 'light notification template')
Task-2647302 (Mail: add layout field in composer)
Part-of: odoo/odoo#76418
Purpose
=======
Hide non-relevant fields for a portal user. E.G. we want to hide the
notification type, the menu customization... Because those fields
make no sense for a portal user.
Force the non-internal user to receive notifications by emails since
they can not open Discuss.
Task-2508521
Part-of: odoo/odoo#77766
Co-authored-by: nounoubensebia <neb@odoo.com>
* = auth_signup, calendar, im_livechat, snailmail_account, survey, test_mail,
web_editor, website_crm_iap_reveal, website_livechat
The aim of this PR is to improve/fix various flaws and limitation of the current
API, to make it easier to use and more efficient.
Notification are now defined with 3 distinct parts:
- the channel determines which client(s) should receive it
- the type determines how it should be handled
- the payload determines any extra information helpful for handling it
Channel
=======
Business code
-------------
- Record channel is introduced for ease of subscribing to and sending
notifications to specific partners, channels, documents, ...
- String channel is still supported (but it is converted internally to the tuple
channel).
- Tuple channel is still supported without any change (but should be avoided
whenever possible due to its complex syntax).
The channel is no longer sent to the client. When the channel was used for
business purpose, the information it contained has been moved into either the
new type, or the payload itself.
Technical note
--------------
All channels are now internally converted to the tuple (db, ...) channel, which
is necessary for the platform code (saas/sh).
Internally, the bus.bus table is not changed, type and payload are grouped
together into what was (and still is) called message.
Type
====
Type is introduced to uniformize the way notifications are sent and handled.
All existing notifications already had some kind of manually-built type in them.
This is now officially supported at the bus API.
In client code this will allow (to be done in future commits) to register one
handler per specific type, instead of having to iterate and to filter all
received notifications on every handler.
Payload
=======
Payload (ex message) did not change, it can still be anything depending on
business needs.
Few adaptations:
- When the type was included on the payload, the type has been moved to the new
type parameter.
- When the channel was used in business code, its data has been copied into the
payload.
task-1891151
closesodoo/odoo#79201
X-original-commit: 543af27c7d6836ffac9e80ff8490b6ddbd849221
Related: odoo/enterprise#21998
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
When calling `_get_signup_url_for_action` on more than one partner,
because the `url` input parameter was re-used for the actual signup
URL before assigning to the partners map (in
559bdc976e), from the second iteration
onwards the signup URL will almost certainly get misgenerated to
redirect to the previous signup URL (accumulating).
As `signup_url` is not normally accessed in bulk this should not
usually be an issue.
Reported by Andreas Brückl
closesodoo/odoo#78223
X-original-commit: 4d9b23f60087e0e8ffcb85498f39324854f50cb8
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Jinja as a templating engine was problematic in differents respect:
- introduce external dependency to Odoo (less controll)
- add another templating mechanism in the stack
- specific feature in qweb cannot be reused
- difficulty in rendering easily editable templates
- more knowledge required with no betterment
By replacing jinja with qweb we can now build tools to edit a qweb
that will work with the previously jinja encoded document
(essentially `mail.template` records).
There is a catch however. Some email fields (eg. email_to) used jinja
syntax for rendering dynamic variables (ie. ${object.something} and
${object.something_that_should_not_be_escaped | safe}).
We still want user to use dynamic variables for some char fields (eg.
subject, from, to, ...). We made a new rendering engine called
"inline_template" that will render an expression enclosed by `{{` and
`}}`.
To be able to edit the templates from the backend interface, a
plugin to the Odoo editor has been made for seamlessly edit the
document.
This qweb plugin includes:
- make dynamic variables (eg. `<t t-out="variable"/>`) not editable
(for preventing the user to shoot himself in the foot)
- group and hide related logical branching (ie. t-if, t-elif, and t-else)
in order to see only one at once
- a floating select input to switch visibility of a particular logical
branching
Task-27033
X-original-commit: odoo/odoo@68182baff4
Part-of: odoo/odoo#77377
This commit will improve the wording and the layout of the invitation
email sent to the users getting access to the portal. The signup link of
the email will now be a button that emphasizes the call-to-action.
We will also provide in the email another link that will allow the user
to access the login page. This commit will also improve the wording of a
placeholder in the portal backend.
task-2573334
closesodoo/odoo#74210
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
A jinja marker is used as email_to but is actually not evaluated. Instead
we can set the right value directly.
Task-2573334
closesodoo/odoo#75770
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.
closesodoo/odoo#74245
Related: odoo/design-themes#48
Related: odoo/enterprise#19862
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
This branch adds request.redirect on all requests.
In case of a front end request, we do an url_for to the location.
We removed redirect_with_hash that was only for retro compatibility
local_redirect has been renamed to redirect_query, and param keep_hash has been
removed and moved.
Default code for redirect is 303 now instead of 302.
Now redirect and redirect_query make local redirect by default, you need to
pass local=False to make external redirect.
All werkeug.utils.redirect has been replaced by request.redirect.
Http.redirect now use an http.Response type, and it become easy to add an
override like 'set_cookies' e.g.
Dispatch of a website.page return an http.response too, so we first need to
check if it is a cached version before to check if it is an Odoo Response.
Migrate your code:
http.redirect -> request.redirect(location, code, local)
http.local_redirect -> request.redirect_query(location, query, code, local)
http.redirect_with_hash -> request.redirect
Courtesy of odony for help and review ;)
closesodoo/odoo#72599
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Remove arbitrary write on template used in signup process. Instead of writing
on template if some values are not correct compared to the current flow
we force values given to ``send_mail``. It allows to let people tune the
template while still having a working auth signup process.
Task ID-2534550 (Template usage improvement)
Task ID-2477164 (Composer mixin)
COM PR odoo/odoo#70889
ENT PR odoo/enterprise#18352
Conversion of all modules to the new manifest assets declaration.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
Calling write() on a record will touch it and update its `write_date`,
even if all the field values are identical to the current values.
Let's not touch the mail template unless we have a reason to.
closesodoo/odoo#68562
X-original-commit: ecd0253d1cc231c8695183e1688835b969864362
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>
Purpose of the task is, 'general setting' is not easily understandable
by the user. The user often gets lost. This is especially damaging
through onboarding as some new users like to discover the software by
scrolling through the general settings.
So in this commit, the general setting is well organized and easily
understandable by the user.
Related PR: https://github.com/odoo/enterprise/pull/14707closesodoo/odoo#61645
Taskid: 2374990
Related: odoo/enterprise#14707
Related: odoo/upgrade#1958
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For odoo-master Transifex project, no demo data
closesodoo/odoo#66500
X-original-commit: 813931ac850e5ba4181259a5957ec72226fb670c
Related: odoo/enterprise#16510
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Follow up on d0a4b20d36
The `lang` at this step is compared to the locale `code` (eg. fr_BE) so the
split is a mistake.
To reproduce the issue:
- change the language of a website to fr_BE only
- allow free signup
- register as a new user
Notice how the language of the user is set to en_US before this PR instead of
fr_BE as it should be.
closes#63616closesodoo/odoo#64089
X-original-commit: ba21dadf17ba96ecbba917f666a3b385d9b9fd5e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This commit fixes a small design glitch in the user form by replacing a "X"
character to close an alert by an actual close icon.
Which looks better, the "X" really sticks out from the rest of the design.
Task n°2393814
closesodoo/odoo#62368
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
PURPOSE
Clean organization of templates in odoo apps: mail.template records in data,
qweb templates (views) used directly in code, notably using post with view.
Purpose is to ease future improvements in posting based on templates.
SPECIFICATIONS
* move those templates in their own file to ease their discovering and
maintenance;
* put them into data (as those are not views even if it contains qweb)
* guidelines are now :
-> Qweb templates should be in data/mail_templates.xml;
-> mail.template records should be in data/mail_template_data.xml;
* put their declaration in no update when not done if template has no
technical code or complex dependency on underlying code;
* move found mail data (mail.message.subtype or mail.activity.type) records
in a mail_data file that should contain only "core" records linked to mail;
LINKS
Task ID-2375767
COM PR odoo/odoo#61814
ENT PR odoo/enterprise#14775
UPG PR odoo/upgrade#1936
When a module creates a disabled user during its installation or upgrade
(e.g. demo data), the UserError "You cannot perform this action on an
archived user" breaks the whole installation process.
We don't care if the mail cannot be sent for users created by an
installation, so let's just skip the whole function if we are installing
a module.
closesodoo/odoo#59036
X-original-commit: 78e22584c76c9fecbc22ab3604771fdce5f2094f
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
32ec8a974d
aims to give the possibility to admins to send reset password emails
to users.
`groups_id` expects a `res.groups` id,
not a `res.users`
closesodoo/odoo#58935
X-original-commit: 4a978c08853b992199336f6355d816e2d5adfc84
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
- Let's consider a product P (invocing policy based on timesheet and creating new task)
- Create a quotation with the product P for a customer with portal access CPU
- Confirm it (A new task T is created)
- Go to T and add a follower (who is another portal user PU (third party)) in the task
but uncheck the box to send him an email
- Connect to the portal with PU
- Go to T and send a message
Bug:
A server error was raised.
opw:2270074
closesodoo/odoo#52689
X-original-commit: 2a924b44f17f7e9574e2b0074d8ce8adb041c67e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce the bug:
- Let's consider a product P (invocing policy based on timesheet and creating new task)
- Create a quotation with the product P
- Confirm it (A new task T is created)
- Go to T and add a follower (who is a portal user PU) in the task
but uncheck the box to send him an email
- Connect to the portal with PU
- Go to T and send a message
Bug:
A 403 error was raised
opw:2239844
closesodoo/odoo#51953
X-original-commit: c7e864e039dd2c948a5c61df29052313c6a659ce
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
The main classes of partners and users support batch creation, but
the majority of their overrides doesn't support creation in batch.
Adapting those overrides to support records creation in batch shows
great performance gains:
* On `res_partner` : 2 to 3 times faster
* On `res_users`, with the inherited `res_partner` created in batch:
up to 10 times faster.
Tests done with 500 to 4k records:
* `res_partner` with only a name provided
* `res_users` with a name and login
X-original-commit: 9c3c5f161580039c1fe50f68acac808c18817997
TL;DR: remember `osv` and `except_orm` ? You can forget about them.
* Deprecated `except_orm` dropped.
* `UserError` elevated as super type of all user-related
errors.
* Unused `DeferredException` dropped.
* Unused `QWebException` dropped (real one is in `qweb.py`).
* `MailDeliveryException` made a python exception.
* `name` legacy exception attribute made an alias of the python standard
`args[0]` attribute and deprecated.
* `value` legacy exception attribute dropped.
* `exception_type` RPC error response key dropped.
* Deprecated `osv` module dropped.
* `--osv-memory-age-limit` cli option made an alias of
`--transient-age-limit` and deprecated.
The `odoo.exceptions.Warning` have long been a deprecated alias to
`UserError`. It is going to be removed in a future version but first we
explicitly deprecate it with a warning.
The `odoo.exceptions.DeferredException` was a very old internal
exception, it has been removed without deprecation notice as it is never
raised.
The `odoo.exceptions.except_orm` has been a deprecated exception type
with deprecation warning for 5 years, it has been removed in favor of
UserError which becomes the super class of all user-related errors.
The `odoo.base.models.ir_mail_server.MailDeliveryException` was
inheriting `except_orm`. As it is not related to a user error but is
more of a problem an admin much take care of, the exception has been
made a Python error.
The `exception_type` JSON key in RPC error responses was holding an
hardcoded value derived from the exception type. Its usage has been
dropped in favor of the `name` JSON key that holds the precise exception
name. Again as it was hardly used in the source code (beside the crash
manager) it has been dropped without deprecation warning.
Since we are here trying to clean odoo custom exceptions, we are also
deprecating the `name` exception attribute in favor of the more standard
`args[0]` attribute.
The `name` (along with `value`) were two attributes used to raise
`except_orm` exceptions before the introduction of `UserError`,
`AccessError` and related exceptions. The `name` attribute, at the time,
was holding the exception type/title. Nowadays it contains the error
message. The `value` attribute, at the time, was holding the error
message. Nowadays it is no more used.
The `osv` module contains very old deprecated aliases. There is no
simple way to log a deprecation warning for osv, osv_memory and
osv_abstract but as they have not been in use for ages, they have been
removed too. To be consistent, the `--osv-memory-age-limit` cli option
has been made a deprecated alias to the `--transient-age-limit`.
closesodoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Fabio Barbero