| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Before this fix, the field 'color' was hardcoded in the m2m_tags widget,
which means that:
- one couldn't specify another field (problem for custom models, with x_...)
- if the related model didn't have the field 'color', a warning was raised
by the server
Now, the color attribute needs to be specified on the widget options if one
wants to display colored tags.
If the color is not specified, the tags will be displayed in grey.
|
|
Onchange RPCs return an object that may contain a 'domain' key.
When it does, its value is an object whose keys are field names and
values are the new domain for the corresponding field.
Before this rev., the 'domain' key was totally ignored by the
BasicModel. This feature is used for example in the account.payment
form view (go to an open invoice, click on 'Register payment'): the
domain of field payment_method_id is updated by the onchanges (e.g.
when changing the journal_id). As the domain was ignored, it always
displayed all possible payment methods.
|
|
The reference fields haven't been correctly implemented with the new views.
This commit restores their behaviour.
Note that an small improvement has been introduced in this commit.
Before saas-16, a `name_get` was done for each record (so 80 if the field
was displayed in a full list view), which is not optimal. The calls are now
batched by model (so one `name_get` by model appearing in the field values).
|
|
|
|
|
|
Since all workflows have been removed, remove the menu to edit it, since
it generates a traceback and confuse users.
|
|
Purpose
=======
Some field labels are not very explicit
Specification
=============
- Rename "Base Model" into "Model"
- Change "Trigger condition" (Condition Frist char(C) uppercase)
- Rename Domain into Apply on
|
|
Since the new views, the 'o_input' class has to be set explicitely on
<input/> and <select/> elements to have the proper styling.
|
|
|
|
|
|
|
|
|
|
If `d.message` is an empty string, `!!d.message` is false and the
crashmanager will try to display `d.error.data.message`… which does
not exist as it's a warning with an empty message not an upstream error.
That causes the crashmanager itself to crash, and even the warning
name/title to be lost.
|
|
from project task kanban view (PR #17165)
|
|
|
|
Closes #16576
Description of the issue/feature this PR addresses:
According to HTML good practices, when an element is used but there's no text displayed on the screen, the attribute aria-label should be used to label that element.
This is the case in the buttons to change view types (List, Kanban, etc) since there's no text displayed, but an icon instead.
This HTML attribute is specially useful for screen readers, which usually are not able to figure out a button's functionality when that button is not properly labeled.
Current behavior before PR:
Buttons are not properly labeled
Desired behavior after PR is merged:
Appearance should be the same, but the produced HTML should be of better quality, because it would fit more HTML good conventions and it whould be more accessible
Related issue:
I had already reported this issue on the branch 10.0 at PR #16030. However, I decided to report it on this branch, because I believe this branch is the right place to be reported.
|
|
Since the new views, the 'o_input' class has to be added on form
elements for them to be correctly styled.
|
|
Before this commit, it was only possible to click on input to
change the value of the many2many_checkboxes widget.
For better consistency, we must allow to click on labels.
|
|
Before this rev., the FieldRadio didn't work on selection fields
with keys like "0", "1"... i.e. strings that can be converted to
numerical values. This was due to an automatic conversion of those
keys to their numerical value by JQuery, so when the user changed
the value, an unknow key was sent to the server (e.g. 1 instead of
"1"), causing a crash.
This rev. changes the logic a bit so that the keys are no more
written in the DOM, but their index in the selection are.
|
|
In the form view, when the user saves a record (with a multilang instance),
an alert is displayed to display all modified translatable fields.
|
|
Since the rev https://github.com/odoo/odoo/commit/250e716c3a12e88acb4a199b427dc47d4ec55d5d
the class `o_input` needs to be set on an input to correctly style it.
|
|
Since the new views merge, a lot of design elements were broken. This
was particularly impacting the fields in the editable list view; indeed
the editable list view is not using an inline form view anymore so the
fields in the list were not properly styled as the LESS was still
defined assuming the form view environment (for example the invalid
fields were red for o2m fields in form view but not in editable list
view even though they got the right CSS class).
This commit refactor the LESS following these rules:
- No more division of non-layout and layout rules. Dividing LESS rules
in x_layout.less and x.less was a mistake. Many rules can be
considered to be layout and not layout at the same time, developers
always have to switch from one file part to the other, many CSS
selectors (and rules!) are duplicated for nothing, ...
- Field style is extracted from x_view.less and put in the new
fields.less file. As before, the fields_extra.less will contain the
rules specific to community so that the enterprise repo can override
those by replacing the whole file.
- Many classes have been renamed so that o_form_x_y becomes o_x_y as
many classes can now be applied outside of form view. These classes
should not be used in templates anyway.
The commit also changes the DOM of fields so that it is more minimalist
(no useless parent div, etc).
Input elements are not automatically styled anymore, they have to get
the o_input class explicitely. This allows to fix lots of small style
bugs of previous versions (required monetary field had not the proper
style, readonly m2m tags appeared as editable, ...). This also improves
the LESS code.
The editable list view should also completely stop flickering on chrome
and firefox.
The commit also removes the orange outline on list view dirty cells.
The commit also removes deprecated static xml, LESS and other code.
Notice there are still styles to restore/fix and LESS to improve.
|
|
- Fix the toolbar behaviour since there is no more dataset in the widget.
- Improve the communication beetwen the controller and the toolbar.
- Move the code linked to the document upload in the right file.
- Adapt the tests to mock the search_read done by ´document´ addon
- Adapt the mock server to be able to give a custom toolbar action
|
|
This field widget has been adapted to the new views.
This commit also introduces some tests.
|
|
Moves back the mobile rendering part of the FieldStatus to
enterprise, alongside all other tweaks to improve the UX in mobile.
This part had been moved to community inadvertendly in the new
views branch.
|
|
The field has been adapated to the new views.
This commit also introduces some tests.
|
|
In general, I think that we can safely consider that crashes are not the
intended behaviour.
In this case, viewing metadata crashed because we tried to format a date
which was not parsed (so, a string), instead of a moment object. We
simply just parse the date before, and it works as intended.
|
|
With the new views, the barcode mechanisms were completely broken,
because the view and widget JS code was totally changed.
This commit update and refactor all that code to make it work with the
new design philosophy. Also, it update the coding style.
|
|
- remove edit workflow link in debug manager. The workflow feature was
removed, but there was still a link in the debug manager. Clicking on
that link was a crash.
- the rpc to fetch a view was wrongly updated, so the return value was
not properly used.
|
|
+ Document and refactor the files using the new guidelines
* Now only non-technical names are used when building field chains and
domains (technical names can be used in debug mode).
* Better warnings are displayed when using the field and/or domain
selector widgets (also checks domain validity in both domain field
AND domain selector widget).
Also improve design (thanks to original work of @stefanorigano):
- Hovering 'remove' highlights the element that will be removed
- Hovering 'add node' btns shows where the new node will be created
- Restyle debug domain input field (make it similar to a text editor)
- Improve design and layout
- Resize inner fields
|
|
FieldStatus was broken:
- With a selection, the statusbar_visible attribute forces the choices
to display, the discarded ones do not appear at all (even folded)
- With a m2o, the fold_field option tells the field to check in the
relation to know if the choice has to be folded or not, this was not
properly supported
- Changing a m2o value was broken as the parseMany2one function did
not exist
- The status were misordered
- ...
* Also refactor the way the rendering is handled.
* Also modify all statusbar tests so that the statusbar widget is
placed in the form header tag (as it is the common use case).
|
|
We replace a bunch of formatting and parsing functions by an object
(parse or format) which can be used to dispatch on the correct type. It
allows us to remove the format_field and parse_field functions.
Also, we camelcase our new code and add some comments.
|
|
Add the implementation of the "FieldDomain" (widget='domain') in
basic fields file.
|
|
This commit introduce a full redesign of all JS views. We started
basically from scratch. The goal was to unify all the various views
under a common framework, to make them testable, to make then usable in
different conditions (in studio, or in the frontend), and to make our
lives easier.
Some important points are:
- we introduced new coding guidelines (camelCase, 80 chars width, ...)
- we have a brand new testing framework (still QUnit based)
- kanban view moved to the web addon
- calendar view (formerly web_calender) moved to web as well
- the tree view was removed
- all new code should be documented
We hope that this code is the start of a new era for the Odoo web
client, we want to have a high quality codebase, well documented, well
tested, well designed.
Work done by the framework team: mostly aab, ged, chm, dmo, qsm
|
|
|
|
|
|
|
|
Before this commit, wide images were larger than the form view.
|
|
|
|
Purpose
=======
When there are lots of shared filters then its difficult to differentiate personal and shared filters
Specification
==========
- Show all personal filters first as user will prefer his own filters to come first in list
- Show all shared filters after personal filter in list
- Add separator line between personal and shared filter
|
|
The library needs to have a 'relative' positioned parent to place
the datetimepicker correctly.
We don't do that in the template
anymore because it was not working in all the cases.
The template which instantiates the datepicker should define
a parent in position 'relative'.
|
|
Ironically, clicking on the dropdown arrow of the field selector was
the only way which was not opening the dropdown. It was indeed added
as pure design element.
This commit handles the opening and closing of the dropdown in a more
robust way... while simplyfing the code too.
|
|
|
|
Before this commit, the field selector had an unique option to filter
the fields it displays: filters.searchable, which tells the widget to
only display the searchable fields (which is the default). Now there
are two more options:
- fields: an explicit list of the fields to use (if null, let the
widget get the fields itself (this is the default))
- followRelations: a boolean which is true if the user can follow
relation to build a field chain (default to true)
These options are needed by Web Studio in enterprise where domain
construction for form view attrs can only use fields which are in the
view and do not follow relations.
|
|
from 3.0.3 to 4.17.42
|
|
|
|
|
|
Modern browser implement the autofill specs as described at
https://html.spec.whatwg.org/multipage/forms.html#autofill
This means that there is now a way to tell the browser when a password
field is supposed to be filled with the user's own password (e.g. on a
login field), and when it's supposed to be used to input a new secret
value (e.g. when changing someone else's password).
This can be distinguished by setting the autocomplete attribute
to `current-password` or `new-password`.
In addition, many browsers have decided to entirely disregard the
autocomplete='off' attribute value, because it is felt that using
a secure password manager (as provided by those browsers) is a net
gain for security, allowing users to pick stron passwords.
See also https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
Based on this, the framework should generally consider that
password fields in the backend are meant to be used for *setting*
new values (autocomplete="new-password", i.e. no autocompletion!),
whereas the password field on the login page can indeed be autofilled
with the user's current password (autocomplete="current-password").
In addition to making the above changes, this patch also
lets developer specify their own `autocomplete` attribute on
text input fields.
|
