Fix bug from the initial poc of JOV
Fix menu creation
- creating a menu would create a 'container' menu in the DB (.create is call without website_id)
then writing on it would copy (if condition to cow) the menu with a website_id leaving the first
one as a menu container unused.
- website_menu should always have a website_id
we dont want to support the multiwebsite system that allow to have generic/specific menu
unlink/write is useless now since we always have a website_id
Make unique_path website dependent, 2 distinct website can have a page with same name
Make Sale report multiwebsite compliant
Make website_id on sale_order / account.invoice as a related stored from partner_id.
Co-authored-by: Derie Romain <rde@odoo.com>
Co-authored-by: Kersten Jérémy <jke@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.
Purpose of this merge is to improve onboarding of Discuss. This is done via
a wow effect and a bot to test the Discuss app; otherwise you have nobody to
talk to. Purpose is also to improve retention as "the best way to increase
retention is this: when the user invites someone, when this guy activates its
account, the user gets a push notification from the invited user that just
logged in; that way he will come back to Odoo and start discussing with its
colleagues.
Concerning your new best friend: it is not a dog but Odoobot.
See sub commits for more details. This merge is linked to task ID 1838588 and
closes PR #25075.
Purpose of this commit is to improve the onboarding and the first steps of
Odoo notably when using Discuss and inviting first people to join Odoo.
When a new user connects the user who invited him will be notified with
a desktop notification inviting him to have a chat in Discuss and talk
together.
This commit is linked to task ID 1838588 and PR #25075.
When duplicating a user, an email was sent to a user at the email of the
previous user (as the create is called before changing the email).
opw-1853359
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.
Rather than requiring the user have a name *or* a partner, the check
required the user have a name *and* a partner. The B2C form only has a
name and expects the partner to be created from/via the user, so this
would raise an exception which wouldn't even be bubbled to the user, so
trying to signup would just yield a 500 Server Error when trying to
create an account.
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
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 #54023Closes#23081
Purpose of this commit is to standardize portal user creation when
creating new portal users (when 'Free sign up (B2C)' option activated). It
copies the portal user template. The same behavior now applies when
converting a partner into portal user using the portal wizard.
This commit is related to task ID 31399 .
Purpose of this commit is to standardize portal user behavior and creation.
As all portal required features (user, group, support) have moved to
base let us move the template user used to create portal users to base.
'Portal User Template' is therefore moved from auth_signup to base module.
Various config parameters are updated due to the change in xml id.
This commit is related to task ID 31399 .
The field `auth_signup_uninvited` is defined in the 3 aforementioned
modules, yet they are independant modules in respects to one another.
This means that whichever module is installed first will create an XMLID
for the field, if this module is uninstalled before the other two: boom!
crash when changing general settings because the res.config.settings
field set by the other two modules no longer exists.
To solve this, we simply ignore the field during ir_model_field.unlink()
Fixes#23171
- Delete the tax corresponding to the default 'Sales Tax'
- Access the Accounting settings
Error since record could not be found.
In the case of an `ir.config_parameter` referring to a record ID
(i.e. Many2one), the deletion of this record is not propagated to the
associated `ir.config_parameter`. Therefore, the system tries to access
a deleted record without fallback.
It's not really possible to solve it globally in a stable version, but
we can manually handle these cases by providing a fallback (usually
return `False`).
opw-781864
Actually the signup template user to open is configurable and come from
an ir.config_parameter and is not necessarily the data created in
auth_signup even if it is the default value.
Indeed we store an integer that is the ID of the user to copy when
creating the portal user, not a boolean. We therefore have to evaluate
the result instead of comparing it to a boolean. This was introduced
at 689d6d6829.
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.
Let us completely support auth_signup_token and auth_login in request
session and parameters in the auth_signup module instead of in various
separate places.
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.
This commit duplicates the General settings' User Signup options in
the Website configuration, with a clear description of the options.
We also remove the unnecessary usage of safe_eval in auth_signup's
res_config.py. As stored values are repr values of a boolean field
just comparing the string values is sufficient. There is no need to
use safe_eval as it should be used only when necessary.
Currently, all the methods that start with `get_default_` and `set_` are called on a res.config.settings loading or saving.
This commit purpose is to replace all the occurences of `get_default_foo` and `set_foo`. As these methods won't be called anymore, a warning is logged to notice its deprecation.
The generic method `get_default_fields` and `set_fields` could be improved too. The method names and API are not so good:
Why "default" fields? What you ask for is the current value of the stuff, shown as fields in the model. The values are fed as default values in the wizard, but that's an implementation trick.
Why "fields"? What you ask for are configuration parameters, and such things.
Why passing a list of fields? Its value is never used.
We should further simplify the API of both methods to something like
def get_values(self):
return {}
def set_values(self):
pass
