* generic strenght meter widget which can be included in various
places
* password field, taking over the isPassword special cases strewn
throughout the codebase, this should probably become an actual thing
in core /cc @ged-odoo, the meter is opt-in as most uses of
`field[@password=True]` are passwords & secrets for third-party
services or external servers for which a meter would not make sense
* separate override of the ChangePassword wizard which isn't a regular
view for some reason
* direct implementation for signup pages (create user & reset password)
Skip/comment/remove existing testing of @password fields: the policy
replacement/augmentation needs to make an RPC call and does not
support readonly use (because it doesn't seem to be used anywhere so
that made sense?); and there currently is no way to augment or
override/replace existing tests, so the tests will either fail when
auth_password_policy is installed (current situation) or fail when
auth_password_policy is not installed (if updated to be compatible
with APP).
Before this fix, in form view, when a datepicker was not visible (because
they were on another page or literally invisible), when the user pressed
TAB and the datepicker was positionned after the current field in the
form, it was capturing the focus during the activate phase of the
navigation_move.
This is not correct for invisible elements.
After this fix, only focusable datepickers get the focus during the
activation phase of the navigation_move.
co-author: aab-odoo (aab@odoo.com)
The datepicker lib has been updated to tempus dominus (BS4)
recently, but our code hasn't been adapted correctly to the
requirements of the new version of the lib. As a consequence,
the datepicker didn't close itself when the input was focused
out anymore.
This required a slight change in the DomainSelector widget as it
produced a crash when a focused datepicker widget is removed from
the DOM (before the datepicker is destroyed), e.g. by a call to
html() on one of its parent.
Task 1878254
Hardening of commit:995610c065bf0242cb5023cfad2940234395739e
The JournalDashboardGraph requires nv, which is lazyloaded.
However it requires nvd3.js which is loaded after nv.d3.js.
A function called in destroy is defined by nv.d3.js,
which can make the crashhappen with the right (wrong) timing.
opw 1873749
This allow the browser/device to handle the experience of handling number in a more native way.
FieldInteger and FieldFloat now inherits from NumericField because we want
to format it or not dependent of the view (readonly or edit) and the
NumericField will manage it.
We do that because input type number can't take a value with comma on Chrome
(FireFox is more permissive but not perfect because comma is the separator
for decimal in this case).
Task #1880376
Before this rev., there was a crash when a FieldDomain was reset
with a new domain (e.g. coming from an onchange). For instance, it
crashed in Email Marketing > create new Mass Mailing > select
mailing lists. Introduced by 68332a01.
opw-1882850
The domain was instantiated without being given any evaluation context.
As a result, the uid variable was not defined,
crashing the js if present in a user-defined filter.
opw 1866852
Since we correctly compute the height of the field, we don't want to let the user resize it vertically.
This was already working on Firefox because it doesn't require the field to be in the DOM to read the resize attribute, but Chrome does require the field to already be in DOM.
Task: 1869469
PR: #26518
Before this commit, a textarea inside a one2many would only have the correct size after focus or on change.
When we select a line, we want all of the textarea of the line to have the correct size even if they are not directly focused.
Task: 1869469
PR: #26430
Before this commit, a textarea would not resize when its value changed if the event was different than "input" or "focus".
This commit fixes it by also listening to the "change" event, and by triggering it at appropriate times.
PR: #26430
Task: 1869469
The box-sizing property was not correctly taken into account.
- content-box is the standard behavior: border and padding are added after the height
- border-box needs attention: border and padding must be included into the computed height
Task: 1869469
PR: #26430
This rev. allows to navigate, in mobile, through records in form
views by swiping.
We also moved mobile-specific tests involving a form view to the
mobile test suite, since those tests became async because of the
lazy loading of the swipe lib (in the mobile suite, that lib is
already loaded).
Related to task #34727
Co-authored-by: Mohammed Shekha <msh@openerp.com>
Revision on https://github.com/odoo/odoo/commit/10f43955d81ff3e7b5ab050656b312ec19f927c5
Commit above uses `testUtils.patch` in the test.
However, this utility function does not seem to work.
That sucks...
The lib 'nvd3' renders graph when they are attached to the
DOM. However, widgets are rendered in fragments and
appended to the DOM when ready (to prevent flickering).
Before this commit, we used a `setTimeout(0)` and cross
fingers that the widget was attached to the DOM when the
`render` method was called.
With this commit, the render method is called when it is
attached to the DOM.
Task-ID 1868252
Closes#26410
Before this rev. one could set the report layout on the company using a
hardcoded list (background, clean, standard, etc.). Other modules (typically
accounting modules) could add options in this list. The used template was built
on the layout key.
Now, the layout is a many2one field to a newly created model `report.layout`,
which is linked to a view with the layout architecture.
This gives more control to customize reports and create a new layout (without
creating a python module that extend the layout selection).
This commit provides new js widgets for list, kanban and form
views on float field.
1/ 'float_factor' displays the normal float field, but takes a
conversion factor as option. The displays value is the normal
one multiplied by the factor.
You can use the widget like
<field name="my_float_field" widget="float_factor"
option="{'factor': 2}"/>
2/ 'float_toggle' displays a button (in edit mode) looping on a
range of given value at each click. A conversion factor is optional
(default will be 1) to display a converted value, but sent to
non converted one to the server.
You can use the widget like
<field name="my_float" widget="float_toggle"
option="{'range': [0, 0.5, 1], 'factor': 2}"/>
'range' and 'factor' are put in the options.
In simple read mode, the widget display the value as a traditionnal
text (like a normal char field).
This commit provides tests and documentation for those 2 widgets.
Task #39079
Purpose
=======
- Quickly share the url to someone else (a client, a colleague,...)
- Ensure that the recipient can access at least
the portal view of the shared record.
- Typically used when a client cannot retrieve the mail to access his order.
The share link can be used in this case.
Specifications
==============
For any object inheriting form portal.mixin:
- Add a button SHARE (not visible in edit mode)
- When clicking on this button, a popup opens with :
- A warning message for tasks and projects only (see below)
- the link (like in gmail) that can be copied
- Recipients
- mail composer (with preselected template) ==> see below
- button [Send Link] [Copy Link] Discard
- After sharing document, put internal note like
"Document shared to xyz,...." with template message
- Anyone with the link, even anonymous user (not logged in) can have access
to the document with the access token provided in the url.
Impacted models:
- account.invoice (Community)
- project.project (Community)
- project.task (Community)
- purchase.order (Community)
- sale.order (Community)
- helpdesk.ticket (Enterprise)
Warning messages and access rules:
Allowed :
- SO canceled or draft will be accessible with the link
with access_token
- If the customer account is B2B (signup not enabled), the recipient
will anyway see the document as the user specifically wants the
recipient to see the document.
Restrictions :
- For Project and Task, if the privacy is not public, then, there is a
contradiction between the access_token mechanism
and the privacy of the document.
- A warning message will be displayed in the share wizard to inform the
user if the document cannot be visible by the recipients and to
ask him to set the privacy to 'Visible by following customer'.
The send button will, in that case, be hidden.
- To avoid to block the share for a new project, default privacy value
is now set to 'Visible by followong customer'
Technical implementation
========================
- Move the access_token mechanism (field + methods + mail controller)
to the portal.mixin to be able to use it in a generic way for each object
inheriting the portal.mixin
- Generalise a part of the _*model*_get_page_view_values method
into a single one in portal
- Generalize the _*model*_check_access into the portal controller of the
portal module
- Remove the init_column + default value for the access_token
> old records have an access_token,
> new one won't but it will be generated on demand via the get_access_token
Done for performance reasons
- Add share button into action menu separately. + kanban view context menu
(except for task and project where button not in action menu but 'simple'
button for task and project because other modules already provide action
to send documents by email, which is not the case for project and task.)
- Add a sign_token used to authentify the recipient in the portal view chatter,
if any. The message will be posted as if the user was logged in.
- Set the _get_share_url as private for security reason
- Add a redirect parameter to _get_share_url to get
If false : The direct portal view url
If True : The redirect url (mail/view/?)
- Cleaning up unnecessary code
- Bug fix :
- Before, if user was not logged and record had partner_id,
if partner id was null, post message was done as admin.
Now, the post message is done as public user.
- If the user had an uid but had no access_token, he could be able
to gain the access token of the record.
check_access_rights was missing in the get_access_action.
Task ID : 30985
Closes#25629
Revision on https://github.com/odoo/odoo/commit/4b3588feb2b7e260bf237b0f3944c90cdc47c3b5
In order to not replace characters with '*' in edit mode (because of `input`
with type 'password'), the above commit did not format the value at all.
The formatter of a char with the option 'isPassword' turns all of its
characters into '*'. That is not intended for password inputs, because the
content is hidden by the browser with the 'password' type.
The issue with not using the formatter is that an empty field has the value
`false`, so an empty password field produces an non-empty password input with
its value to 'false'.
This commit fixes the issue by forcing empty string for empty password values.
Note: if you use an integer field with password, falsy values (e.g. `0`) become
empty strings in the input value.
Before this commit, when someone was editing a password, the stored
password may not be the expected one by the user.
Steps to reproduce:
1. Open "Outgoing Mail Servers" form.
2. Set a password (e.g. "yop").
3. Save, then edit.
4. Add "y" at the end of the password field.
> Expected value: "yopy"
> Actual value: "***y"
This is due to the use of the char field formatter, which displays passwords
by replacing the characters with '*'. It is not necessary to do this in edit
mode, because it uses an input field of type 'password'. The browser
automatically hides the value of such inputs.
Any changes on a input field in edit mode uses the value of the input, so the
value of an password input should contain the password, without '*'.
This commit fixes the issue by using the formatter in edit mode for the input
of type 'password'.
Task-ID 1869565
Before this commit, Odoo used checkboxes in three different ways:
- A simple <input type="checkbox"/>, mainly in the frontend. The style
is browser dependant.
- Same as above but with the BS3, checkbox structure. The style is still
the same, but the alignement is supposed to be better (which is not
always the case).
- The Odoo official structure:
```
<div class="o_checkbox">
<input type="checkbox"/>
<span/>
</div>
```
which allows to have a cross-browser checkbox style and correct
alignements.
The goal after this commit is to only use the BS4 *custom* checkbox
structure to achieve the same goal as our official structure (and
remove that one):
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
/!\ Labels are now required (use a zero-width space if necessary)
- The dropdown structure was simplified, allowing to get rid of the
3-levels structure induced by <ul/> elements and dropdowns can now
contain anything. The class 'dropdown-item' is now mandatory for
each dropdown clickable element. The class 'dropdown-item-text' can
be used to add same padding and style but without making the element
have a clickable look.
- Dividers now use the class 'dropdown-divider'
- The way dropdowns are opened and hidden also changed (before the
'open' class was added on the `.dropdown-menu` parent, now the
'show' class is added on both the `.dropdown-menu` parent and the
`.dropdown-menu` itself).
- JS-wise, no click event handlers can be put on `.dropdown-toggle`
elements anymore (instead, use handlers for dropdown events).
- Carets are automatically put on `.dropdown-toggle` elements, so this
commit replaces the `.caret` elements with this. This feature was
possible to disable but would prevent us from adding a caret with
scss. Also, this simplifies the DOM. The 'o-no-caret' class was also
introduced to allow using the 'dropdown-toggle' class on non-caret
elements.
- Also adapt the scss to use $caret-width instead of $caret-width-base
* website_form, debian
Our old library for datetimepicker for bootstrap 3 is deprecated and
an updated version is developed by the same team under the new name
"tempusdominus", for bootstrap 4.
The lib is imported by taking the *unminified build* JS and the *src*
scss. Odoo is also bundling the lib better by putting the scss file
in both backend and frontend assets instead of only in common (so that
the scss is compiled differently for the frontend and the backend).
Note: the lib also needed to be patched inline to solve a bug at one
line.
It is useful to know when the stylesheet has been loaded in order to prevent displaying unstyled content.
CalendarView and the dashboard_graph widget (JournalDashboardGraph) use loadCSS through cssLibs / loadLibs so the tests now have to use createAsyncView instead of createView.
The value of the statinfo widget is rendered by the qweb after a t-esc.
Say if the python rounding returned 14.0000000001
(supposed to be a two digits precision number through the magic of floats)
then the statinfo widget would print it as-is.
We now format the value at assignation.
opw 1865426
- JS Modals were not correctly built anymore, their .modal-body element
was duplicated and many without-effect JS lines were introduced (as a
side effect, the form view design was broken when inside modals)
- Tests were changed to make bugs go unnoticed. For example, the media
dialog functionnality was entirely broken because the .modal-dialog
element was not receiving the correct class anymore.
- The JS translation function is _t, not _
- Do not use the <title/> tag as a regular DOM element, it is meant to
be unique, in the <head/> section
- CSS rules were added to the utils.scss file, which is meant to contain
functions and mixins, otherwise, the rule is duplicated in every asset
- Some icons were still broken, as missed by https://github.com/odoo/odoo/commit/f90cf060a3cfeb37a67bec83264c0aaab8892b56
- Tests were changed to use [role="dialog"]/footer/header in their
selectors without any reason, this commit restores some of that to
avoid rebase conflicts with the BS4 work.
- ...
Note: other elements should still be discussed, like the direct use of
the 'o_form_label' class in views definition... but those do not cause
direct problems.
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
Xavier Morel