This commit adapts the directional icons to improve the usability and
maintain consistency with the ui icons library.
task-2818586
Part-of: odoo/odoo#116641
This module allows to add secret key to add the turnstile captcha on
each snippet website_form.
Cloudflare Turnstile
--------------------
A friendly, free CAPTCHA replacement
Turnstile delivers frustration-free, CAPTCHA-free web experiences to
website visitors.
Turnstile stops abuse and confirms visitors are real without the data
privacy concerns or awful UX that CAPTCHAs thrust on users.
closesodoo/odoo#119246
X-original-commit: 4aca39a533e9d41f5f452f36a1ffc001f586b4f4
Signed-off-by: Jérémy Kersten <jke@odoo.com>
This commit converts almost all odoo module by native module.
The goal is to deprecate odoo.define in favor of native module and then
simplify boot.js by removing the regexp that finds module dependencies.
task id: 3162300
closesodoo/odoo#117305
Related: odoo/enterprise#39118
Signed-off-by: Géry Debongnie <ged@odoo.com>
before this commit, the field and labels are aligned in different lines in the settings.
closesodoo/odoo#109683
X-original-commit: 5844a0446ef9712027aa08fc239bbb858d164b87
Signed-off-by: Arnaud Joset <arj@odoo.com>
Steps to reproduce:
- Set up a recaptcha on a DB
- Drop a form block on a website page
- Click on the submit button
- Toggle the Show ReCaptcha option
=> A traceback is displayed. The bug is quite obvious: we try to render
a XML template which has not been loaded.
A bit of history:
Before [1], the "google_recaptcha" app was a dependency of the
"website_form" and "website_mass_mailing" apps only. Both needed to
render this recaptcha XML inside a snippet option JS file. That XML
definition was lazy loaded by the related JS widget: it made sense for
the XML definition to be defined in the "google_recaptcha" app, as an
util to be lazy loaded.
After [1] and before [2], the "website_form" app was merged in the
"website" app directly. The "google_recaptcha" app thus became a
dependency of the "website" app directly. The same XML was still lazy
loaded by "website" and by "website_mass_mailing". Since the "website"
app is a dependency of the "website_mass_mailing" app, it could have
made sense already to move the XML definition from "google_recaptcha" to
"website". Although as it was still lazy loaded, it still made sense to
keep it as a "google_recaptcha" util.
After [2], however, the XML lazy loading was entirely removed. That
change is debatable (and being debated again for future versions). But
meanwhile, the XML definition still in "google_recaptcha" was put inside
the "web.assets_frontend" bundle. This is wrong at multiple levels:
- Website visitors never need that XML definition, it should never have
been added in there. We'll keep it however to respect stable policy.
- Since [3] (which occurred before [2]), the website editor UI is now in
the backend. Having the recaptcha template XML definition defined in
"web.assets_frontend" makes it inaccessible to editor options.
A fix could be to add the recaptcha XML definition in the
"website.assets_wysiwyg" bundle in the "website" manifest (as both JS
files which need that XML definition are defined in that bundle in
"website" and "website_mass_mailing"). It could be not really robust
though: if another custom app adds "google_recaptcha" as dependency and
put the XML definition in a different assets bundle, there could be
potential problems of having the same XML loaded twice (while the lazy
loading of before was smart enough to not load the same XML file twice).
As a fix, we put the definition in "web.assets_backend" directly. In
master, we may want to consider to reintroduce XML lazy loading and/or
move that XML file in "website" instead of "google_recaptcha".
[1]: https://github.com/odoo/odoo/commit/f8882698e8f4d1a3ad081522778344e2bd7aa0de
[2]: https://github.com/odoo/odoo/commit/39ea7a1fab257ab46a8faf97eea75cc37f8c43e5
[3]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
opw-3076185
opw-3096657
closesodoo/odoo#108005
X-original-commit: e76599d4b52f8c6a797907aeade5060dacd2987a
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Co-authored-by: qsm-odoo <qsm@odoo.com>
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>
Unused catch block arguments are now forbidden even when prefixed with an
underscore: if the argument on the catch block is not needed, the use of the
optional catch binding is enforced.
Part-of: odoo/odoo#105433
Remove most values uselessly specified because giving the same value as
the default one (see _DEFAULT_MANIFEST in odoo/modules/module.py)
* auto_install is Falsy by default
* author is Odoo SA by default
* summary & description are empty strings by default
* application is False by default
* test, demo, depends and data are empty lists by default
This will reduce noise/inconsistencies between manifests specifications,
simplify analysis of manifests content, ...
closesodoo/odoo#90209
Related: odoo/enterprise#26807
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
All named arguments on the catch block must be used. If for some motive
the named argument on the catch block is not used, its name must begin
with '_'.
closesodoo/odoo#85569
Related: odoo/enterprise#24867
Related: odoo/design-themes#552
Signed-off-by: Géry Debongnie <ged@odoo.com>
Before this commit, if there was a Google ReCaptcha public key
registered on the database, it was given to the backend along with
the assets in the `session_info` global key.
Since this key is meant to be used on the frontend to generate recaptcha
tokens, it should be available there as well.
Now, it is also given to the frontend version of the `session_info` key.
closesodoo/odoo#76600
Task: 2639095
X-original-commit: 27136cd09abfb4e012b0df2d53877534cbcdad28
Signed-off-by: Julien Mougenot (jum) <jum@odoo.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>
* google_recaptcha, mail, partner_autocomplete, point_of_sale, website
Now, to read session information, the module "@web/session" must be
imported. Not that, there is also the user service with all the user
information.
closesodoo/odoo#73201
Related: odoo/enterprise#19434
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
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>
Before this commit, the recaptcha widget got the database public key
from a qweb "t-set" directive fetching directly the key from the
database when rendering the template.
Now, it is loaded beforehand and given to the session_info instead.
This has been done to improve consistency in asset bundles declarations
by reducing them to the simplest possible templates.
Part of task: 2352566
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Simon Genin <ges@odoo.com>
*: google_recaptcha, website_form
Issue
- Install 'Ecommerce' module
- In settings, fill the "reCAPTCHA: Easy on Humans, Hard
on Bots" option with random wrong site key and secret key
- Open your ecommerce (go to /shop )
- Add any product to cart and and open cart
- Activate "Customize -> Extra Step Option"
- Process to "Extra Info" step
- Click on next
Stuck at this step since next button does not react.
Cause
There is an error due to re-captcha feature that
does not allowed to go to next step.
The second issue is that the error is not displayed
because missing message area in form.
Solution
Do not check recaptcha if 's_website_form_no_recaptcha' class
present in form.
Add span 's_website_form_result' to display error messages.
Replace 'public' by 'site' in error message to fit google
'field' name.
opw-2456098
closesodoo/odoo#66493
X-original-commit: eb9373522628fa01c3503fa802ded23adc1cbe1f
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
You can enable it in base_setup when you need it.
Depends of base_setup and not ir_http or website because you need to
be able to enable it for login form e.g.
closesodoo/odoo#61520
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Take argument _action_ of method _verify_request_recaptcha_token into effect.
Otherwise it always sends 'website_form' as recaptcha action to google
recaptcha service to verify the token, this would lead to failure.
closesodoo/odoo#60854
X-original-commit: f29a625857128617c2d4d795e648d5ad1f7ab8a4
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
* = base_setup, website_form, website_sale, website_crm,
crm_iap_lead_website, website_hr_recruitment, website_mass_mailing
Integrate reCaptchaV3 on website_form submit and website_mass_mailing
subscription.
You can now use ReCaptchaV3 to add reCaptcha verification in any module
using google_recaptcha.
Also added a better error management on the form with custom messages.
task-2217980
closesodoo/odoo#48466
Related: odoo/enterprise#9649
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Brieuc-brd