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>
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>
Steps to reproduce:
- Let's consider the portal user Pu, the project Pr and the task Ta
- Add Pu as a follower of Pr
- Log as Pu and open Ta
- Try to post a message
Bug:
An access error was raised due to the rule "res_partner: portal/public: read
access on my commercial partner".
opw:2070320
closesodoo/odoo#36960
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit adds `website_sale_tour` test which is testing the whole ecommerce
flow.
This tour will test b2b and b2c flow using public user, tests website sale
flows with tax included and tax excluded price. Also test address management.
Also, the signup URL needed to be modified as PhantomJS run all tour on domain
127.0.0.1 but ignup button has absolute URL.
Runbot stores next step to be executed on `localStorage` and due to domain
name change during tour execution, it will lose track and runbot will fail.
Closes: #24179
Task-1829827
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Co-authored-by: Ravi Gadhia <rga@odoo.com>
Co-authored-by: Mohammed Shekha <msh@openerp.com>
* = base, auth_signup, mail, portal, sale, website, website_sale
Before this commit, sending an object by email would always link to web.base.url
even if the object was created from a specific website.
Now if the object has a website, we use the URL of that website if it is set.
The fallback will always be on the web.base.url.
opw-1921030
PR: #30000
Purpose of this commit is to improve the redirection done after signup.
Currently everything is tailored to create an Odoo action (action, model,
res_id, ...). This action is used to forge an URL that is the redirection
URL after signup. In some cases you would like to directly give the redirection
URL when no Odoo standard action is involved.
An example of use is the redirection when subscribing to take a survey. We
want customers to be back on survey that is a frontend URL, not a backend
URL linked to an action.
This commit is linked to task ID 1932508 and PR #30508.
Fine tuning of this commit:https://github.com/odoo/odoo/commit/7501691da9a9dae832b7d6e78c6a5f57fc983b5c
Fields signup_token, signup_type, signup_expiration are protected
When sending a quotation (mail template 'Sales Order - Send by Email'):
the token needs to be read (and sometimes written)
opw:1907157
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
closesodoo/odoo#30954
Before this commit, the signup_valid field was miscomputed
probably due to some env mayhem.
Hence the banner with the link to reset the password was never shown
After this commit, the field is well computed, and the banner displays
OPW 1894390
closesodoo/odoo#27901
- The field `signup_valid` was computed and stored using the `superuser`
env, which causes issue since it means the value was computed for the
wrong environment.
Using a compute_sudo instead of manually calling `sudo()` fixes the
issue.
e.g: reading signup_valid using a regular user (non superuser) will
always return False, while doing it as the superuser will return
the correct value.
compute_sudo does not do anything when the computed field is not stored.
This fixes an issue where user not part of base.group_erp_manager
couldn't modify res.partner
opw-1942803
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 token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The token field is a technical data that the other users are not able to use.
It may be confusing for users to see token on the user interface.
Still show it to administrator for debug reasons.
The field signup_valid is a non stored computed field based on signup_token.
The cache is filled with prefetched values, so in a loop the field is read from
the cache and not recomputed due to the missing dependency.
opw 1843442
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.
When another user than administrator opens the mail sending wizard there
is an access right issue. Indeed as sale mail links now contain auth_signup
parameter an access to allow_uninvited config parameter is done. However
this has to be done using sudo because classic users have no access to
config parameters. Fix related to e79eb01a67 .
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 5425316eff 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 5425316eff for reasons) while
the other ones are fully displayed.
This commit also improves translations of messages.
In Python 3, all of these were "consolidated" under urllib(.request,
.parse, .errors) which is inconvenient.
Since we already have hard dependencies on requests and
werkzeug(.urls, which is a backport of Python 3's unicode-aware
urllib.parse) migrate *everything* to that.
A sticking point is urllib2.URLError, those were (mostly) replaced by
the slightly more general IOError which URLError extends.
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
Xavier Morel