| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
|
|
Steps to reproduce the bug:
1.Create a new company
2.Set a user in this company
3.Go to Helpdesk > All tickets > Create
It raised a traceback because stage_id was not defined
opw:710084
|
|
|
|
Make sure the widget won't crash when no `terminology` option
is passed.
Also for the translation extraction system to work, each literal
term needs to be enclosed in its own _t() call:
// No
var trans = _t(term || "Default term");
// Yes
var trans = _t(term) || _t("Default term");
The _t() function supports `undefined` arguments so the second
form is equivalent to the first form at runtime, but supports
proper term extraction.
Finally, simplified the implementation a little bit,
requiring `hover_true` and `hover_false` "action descriptions"
to be provided explicity in custom terminologies.
Previously we tried to reuse the values from `string_true` and
`string_false`, but they describe a state rather than an action,
so they are hardly ideal.
|
|
|
|
(1) The priority widget is based on a selection field.
So, this priority widget must support string values.
Before this commit, the widget worked correctly with numeric values.
For example: '0', '1', '2', '3' was converted to 0, 1, 2, 3.
But sometimes, we have non-numerical values.
For example: 'Normal', 'Low', 'High', 'Very High'.
In this case, we can not compare the elements to each other according to their values.
If you select 'High', we don't know if the star of the value 'Low' must be filled.
To fix this, we base the comparison on the indexes of the table of possible values.
For example:
[('A', 'A'), ('B', 'B'), ('C', 'C'), ('D', 'D')]
Now, if you select D, we know that A (with index 0) is smaller than D (with index 3).
This could be a behavioral change if you had [('1', '1'), ('0', '0'), ('2', '2')]
(2) When the selection field had no value, the 'o_form_field_empty' class was added.
In this case, the stars must be displayed without being filled.
|
|
|
|
This will be used on a sale_coupon_program
|
|
|
|
The "in_dialog" option of the domain field was not working correctly
when the field value was falsy as it did not consider it to be
"[]" in that case (as it is done without the "in_dialog" option).
Same goes for the dialog which displays the matched records.
|
|
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.
|
|
(Fixes #14824)
The hard coded limit dates back to a time where the browsers would crash
when using FileReader#readAsDataURL() on files of serveral dozens of Mb.
This limit is now obsolete and even IE Edge now supports the FileReader
api.
This commit removes the limit and turns it into an option so it's
possible to limit a particular binary field to a given amount from the
form views, eg:
<field name="image" widget="image" options='{"max_file_size": "200k"}'/>
Note: this feature only works when the FileReader api is available.
At time of writing, all major browsers supports this feature:
http://caniuse.com/#search=FileReader
|
|
|
|
|
|
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.
|
|
Introduced by 07bf7bf4f3af4.
|
|
On UNIX, the timezone modules conversions can be reset by using
`time.tzset()`. On windows this is not available and the timezone (TZ)
environment variable must be set before the first import of time module.
If not, all datetime gotten in python without specifying UTC (such as
datetime.datetime.now) could be wrong.
This was fixed with 4a77c6a0 in 2013, but has come back since 389c2ba97b
imported pkg_resources (which do a `time` module import) before that.
closes #14926
opw-693764
|
|
The number of records selected by a FieldCharDomain was only computed
with the base language.
But when selecting the domain with a modal window, or when sending a
mass mailing restricted to a domain, the current user language is used.
With this commit, the number of records is computed with the current
user language.
opw-693836
|
|
* 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.
|
|
84a650e33aadb29661121410813e3de37a5ad3e9
|
|
|
|
|
|
|
|
Before this revision,
using a selection field with as possible keys `0`,
such as `require_payment` in `website_quote`,
resulted to the records field values to be stored
as `NULL` instead of `0` in the database.
This leads to the inability:
- To distinguish records with this selection field not set
or set to `0` (as both are stored as `NULL`)
- To search for records with the field set to `0`
(as they are considered not set)
For instance, while having `website_quote` installed,
search for sales orders with `Payment` set to
`Not mandatory on website quote validation`: It won't
return any result, even if you have some.
opw-697454
|
|
|
|
It was already working without it since commit e01837d2f4c683ef976fab0daec9e9afa36bbe82
|
|
|
|
Keep return line in ViewMode.
Courtesy of @odony
|
|
PURPOSE
=======
Usability Issue of "Archived" button. People tend to click on it accidentally
+ Also rename `Unarchive` into `Restore`
|
|
In the widget, the value of reference field is a pair `[val1, val2]`.
When the field is blank, its value is `[false,false]`, thus checking `[false,false] === false`
never succeeds, and this breaks the check for required fields.
|
|
|
|
|
|
|
|
|
|
When the statusbar is clicked, a `debounce` function prevents a
doucle-click, and therefore making several `write` calls. In debug
mode, the click doesn't work anymore.
For some mysterious reason, the event is propagated to the parent. The
`currentTarget` is not the `li` element, but the parent `ul`. By
setting the `immediate` argument to `true` (execute the first function
instead of the last), this solves the issue.
|
|
|
|
eg:
<field name="active" widget="boolean_button"
options="{
'terminology': {
'string_true': 'Published',
'hover_true': 'Unpublish',
'string_false': 'Unpublished',
'hover_false': 'Publish'
}
}"
/>
|
|
When we use firefox top or bottom arrow the ace container does not scroll automatically if the cursor is not visible.
|
|
* 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
|
|
|
|
|
|
|
|
When double-clicking on the statusbar widget, two calls to write are
performed. This can cause unwanted behavior, and when the `write` method
takes a lot of time to process, it's not possible to prevent it
server-side.
Courtesy of @gurneyalex and @aab-odoo
Closes #13135
opw-686025
|
|
Before rendering the radio button, the radio button must be unchecked
to ensure to take the last value checked.
Step to reproduce:
-From main menu, click on 'Contacts'
-Click on 'Create'
-Select 'Company' value on company_type field
-Save or not the contact
-Return in the main contact view (click on breadcrumbs)
-Click on 'Create'
Bug:
The default value on company_type field is 'Company'
but the fields that should be hidden are visible (example : parent_id field)
After the fix:
The value of company_type field is 'individual'
opw:684847
|
|
An issue occurs in the following use case:
- Create an automated action
- Choose a Related Document Model
- Select records to filter (click on "Select Records")
- Do not save, but cancel instead
- Create an automated action once again
The filter domain keeps the same value than previously, forcing the user
to refresh the page to get rid of it.
opw-683214
|
|
'Unpublished'
Another reason why it’s better to change ‘not archived’ into ‘active’ is
because ‘active’ is the functional name of this field in the filter list in list view.
For the rest, it’s just a better en_US way of saying it.
|
|
|
|
|
