The attribute 'sample' is now also available for the reporting views
(the cohort, dashboard, graph, and pivot views). Here, we simply extend
the existing doc on the attribute.
Task ID: 2282196
Before this commit, the search panel was subject to some inconsistencies
when dealing with a category having enabled counters and with a filter
defining a "domain" attribute. Indeed, the counters could be in an
incorrect state if the right filters/categories were not loaded first,
with no simple way in doing so.
The search panel being complex enough as it is, we decided to disable
all categories' counters in the presence of a filter having a "domain"
attribute regardless of said domain.
closesodoo/odoo#55734
X-original-commit: e78f777bd8ccb314b85451cbc8d1dd9109997d7a
Related: odoo/enterprise#12341
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit adds the parameter `scales` in the calendar view's template.
This parameter can be used to choose which mode(s) is/are allowed.
This commit also refactors the way we manage calendar scales.
Before scales were defined in model and renderer, now it's defined
in the view and given to model, controller and renderer by params.
Task: 2193921
This commit adds a new year scale to the calendar view.
It comes with a new view in the calendar, this view displays a
4x3 grid which cells are month views.
Task: 2193921
Documentation of the affected blocks have been updated to inform about
the contents of the "today" and "now" context values.
closesodoo/odoo#54438
Related: odoo/enterprise#11831
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Since
https://github.com/odoo/odoo/commit/369c20a99bd25172f72f4efde870172a4729aadc:
event cards cannot be customized anymore, only the popover is adapted
depending on <field> attributes inside the calendar tag.
Forward-Port-Of: #54984
original commit: 920599a46e1221c03a20e005a7ad5c61fa9107a0
X-original-commit: ef18d482a58bbff24ce1217619df603ec4670002
Until now the "widget" attribute used in the search view was meant to
force the type of a field regardless of its definition. This system was
implemented quite a long time ago and is now useful in only one case:
searching for "reference" fields (we want them considered as char fields
else it is impossible to search on them).
This is why this commit completely removes the "widget" attribute
support in search views while consistently casting the "reference"
fields as "char" fields in the search bar.
Task 2061795
Otherwise the reStructuredText parser thinks the first definition
title is part of the preceding paragraph, and the definition item is
interpreted as a quote due to the indentation.
closesodoo/odoo#54709
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Before this commit, when the same field occurred multiple times in
a form view, all occurrences were associated with the same id, and
all occurrences of the corresponding label (if any) had the same
'for' attribute. As a consequence, besides the fact that there were
warnings in the chrome console, clicking on any occurrence of the
duplicated label focuses the first occurrence of the field.
This commit generates a unique id for each pair label/field, when
possible. However, there is a case that can't be handled
automatically: when the label isn't automatically generated (field
located outside a group, or with nolabel attribute set to "1").
Typically, in this case, there is a <label> node with "for"
attribute referencing the associated field. In this situation, the
id must be defined in the arch, and used in the "for" attribute:
<form>
<label for="phone"/><field name="phone"/>
<label for="phone_2"/><field name="phone" id="phone_2"/>
</form>
Task 2261697
With this commit, it is now possible to display sample (fake)
data in empty views, in the hope of easing user onboarding.
This can be enabled (in list and kanban views) with attribute
sample="1" on the arch root element. In this case, if there is
no data to display, sample data will be generated based on
heuristics (depending on field types and names). This can be
used in addition to the no content helper.
Task 2232801
X-original-commit: 7c8e627ff5029cb539d702705e5ce53d658c76ed
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jérémy Hennecart <jeh@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit adds the support of nolabel attribute on fields
in list view. This attribute can be used to empty the column header.
Example of use:
<record id="module_example_tree_view" model="ir.ui.view">
<field name="name">module.example.tree.opportunity</field>
<field name="model">module.example</field>
<field name="arch" type="xml">
<tree>
<field name="name"/>
<field name="tag_ids" widget="many2many_tags" nolabel="1"/>
</tree>
</field>
</record>
Result:
This will create a tree view with 2 columns.
The second column will have an empty header and won't be sortable.
Name |
--------+--------------
Record1 | [tag1]
Record2 | [tag1][tag2]
Record3 | [tag2]
closesodoo/odoo#52302
Task: 2269315
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
PURPOSE
Currently, reporting views such as the bar and line charts have
their x-axis sorted either alphabetically or according to a
sequence. When reporting, the user would be interested in sorting
the x-axis values by their measure.
SPECIFICATIONS
Add 'ascending' and 'descending' options in graph view for bar and
line charts
Task 2070103
closesodoo/odoo#49970
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
In list views, one can specify decoration-XXX attributes on the
arch root node. Those decorations are evaluated for each record,
and the corresponding style is applied on rows for which the
condition is true.
This commit allows to specify those decoration-XXX attributes on
field nodes as well. In this case, when the condition is met by a
record, only the field on which the attribute is set will be
impacted.
Part of task 2195254
After this commit, in the graph view, when the user clicks on parts
of the bar and pie charts, it opens the list view of the concerned
records (like what was already done in the pivot view).
This is the default behavior, but it can be deactivated by setting
the attribute 'disable_linking' to true in the view.
Task 2198461
closesodoo/odoo#47796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
"Edition" is a French-English false friend word. "Edition" in English
means "version" whereas "edition" in French means "editing". This commit
updates user facing strings/documents that incorrectly use "edition" instead
of "edit" or "editing". Attempts were made to clean up English around
"edition" usage so please excuse any errors from lack of context
knowledge. Code comments and names incorrectly using "edition" were NOT
updated.
Enteprrise pr 6836 will allow disabling the delete button on gantt
views. Document it is possible.
task-2088954
closesodoo/odoo#40716
Related: odoo/enterprise#6836
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
In this commit, we add a new attribute "Delete" for user conveniency
if he don't want 'Delete' button on popover card they easily achive
by "delete=false" attribute and also add a testcase for it.
task-id:2088954
Now in a calendar view, if we use the color, attribute, it will use
the same color as Gantt views and the color picker widget.
The attribute color isn't more set as default in filter because it make,
in most situation, no sense to filter by color.
Now, we can add new filters in the right panel. To do that, we must
add the attribute "filter='1'" in the corresponding field line.
And if the filter has no direct link with the color of the model,
we can specify an attribute 'color' for this filter line block.
(for example color='color', and the color of the related model
will be used)
TaskID: 2153249
Add documentation about the new gantt parameter, `dynamic_range`,
The parameters were added in enterprise (odoo/enterprise#7640).
Task #2168740closesodoo/odoo#43052
Related: odoo/enterprise#7640
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
This commit corrects erroneous instructions in the documentation page for the installation of Odoo.
Additionally, the following changes are made:
- Add new instructions where the steps were not clear or complete enough.
- Replace some installation flows for an easier onboarding.
- Rework some parts of the page structure and display.
- Add a "running odoo" section for Mac OS.
- Fix display error in views.rst
task-2072822
closesodoo/odoo#42900
X-original-commit: 82471da5d63f07796c6df1639aa30cc4894d5891
Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>
Previously it was always possible to create within the calendar view.
For some modules this did not make sense and lead to confusing behavior,
for example: a new model instance created in the calendar view that was
not viewable in the calendar view, but was viewable in other views. By
adding a 'create' attribute (to be used in view xml), we allow users to
choose whether or not they want a calendar view to be able to create.
Note that this change does not affect the edit ability of calendar views
for existing instances.
Part of
Task: 2126530
Related to issue: #41517
The class has no effect but was still referenced in the documenation
closesodoo/odoo#41629
X-original-commit: 063098bdf3414ffa1db12d3bfc5999506c109329
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
For simplicity marker popup fields are declared as a direct child of the root
element.
consistency in the name of marker popup fields
added new 'hide_name' and 'hide_address' option in the calendar view
task-2009017
closesodoo/odoo#37433
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
only activate multi-edit on list with specific attribute.
When the attribute multi_edit="1" is set on the tree view the user
can select a/some records and it will activate the multi-edit
with confirmation dialog (even for a single record).
Also, on-change are not applied when using multi-edit
closesodoo/odoo#37525
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
This commit adds a recordsDraggable option on the kanban view that allows to completly disable
the drag and drop feature.
This is a preliminary work for the social 'Feeds' kanban where the user should not be able to drag and drop posts.
Purpose
=======
The commit 2849b5c introduces a new export mechanism of grouped
list views to xls files.
The issue with this development is mainly that the displayed records
are exported, instead of all the records that match the search
parameters.
To export all the records we cannot rely on the data from the web
client. This implies to revert 2849b5c, and implement it in a better
way.
Functional Spec
===============
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
Technical Spec
==============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export
shortcut should be displayed
Task 2072910
closesodoo/odoo#37087
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
PURPOSE
=======
Add the support of grouped exports.
Allow the user to export all records in one click from
the listview, without having to go through the export modal,
taking into account the domain, groupbys, and visible fields.
SPECIFICATION
=============
When exporting (whether it is from the modal or from the shortcut),
any groupby(s) set on the listview should be taken into account (all unfolded)
- UNLESS the export is import-compatible
- each subgroup header has an indentation compared to its parent
- the 'group headers' in the exported file should contain the
same info (label, field aggregates) as it has in the listview.
New secondary button on the tree view with label 'EXPORT' (to be confirmed...)
- the export shortcut disregard the selected records, it exports all records
according to the domain.
- the button is visible even if there is no selected records.
- essentially the export shortcut does the same thing as the following:
- select all records
- hit 'action' then 'export'
- hit 'export'
Define a boolean attribute on <tree> to specify whether or not the export shortcut should be displayed
Task 2072910
There are too many image sizes. Since they are stored resized this takes time to
generate when saving a new image, it's more rows on the attachment table, more
files on the disk, ...
64px is close enough to 128px that it can be removed without a big impact on
download size.
It will even reduce download and number of requests when both images are
displayed because now only one has to be downloaded and then benefit from cache.
The difference between the two is typically around 1.5kB which is negligible
these days, especially when the request overhead is around 0.5kB already, not
even taking into account other factors such as latency.
If a 64px image must absolutely be returned, it is still possible to pass the
size parameters to the image route. But the current guideline is to handle
resizing in the views when necessary.
Views
=====
- remove width and height attributes when existing CSS rules are overriding them
(eg. `.oe_kanban_avatar` in the right context)
- add CSS rules instead of width and height attributes when possible
- use `object-fit: cover;` where width and height are forced to avoid distortion
of non-square images
- for products, use `object-fit: contain;` instead, keep ratio but without crop
- add new CSS rules where the expected size was max 64px*64px before due to the
image size itself
- remove `img-fluid` where using size classes to avoid conflicting rules
task-2060865
closesodoo/odoo#36147
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
This rev. makes the part of the progressbar corresponding to falsy
records 'alive': the user can now click on it to filter on records
whose value is false for the progressbar field.
Task 1952430
closesodoo/odoo#35100
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Having two attributes for this was probably overkill. We now have
a single attribute 'width' which can specify either a fixed width
(e.g. '120px') or a factor (e.g. '2.5').
For some fields (especially employees) it is nice to see a picture of the model on the gantt row in order to quicly identify which record is concerned. This is obvious for employees where we display their avatar picture but might be handy for other models as well. This commit introduces this functionality.
In order to activate it you should declare a avatars attribute on the gantt arch.
It is a python dict which keys are the fields name for which a thumbnail should be displayed (ie: 'employee_id') and the values are the fields on that model that hold the image (ie: 'image_small).
If none is defined or the row isn't currently grouped by this field, nothing is displayed.
NB: it is expected that the field name (key) is a relational field to another model which has a *image* field.
related task 2009563, 2000719, 2024216
Mathieu Duckerts-Antoine