Currently kanban columns propose an Archive / Unarchive option if the
records model has an active field. It allows to directly archive or
restore all records belonging to that column. It is currently not possible
to control whether this option is present or not as it only depends on the
active field being defined on the model.
In some specific cases we want to be able to hide this option even if the
active field exists. For example future commits will hide this option for
leads (crm.lead) as business flow goes through marking them as won or lost
instead of archiving / restoring them.
This commit adds support of a new archivable parameter when defining the
kanban view that hides the archive buttons if it is set to False. Default
value is true so that current behavior is kept as it is by default.
Doc and tests are added.
This commit is linked to task ID 1880051 and PR #26977.
The recently introduced `activity` view (see rev. odoo/odoo@1de9496 has not
received all the consideration it deserves as a real view type (no RNG, not in
the valid view `type`, no doc, etc.). It was currently only working based on a
`_get_default_activity_view` method.
Even if the RNG is currently really basic, its grammar could evolve in the future.
This was causing an issue when opening Studio with this view as a default view
with an invalid type was created.
Add a banner_route attribute to AbstractView to allow fetching html from a
controller route and displaying it above the view.
The initial use case was the onboarding panels.
Supported views are the ones inheriting both AbstractView and AbstractController.
The default "add a line" button creates a new line with the default values from the model. Sometimes we want to create a new line with different default values (or more generally a customized context), which is possible with this commit. Moreover it is possible to create multiple buttons for multiple default values/contexts.
This works both for in-line creation ("editable=") and dialog creation.
The new tags are:
<control> defines custom controls for the current view.
Does not support any attribute, but can have children:
<create> adds a button to create a new element on the current list.
This makes sense when the parent tree view is inside a One2many field.
If any create is defined, it will overwrite the default "add a line" button.
For more information and example, have a look at the Views documentation.
Technically, the commit will:
- parse the new XML tags (+ add appropriate validation)
- display the buttons based on the XML
- on button click/keyboard: pull up the additional context information from the button event up to the default_get
- add unit tests
- add documentation
PR #25209
We add the attribute default_order on the pivot view (already present in
graph view), this attribute will sort the pivot view on the given
measure.
Closes: #25675
Pivot view documentation was still inside the graph view documentation
as it was previously only a mode of this graph view.
As the pivot is now an entirely different view, it has the right to have
it's own documentation.
The way the calendar view selected its form view was broken for two
reasons:
- any value given in the form_view_id attribute was kept as string,
which means that the string value would be sent to the server, and
this is not good.
- if no value was set, the calendar view then simply did a do_action
with the form view id set to false, which means that the default form
view is used. This is mostly ok, except when we are in the context of
an action with a form view which is not the default one. In that
case, we clearly prefer the form view from the action.
For example, before this commit, the form view in the timesheet
application (community) is not the same as the default form view on
account.analytic.line.
Note that this commit also adds a small tweak to the mock server to
better simulate errors like the web client does (in session.js).
No mention of the group_operator attribute was made in the dashboard view documentation.
This fixes remedies this situation and slightly ameliorates the previous documentation.
This commit add the reference documentation for the new dashboard view.
In an ideal world, this should be done in the enterprise repository, but
our documentation system is not extensible that way.
The global link was redirecting to http://getbootstrap.com/components/ (without
the fragment identifier).
Moreover, now that Bootstrap 4.0 is released, this URL may be broken in a close
future.
Closes#24031
Before this commit, the 'limit' attribtue worked properly for list views
(but was not documented), and was ignored for inline tree views. There
was no good reason for that limitation, so we fix this issue.
* fix all warnings wrt patch application & al, only warning left is
only exercise-kanban being auto-guessed as an xml+django file and
then lexing failed (because it's only a small snippet)
* update sphinx-patchqueue to drop the requirement on mercurial for
patch introspection and application, though that means application
is significantly less forgiving (fuzzy application was not
implemented)
* crm, project
Add a new feature which allows to put a progressbar in the kanban
columns. The progressbar shows with the same color the amount of
records whose value of a given field are the same in the column.
It also indicate the sum of another given field or simply the total
number of records. It also allows to subgroup the column content.
To define a progressbar, add this as a direct child of the kanban
arch:
<progressbar field="<name of the field to use for subgroups>"
colors="{<one possible value for the above field>: <success, warning or danger>, ...}"
sum="<name of the field to sum or nothing to use total number of records>"/>
Also:
- Properly update record model data's parentID when moving a record
- ...
Thibault Delavallée