Steps to reproduce:
- Install "Sales" module (for test purpose)
- Change company name to `בונז " ור מונד` (notice the double quotes)
- Go to "Settings > Users & Companies > Users"
- Select any user and then click on "send an invitation email" button
- Go to inbox and check the email
Issue:
No email received (at least not in main inbox).
Cause:
The email is not received in main inbox (Gmail or Outlook might flag
them since email from is not well parsed) because the `email from`
value is not escaped properly (by escaping the double quotes).
Solution:
Instead of using the company name (that is not escaped) and email to
build the `email from` value, use the company email_formatted value
instead (and fallback on user mail if not available).
opw-3097910
closesodoo/odoo#114534
X-original-commit: 0c4cb5e3cc2758cb27e94ecbbcfaa734ba5a50eb
Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
request.geoip is no more a dictionnary cached in the session. It is now
a full blown object with lazy and smart geolocalisation capabilities.
Among other things, the previous dictionnary API is now deprecated. The
changes are:
* `request.geoip['country_name']` -> `request.geoip.country_name`
* `request.geoip['country_code']` -> `request.geoip.country_code`
* `request.geoip['city']` -> `request.geoip.city.name`
* `request.geoip['latitude']` -> `request.geoip.location.latitude`
* `request.geoip['longitude']` -> `request.geoip.location.longitude`
* `request.geoip['region']` -> `(request.geoip.subdivisions[0].iso_code if request.geoip.subdivisions else None)`
* `request.geoip['time_zone']` -> `request.geoip.location.time_zone`
It is safe to access all the attributes. Doing `request.geoip.city.name`
when the geolocalization failed (missing db, invalid address, ...)
evaluates to None. It does not raise an AttributeError.
Task: 2848206
Part-of: odoo/odoo#91337
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Allow our users to modify mail template more easily
- make the list accessible from the settings
- give them a link to update relevant views to update header/footer
- make the list and form of templates more readable
- add a description on templates, allowing to describe their usage
In order to better filter templates, a new category field is added that
is computed based on active flag, description being set and the template
having an xml ID. Master templates are active, with a description and an
xml ID.
Update master data to add description on some templates.
task-2944770
closesodoo/odoo#101730
X-original-commit: dfa867343ee8842f3f127ac62584fd471b41dde1
Related: odoo/enterprise#32079
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
Commit "[IMP] core: don't save visitor default session" moved the geoip
from the session to the request with a deprecation warning. This commit
adapts the remaining modules to use `request.geoip` instead of
`request.session.geoip`.
Geoip is always set on the request but it can be an empty dictionnary in
case the geolocalization failed.
closesodoo/odoo#86015
Task: 2789035
Related: odoo/enterprise#25192
Signed-off-by: Julien Castiaux <juc@odoo.com>
When using the odoo app,
`request.httprequest.user_agent.browser` is `False`,
instead of a string expected.
Therefore, `capitalize` cannot be called
```
2022-03-02 09:44:01,267 1321846 ERROR dle-test1 odoo.addons.saas_trial.models.res_users: 2fa by email failed
Traceback (most recent call last):
File "/home/odoo/src/custom/trial/saas_trial/models/res_users.py", line 267, in _send_totp_mail_code
return super()._send_totp_mail_code()
File "/home/odoo/src/odoo/saas-15.1/addons/auth_totp_mail_enforce/models/res_users.py", line 95, in _send_totp_mail_code
'browser': request.httprequest.user_agent.browser.capitalize(),
AttributeError: 'NoneType' object has no attribute 'capitalize'
```
closesodoo/odoo#85684
X-original-commit: 5a87db453fcfd750934d1a1d62c00d93ad01c0e1
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Add the possibility to force the two-factor authentication for all users,
using a two-factor authentication by email
when the 2FA using an Authenticator app is not configured for the user.
Two possibilities:
- Force the 2FA only for employee users using the system parameter `auth_totp.policy=employee_required`
- Force the 2FA for all users, employees and portals, using the system parameter `auth_totp.policy=all_required`
closesodoo/odoo#83750
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Gorash