| Age | Commit message (Collapse) | Author |
|
|
|
Since all workflows have been removed, remove the menu to edit it, since
it generates a traceback and confuse users.
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
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.
|
|
|
|
Mixing the use of btn-xs and btn-sm was not good for design.
This commit use btn-xs for "add a filter" and "edit domain"
buttons to improve elements alignment.
|
|
Some domain fields are initialized with a model which depends of another
form field value. Sometimes, this value is False and the domain selector
cannot be used during that time (and was even performing useless RPC).
Now, in this case, the field domain is fully replaced by a message
which explains that a model have to be set. If you don't want this
message to be shown, you still have the possibility to not show the
field domain when there is no model thanks to the "invisible" attrs.
|
|
|
|
|
|
Now, the form FieldDomain has an option "dialog" which allows to force
the domain *edition* in a new dialog. This allows the field to be
positioned in smaller area of the form view in some contexts.
|
|
The FieldDomain is composed of a DomainSelector widget and a button
which allows to see the records which match the domain (or an error
message if the domain is wrong).
The button was placed below the domain selector. Now, in edit mode,
it is placed at the top-right of the domain selector, saving some
vertical space.
|
|
* base_action_rule, gamification, mass_mailing
1) Create the independant DomainSelector widget
- Allow to build a prefix char domain
2) Replace old FieldCharDomain with a new FieldDomain which uses the
new DomainSelector widget
3) Create the independant ModelFieldSelector widget
- Allow to build a valid field chain for a specific model
(e.g 'partner_id.name' for a 'res.users')
- Used by DomainSelector widget
---
The DomainSelector widget uses a tree-like representation with
user-friendly buttons (ALL/ANY/+/-/...). Any domain can be built,
except those containing the "!" (not) operator or some operators
like "like", "child_of" (@see DomainSelector). However, if the
user enters these in the debug input, the widget can handle them.
Note: these widgets had to do unusual stuff the widget API does not
allow to handle efficiently right now but it will be adapted to the
new widget/field API in a further update.
Note2: the widgets also have possibility of other improvements like
supporting m2o input instantiation in DomainLeaf, etc.
---
This work is an adaptation of the original code made by @pga-odoo.
|
|
Before this commit, the pager counters and buttons were at the same
level, and could not be styled independently (with some rules such as
nowrap).
Close PR #14865
|
|
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
|
|
In export wizard on mouse hover display technical name of field in debug mode
|
|
In the pivot view, when the user select a new field to drill down, the
previous dropdown menu displayed all the groupable fields as valid
choice. This commit disables all the fields that have already been
selected. It means that they will be greyed out, and inactive in the
UI.
|
|
* Do not assault the user with a full traceback on bug, but indicates
an error occured and allow him to toggle the traceback
* Automatically scroll the traceback to the end (better for python
errors)
* Propose the user to report the traceback by using a new "Copy"
button which correctly copies the full error + traceback
|
|
Make it such that the buttons "Save" and "Discard" are still visible.
|
|
It is more logical to display it next to "Leave the Developer Tools"
|
|
This link was useful when the "Technical Features" group was not linked
to the "?debug" parameter. This is not the case anymore, and this button
has no effect.
|
|
|
|
|
|
* The debug manager contains a feature to launch tours, adapt it
to new web_tour.tour system
* The website help menu allowed to relaunch tutorial tour in debug
mode. This feature is not adapted to new tour system and was useless
in the first place (debug mode in frontend is barely used anyway).
-> remove the website help menu and the feature
|
|
|
|
* display all lines and don't display the scroll bar into ace editor
* lazy read ace lib and add missing lib file
* use not minified version of ace lib
* Move ace lib from website to web
* Added ace widget for webclient
* XML mode for view text box
* Python mode for server action text box
* Removed web_ace_editor.xml, instead added template in base.xml itself
* Added widget=ace_editor in compute field of ir.model.fields
|
|
Fp request: In the user preferences menu, remove "About Us" and put the version number in the Settings dashboard somewhere, as well as the link to switch to developer mode. Odoo is not a desktop application anymore.
|
|
dashboard"
This reverts commit 328af5dc8608172505fa6761190bf349e7656d89.
|
|
Fp request: In the user preferences menu, remove "About Us" and put the version
number in the Settings dashboard somewhere, as well as the link to switch to
developer mode. Odoo is not a desktop application anymore.
|
|
|
|
When there is no `color` field on the model
e.g. On invoice line taxes
The color class to apply on the badge was set to
`o_tag_color_undefined`
which doesn't exist. It must be set
from `o_tag_color_0` to `o_tag_color_10`
in order have a color.
Because of this, the taxes in the invoices lines
were not visible, because they were written in white
on a white background.
This has been broken by the below revision:
fe66472e2cf7844c21ec438921307330ae562668
removing the or statement (`||`) to set a default
color for models not having a `color` field.
We choose to set `10` as default value, so the color
remains the same compared to the previous release
(light grey). However, if the new behavior chosen
by the usability is to have these in black, it should then
be changed to `0` again.
|
|
|
|
|
|
Quantity is perceived as Quantity of products, whereas it's the count of SO Lines. Renaming to Count
|
|
|
|
un-revert of fe66472e2cf7844c21ec438921307330ae562668 which have
wrongly been reverted with 977db823c7c84e9edc7c8cf8384eb9cf47275b3a
|