| Age | Commit message (Collapse) | Author |
|---|
|
Follow up on d0a4b20d3660c09b1ebe203125d57c9a533c7957
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 #63616
closes odoo/odoo#64082
X-original-commit: ba21dadf17ba96ecbba917f666a3b385d9b9fd5e
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
|
|
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`.
closes odoo/odoo#45723
Task: 2187728
Related: odoo/enterprise#9162
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
|
|
- Create a website:
Free sign up
Specific User Account activated
- In the backend, create a partner "test@test.com"
- Grant him portal access
=> user is not website-specific
- Go to the website, Sign Up with "test@test.com"
=> user is website-specific
At login, an expected singleton error arises at:
https://github.com/odoo/odoo/blob/c53f1c6a58b4c8c9e9b3c87f27281c9bfd65a0e1/odoo/addons/base/models/res_users.py#L613
Because this matches both users:
https://github.com/odoo/odoo/blob/c53f1c6a58b4c8c9e9b3c87f27281c9bfd65a0e1/addons/website/models/website.py#L44
When such a case arises, we make sure to always select the most specific
user first.
opw-2219618
closes odoo/odoo#49089
X-original-commit: 9e217125c0d8c951e895e9799795ac29b7962107
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
from default computation
Purpose of this commit is to correctly compute author_id and email_from
in mail_message and mail_mail as they depends from each other. Moreover it
is a good idea in various flows to specify email and author when giving
creation values to avoid default computation that is not always guaranteed to
be accurate notably when involving super user.
Mail message creation could lead to desynchronized values between author
and email_from. This is improved with this commit by correctly inheriting
from default_get and computing both of them at the same time instead of having
two default values. Indeed they depend on each other.
Same thing is done for mail composer. Mail Thread offers a tool method to
find email_from / author_id based on having one of those values or current
user and it is called whenever necessary.
Some calls to mail template send_mail are also cleaned.
Task ID 1853147
PR #32243
|
|
Follow up of 269aa594111a152ad4b7714856ea745bfef57155
`request.lang` is only set on `http_routing` so it cannot be used here.
The fix here is the same as what was done on `web` on the mentioned commit.
To reproduce the issue:
- install any module, but not `http_routing`
- use reset password
- try to set a new password from the received link with token
A few notes about the mentioned commit:
- the `lang` `lazy_property` was removed because it was a string before and a
record now, and lazy_property cannot return a record
- the `lang` on the `request` is now a record
- the `lang` on the `context` is still a string
closes odoo/odoo#36468
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
|
|
With this commit it is now possible to change the lang displayed in the URL.
Eg, you could use `/fr` instead of `/fr_BE`, or even a fancier `/french`.
Task-32838
Courtesy of pla@odoo.com
closes odoo/odoo#35135
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
|
|
get_installed and _lang_get_id are both ormcached and correctly check
the context
Retrieving a res.lang from a code is a frequent action that can be
achieved with _lang_get (cf previous commit).
Using _lang_get ensure the active_test in the context is correct and
is not poluted with another context propagation issue.
odoo/odoo#35490 discussion is an example of bad context propagation
closes odoo/odoo#35504
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
|
|
Purpose
=======
Currently, when we click on “Settings” on the Home Dashboard, we arrive
on a new Dashboard with several pieces of information like Installed Apps,
invite new users, or translations. Some informations are reachable in
several ways, which is not necessary.
We would like to remove this page and replace it with the General Settings
page directly. That makes more sense to the user who click on “Settings”. The
present informations will be dispatched in the menu or in the general settings
for a better usability.
Specification
=============
This commit move code from web_settings_dashboard in order to put the features
in settings directly. To do so, we choose to move code to base_setup, and create
widget on the settings form view to keep features. Concerned features are: invite
users, dev tools, odoo edition number and IAP account link.
TaskID: 2006910
closes odoo/odoo#34290
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
|
|
|
|
|
|
|
|
|
|
To reproduce:
0. Start an odoo v10 instance with --load=saas_worker,web
1. Install ecommerce.
2. Enable "Allow external users to sign up" and "Enable password
reset from Login page" from General Settings.
3. Open different session then signup a new user.
4. After successfull signup, the new user will be redirected
to the backend (/web).
Facts to consider:
1. odoo.addons.auth_signup.controllers.main.AuthSignupHome and
odoo.addons.website.controllers.main.Website both inherit
odoo.addons.web.controllers.main.Home
2. When instantiating an odoo instance *without* saas_worker,web,
the mro is the following:
( <class 'odoo.http.Home (extended by Website, AuthSignupHome)'>
, <class 'odoo.addons.auth_signup.controllers.main.AuthSignupHome'>
, <class 'odoo.addons.website.controllers.main.Website'>
, <class 'odoo.addons.web.controllers.main.Home'>
, <class 'odoo.http.Controller'>
, <type 'object'>
)
while the mro *with* saas_worker,web loaded is:
( <class 'odoo.http.Home (extended by AuthSignupHome, Website)'>
, <class 'odoo.addons.website.controllers.main.Website'>
, <class 'odoo.addons.auth_signup.controllers.main.AuthSignupHome'>
, <class 'odoo.addons.web.controllers.main.Home'>
, <class 'odoo.http.Controller'>
, <type 'object'>
)
You can notice that depending on how the instance is instantiated,
the order of inheritance is different.
The problem occurs when saas_worker is loaded, so this bug can be
experienced by saas clients.
Explanation of the fix:
Notice that the original code calls web_login of its super in its
web_auth_signup method. This is technique is used normally during
optimization (according to RCO). If website is installed, the
portal user should be redirected to '/' instead of '/web' and this
is defined in web_login of website. However, the web_login of
"website" is not called after signup because "website" is not super
of "auth_signup" when saas_worker is loaded (see the mro above).
Calling self.web_login will make sure that web_login is called from
top to bottom, and regardless of the order of website and auth_signup,
web_login of "website" will be called and makes sure that the
new portal user is redirected to the '/' and not to '/web'.
opw-1956980
closes odoo/odoo#32741
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
|
|
This implements support to administer multiple websites. Although the
core functionality already existed, managing multiple websites was
fairly technical.
In the interest of database updates and migration this attempts to
keep duplicated data to a minimum. To do this the usual generic
records are rendered unless some website-specific record exists that
replaces it. Copy-on-write (COW) is used to create these
website-specific records. Through this mechanism creating a
website-specific record is delayed until necessary. A COW mechanism
has been implemented on 4 models: ir.ui.view, website.page,
website.menu and ir.attachment. These COW mechanisms are activated
when editing data through the website (aka frontend). These frontend
edits (e.g. with web_editor) will be website-specific, possibly
creating a website-specific record when necessary. When editing data
in the backend nothing special will happen, even when editing a
generic record. Note that because of this mechanism also facilitates
the ability to create new, uncustomized websites because the generic
data is kept.
Support is provided for a website to have any theme. Themes are fairly
complex to handle. Standalone themes can depend on other standalone
themes (e.g. theme_beauty depends on theme_loftspace) and themes
usually modify some data of the themes they depend on. Because a theme
can be installed on multiple websites, using website_id m2o fields
does not work well. It would require duplicate data, making updates
and migration harder. Because of this, data for themes (ir.ui.view and
ir.attachment specifically) have a theme_id m2o. website has a
theme_ids m2m that identifies all theme modules currently installed on
it. Through these fields we figure out what to render. A theme is only
fully uninstalled when it's no longer active on any website. The
advantage of this approach is that upgrading or migrating theme data
is no different from the single-website case.
The website.published.mixin class was modified to handle multiple
websites. A wizard was added in the backend to easily manage this for
multiple website.
Although not used anywhere in this commit, a 'website_id' variable has
been added in the evaluation context of ir.rule. It allows to easily
make any model multi-website aware, all that's needed is a custom
website_id m2o field on a model and a custom record rule.
|
|
The /web/signup controller was also supposed to get the special frame
header, like all sign-in/up pages.
|
|
|
|
|
|
Similar as 676022e3afdd for reset form
|
|
|
|
|
|
Revision 054c68689b58f554e9433938644f2960720e08ef added by mistake the
password of the new user in the welcome message that is sent to users
who signed up with an invitation token.
There is no need for this, the user has just chosen their password, and
we should not send them a copy which could be compromised on the way to
their inbox or later in their inbox.
It may also give users the impression that their passwords is stored in
cleartext in the database, even when that is not the case.
This patch minimalizes changes to the template and its translations.
For existing databases where the code is updated without re-syncing the
template, the password will simply be missing in the message (until a
resync of auth_signup module is done)
|
|
Currently if a user has already been invited you cannot invite him again
via the web_settings_dashboard as it automatically tries to create a new
user.
This commit changes that behaviour in case you have the mail app
installed odoo will now send an invitation email to the invited user as
long as this user has never connected.
1) Mail app not installed:
- if user is active > display error (this email is already in use)
- if user not active > activate the user
- if user doesn't exist > create new user
2) Mail app installed:
- if user is active && state confirmed > display popup (this email is
already in use)
- if user is active && never connected > resend invitation mail
- if user is inactive > activate the user
- if user doesn't exist > create new user and send invitation mail
This commit is related to task #54023
Closes #23081
|
|
integration
This commit updates the various res config of Odoo addons to use the
newly-introduced config_parameter field attribute.
|
|
Was "Internal Error 500"
Introduced at c3bf161
This closes #20941
|
|
|
|
The /web/signup controller was also supposed to get the special frame
header, like all sign-in/up pages.
|
|
Was "('Passwords do not match; please retype them.', '')"
Introduced at 676022e3
|
|
Don't add useless routes or route that will return 404.
Improve generate function from ModelConverter to have a better management of
query_string.
Now we have an helper sitemap_qs2dom that will analyse the current route and
check if query string is plausible and if yes, generate a domain, when the
query_string don't seems to match the route, we return a Falsy domain.
Before this commit, if qs was /product/ipad, enumerate_page check for each
modelconverter of the route a name ilike '/product/ipad'.
Now we check all routes that contains product and one converter that match ipad
or routes that contains ipad and one converter that match product.
This commit a new way to declare the sitemap for a route.
def sitemap_xx(env, rule, query_string):
yield {'loc': '/my_url'}
@http.route(..., sitemap=sitemap_xx)
In this case, only the loc returned by this function will be in the sitemap
for all rules.
You can pass sitempa=False, if you don't want that route are into the sitemap
|
|
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
|
|
* allow new signup on invalid token
* relabel signup buttons
* send a welcome email upon signup with a signup token.
This way, should the token somehow be usurped by someone else,
the original partner's email address will be notified.
(before the usurper can change the email)
|
|
When you receive an url with parameters
* auth_signup_token: uuid
* auth_login: login
those will be stored in the session and used
* when the user will want to sign up in order to be linked to the right
partner;
* when he logs in so he's sure to log in with the right account +
autofill is nice
This commit only adds the support, future commits will support its use.
|
|
Since 5425316eff19e7ae716aafdb730c92d1b3ea2abb errors when signing up will only display two
messages:
* "Another user is already registered using this email address." or
* "Could not create a new account."
While Odoo creates a multitude of other comprehensible error messages
such as
* "Passwords do not match; please retype them."
* "Signup token '%s' is no longer valid"
This commit now separate UserError and AssertionError from SignupErrors.
Those are still hidden in a general message (see 5425316eff19e7ae716aafdb730c92d1b3ea2abb for reasons) while
the other ones are fully displayed.
This commit also improves translations of messages.
|
|
|
|
|
|
|
|
|
|
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
|
|
|
|
Futurize fixers:
* lib2to3.fixes.fix_except
|
|
We generally consider this a low priority issue
as it is social-engineering based and many easier
options exist for targeting gullible users.
Nevertheless, protecting a couple of obvious pages
does not hurt.
|
|
Add `sudo()` to call `get_param` where necessary, and make the web client use a
controller instead of directly accessing parameters.
|
|
Add `base.group_system` on existing parameters:
- `auth_signup.allow_uninvited`,
- `auth_signup.reset_password`,
- `auth_signup.template_user_id`,
- `google_redirect_uri`,
- `mail.bounce.alias`,
- `mail.catchall.alias`,
- `mail.catchall.domain`.
|
|
|
|
|
|
|
|
When the user name entered hasn't an email specified the error message wasn't
displayed in the reset view.
The error message was in e.name, not e.message
|
|
|
|
When evaluated, the translation function never finds a match if a variable is
integrated into the untranslated text.
SHAME! :bell: :raising_hand:
|
|
|
|
|
