Reorder res.config.settings for website
Make website_id in no create in most view
Revamp res.configsetting and view Form simplified
Transform old 'useless' stored field for presentation by computed field.
We can consider that if there are not key, feature is disable.
Co-authored-by: rde-odoo
Co-authored-by: jke-odoo
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 'form-horizontal' class have been removed; the '.form-group'
elements must now use the 'row' class for an horizontal layout.
The 'control-label' class was renamed to 'col-form-label'.
The 'help-block' class was renamed to 'form-text'.
The 'has-error' and 'has-success' classes have been removed and
replaced by a new system using the :valid and :invalid pseudo-classes,
when a parent has the 'was-validated' class. While this system is great,
it is not straightforward to use it in Odoo. Fortunately, BS4 provides
the 'is-valid' and 'is-invalid' classes as fallback. This commit
replaces the 'has-error' and 'has-success' classes by 'o_has_error' and
'o_has_success' classes (for JS compatibility) and use the 'is-*'
fallback classes. (The 'has-warning' class has no equivalent but was
unused in Odoo anyway).
Today, Odoo is really tricky to use without seeing the screen, it must be improved to be usable.
This PR forbid to use labels without a "for" attribute, add some title, rule and aria attributes in HTML. With that, Odoo will be fully usable with a screen reader.
* [IMP] Labels must have a for attribute. Improve accessibility.
* [IMP] Better error message when trying to read a missing cached value
* [FIX] Add some aria-label and title attributes for screen readers.
* [FIX] Template name is not included in the error message in case of SyntaxError in QWeb
* [FIX] Improve the Tour failed at step error message to be more explicit.
* [IMP] Add aria-labels
* [FIX] Add missing aria-label on failing test
* [IMP] aria-hidden means hidden. Fix all bad aria-hidden and hide aria-hidden for all.
* [IMP] Color names on kanban views and many2many tags
* [IMP] Add some checks on views for accessibility.
* [IMP] Add `alt` attribute on `img` tags.
* [IMP] Add aria-label and title on non-described icons
* [IMP] Add button role to widgets with btn class
* [IMP] Translate aria and formatted attributes.
* [IMP] Remove wrong aria-labelledby
* [IMP] Add menu role on dropdowns
* [IMP] Buttons must be focusable
* [IMP] Add aria attributes on progress bars
* [IMP] Improve accessibility of basic widgets
* [IMP] Change main layout to more semantic tags
* [IMP] Add menuitem role when missing
* [IMP] Remove wrong role='presentation'
* [IMP] Improve accessibility of tab panels
* [IMP] Add aria-invalid on invalid fields
* [IMP] Add aria-sort on ordered columns
* [IMP] Add role on alerts
* [IMP] Use dialog role, header, main and footer tags for modals
* [IMP] Add labels on o_status
* [IMP] Improve accessibility of kanban view with feeds and articles
* [IMP] Add alerts in case of new messages
* [IMP] Add widget, navigation or img role to aria-labelled items
Before this commit, website.page xml record were created in 2 steps:
1. Create an ir.ui.view record with <template> tag
2. Create a website.page record with <record model="website.page">
But this is useless since website.page inheritS ir.ui.view, you can create both
records just in one <record> tag.
Note: This is NOT TRUE in every case:
Odoo's ORM will suffix external_id of inherited records (in this case the
ir.ui.view created through the website.page record) with its model's name.
This can be a problem in some case (this is an example):
website_crm_template.xml create an ir.ui.view inheriting the
ir.ui.view 'website.contactus'.
But if we didn't keep website.page & ir.ui.view records split for that
specific case, the ir.ui.view would inherit a website.page record
causing an error. (website.contactus would be the id of the page record
while the ir.ui.view's id would be website.contactus_ir_ui_view)
In short: when migrating an ir.ui.view (<record> xml) to a website.page:
* If there is record inheriting the ir.ui.view ID, then split
website.page & ir.ui.view
* if not, you can create the website.page and its ir.ui.view both in one
record (<record model="website.page").
This commit also removed remaining page="True" from xml template since we
removed the 'page' attribute from ir.ui.view model overrided in website module.
Before this commit, website.page had a 'name' field which was useless because
website.page inheritS from ir.ui.view which has its own 'name field.
At the end, we were duplicating/synchronizing 'name' field between
website.page and its ir.ui.view for no reason because we were always using the
one from ir.ui.view.
Now, getting website.page's name will always retrieve the one from its
ir.ui.view and there is no redundant information.
website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.
From now, we don't have a specific /page controller to serve 'page'.
We use a new model website.page which is rendered if none route matches the url
and that the field 'url' on website.page matches the request.httprequest.path.
The order to serve a path is:
- Routes defines in controllers (/shop, /blog, ...)
- ir.attachment with name matching the path
- website.page with url matching the path
- website.redirect with url_from matching the path
- 404
To improve:
- allow regexp in website.redirect model
- allow to edit the view_arch from the page.management via redirect backend
(needed when traceback in the page, or when modifying a js/css/less/...)
Purpose
=======
- Settings are too complex: too long + too many options that shouldn't be suggested with checkboxes
e.g. twitter roller is now suggested as a new snippet to install from website editor
google maps, slides, forum, etc. should show up in the apps store
- When saving the page I expect to stay in the settings -> no redirection to homepage anymore!
Specification
=============
See task 33620
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
If the feedback of a form is too slow, people might be tempted to
click a second time, trigerring a second request. If, after that,
the result has not been received yet, the user might be tempted
to click a lot of time because he is angry at such slowness. This
behavior would trigger a record creation each time the user clicked
the submit button. This fix disables the button once it has been
clicked once, and re-enable it if the record could not be created,
which means that there was an error in the input and the user needs
to change the values and try again.
The button has been changed to a span to avoid the default browser
behavior to post the form when no function is bound on the send button.
* make CSRF protection the default on all non-SAFE methods
note: there currently is no way to call a CSRF-protected endpoint
without a form-encoded entity-body as that's the only place we get the
CSRF token from.
* simple CSRF token generation: just use the HMAC'd session id, no
generating a new random token per session then HMAC it
* use constant-time equal function to avoid timing attacks
* assert that a database secret is configured before hashing/validating
the CSRF token
* opt-out database manager from CSRF: The super-admin password serves
the purpose of a CSRF token in the database manager screens.
There is no request database to obtain the
secret and generate a CSRF token.
NB : Some tests have been modified.
One assert statement in orderpoint_calendar.yml has been modified,
but the change is legit has no python method has been modified at all
get argument are processed and set into input fields + hidden fields
save some datas from http headers
controller should save all the submitted vars
bzr revid: chm@openerp.com-20140310162626-libizyxlycvuwo7h
- added error management in contact us form, using a new error argument in the view;
- improved thanks template, to display more like contactus with company description;
- extracted company description in website to be able to re-use it in thanks template
- added optional company_name in contactus form, used to flil partner_name in lead
bzr revid: tde@openerp.com-20131002114818-y369gu6u32uxry1m
Jeremy Kersten