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
This rev. is similar to db9b91ff, but treats the x2many case.
Calls to the 'commitChange' function of renderers must not be done
inside a mutex, mainly since 241704536, as they could end up in a
deadlock. For x2manys, it was actually the case in practice in
Inventory > Operations > Inventory Adjustments > Create > select
'One product only' > select a product > try to edit the real
quantity in the editable list > focusout > deadlock.
The reason why the deadlock occurred in this view and not in, e.g.
sale.order, is due to the presence of the field_float_scannable
widget. Indeed, the barcode engine intercepts input events and
manually re-triggers them. As a consequence, the 'change' event is
not triggered on the field, and it does not notify the environment
of its new value by itself, until the field x2many asks it to
commit its value. Note that this might be an issue as well, as
onchanges are thus not triggered.
Task 1878254
Rev. f241441 recently added the possibiliy to define custom
controls (instead of the single 'Add a line') in editable list
views. However, it didn't take into account keyboard navigation.
Suppose that the focus is on the field preceeding the list, and
the user clicks on TAB, the code assumed that there was only one
control, and focused it. However, when there were several control,
the last one was focused (which is typically the less common one),
and there was no way to navigate to the others.
This rev. focuses the first control by default, and allows to
navigate through controls with RIGHT and LEFT. Pressing TAB still
moves out of the list, to the next field.
Note that i'm not happy with this fix, as the logic doesn't seem
to be in the right place. Indeed, the notion of controls is the
concern of the editable list, not the x2many field, so the list
should handle this logic by itself. Unfortenately, this is not that
easy to change, as for now the list doesn't even know that we are
navigating to/from its control(s), until we click on it/them.
Changing that will be for later, in master.
We also did a linting pass on the concerned code.
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
Before this rev., if the user clicked on a tag to open the color
picker, and then clicked in the dropdown, but not on a color, the
color picker closed itself, and it was no longer possible to open
it again.
This issue came with the migration to BS4 and its following fixes.
As the color picker is now a classical BS dropdown, it closes
itself automatically, so we don't need to manually close it on
focusout.
Task 1878254.
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
Suppose you select a customer for a sale order.
You type the beginning of his name "think", and a name_search is triggered
which finds matching results, with first result "Think Big Systems".
There are three ways to select it: click, enter or tab.
Now there can be a warning set on this customer
("Bad client, only accept cash", or "good client, offer discount").
In that case, clicking on tab would trigger the onchange displaying the warning,
but it would also set floating to true, which means a dialog to create client
"think" would appear.
This happens if the onchange is delayed, and thus the call to reset the floating
state is triggered only after the focusout completed, instead of before.
Coauthored with @aab-odoo
opw 1866619
opw 1874475
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
289adeb63f introduced a bug where we tried to trigger an event on an element that didn't exist. Indeed there is no input if it's not in edit mode.
This commit fixes it.
PR: none
Task: none
When there is no handle field, there was an unnecessary margin-left. When there was a handle field, the margin-left wasn't the correct way to align it.
PR: #26566
Task: 1869469
* mail, calendar
- Fix traceback when clicking on a tag without color field (introduced
in recent changes)
- Properly allow to delete tags on firefox (a button obviously cannot
contain another button)
Closes https://github.com/odoo/odoo/pull/26547
Thanks to @hbh-odoo
-Some tests where moved without addapting the path to them:
path is now update and tests fixed.
-A picture was removed in commit 4dce6cc98b but
still referenced in template website_twitter_snippet.
-A test was missing a data leading to the wrong path to image beeing loaded
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
In a one2many, pressing ENTER or TAB from a required input (of type text or char) that is on the last editable column of its line would fail to navigate to next line.
The issue was that the validation of the required field would happen before the change to its value was actually applied.
This commit fixes it.
PR: #26430
Task: 1869469
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>
Currently, to remove link of x2m field from any record, sometimes there's no way.
For example, if we are on mobile and open any Quotation, it's linked quotation lines
are automatically converted in kanban, and there is no way to delete a line from
that quotation. However, in some of the manually designed kanban, there is special 'x'
for removing / unlinking x2m record, for example, Contacts of Partner.
This commit makes the behavior more consistent. During edition (mobile and desktop), if
a view dialog is opened on click of x2m field, it will have one 'Remove' button (based
on user rights) on right side of dialog footer, allowing users to delete / unlink the
record. Moreover, in mobile, the modal is opened fullscreen, with sticky header and
footer.
Related Task# : 31641
Closes PR #15857
Co-authored-by: Mohammed Shekha <msh@openerp.com>
example: <field name="product_id" options="{'no_open': True}" readonly="1"/>
This has been broken by rev. 43d21dd9c due to misplaced parentheses
(an empty object in javascript being truthy).
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
From this rev., the empty value isn't available in the options of
required selection fields, thus preventing the user to unset it.
Related to task #49262Closes#24404
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)
Christophe Simonis