This rev. reverts partially 1d76586a1b
This rev. is related to #3462
Regarding addons/web/controllers/main.py
---
name of model ir.actions.actions is not translated
it's the name of server actions, client actions and window actions
that are translated.
Meaning the name of the ir.actions.actions will always be in English,
even when passing the user language within the context.
Regarding addons/web/static/src/js/views.js
---
There is no reason to pass the field values within the context
of the /web/action/load call: The read methods of actions are
not overidden to use the field values. Besides, it pollutes
the context of the action, leading to unwanted behavior, such
as the translation of the action name within the lang available in the
fields of the form view (e.g. the partner form).
Initially, the field values added in the context has been added
within the rev. 542928adde
Indeed, sidebar_context (or sidebar_eval_context nowadays), contains
the field values, and the additional_context passed to /web/action/load
is an extension of this sidebar_context.
We are not sure the reasons why the sidebar_context was passed to the
/web/action/load, but we believe it was to pass the session/user context
containing the lang, timezone, and so on, not to pass the fields values.
If the list view had a default order,
for instance, default_order="create_date desc",
setting a groupby filter kept this default order
and the groupby list was therefore not ordered on the groupby field
In general, when setting a groupby filter on a list
we expect the list to be grouped by the groupby field
The reset of the orderby is done only when the list is not grouped
and a first groupby filter is applied.
The orderby is not reset when adding a new groupby,
when one was already applied.
It doesn't reset either when passing from 2 groupby clause to 1.
It doesn't reset either when passing from 1 groupby clause to none.
opw-627233
The mapping old api → new api mistakenly takes the last positional argument as
the context (fields_view_get() has an extra parameter after context.)
Fixes issue #2063
Added some cryptic comments so we remember a bit
why we have a complicated dance with on_close.
Basically we do not want to reload the
original form view until the last popup is closed,
in the case where several wizard (steps) are opened
one after the other.
If an action unlink the current records (e.g. unreconcile on account.move.reconcile), trigger history_back to avoid errors when trying to reload inexistant record (opw 607883)
This is a partial backport of saas-4 code (rev c0db6ae, 162ad1c) and should not be forward ported.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
The switch mode event was triggered even if the view was not actually switched
This leaded to inconsistencies, like adding the view in the breadcrumb history, while the switch did not happen
due to the way breadcrumbs work, the method adjust_view_top was
not called at the correct time. This had the unfortunate consequence
that the main view was on top of the header.
This fix is related to a37bad205b
This previous fix did solved the issue of its purpose, but had a side effect for actions using these active* params, e.g. search views
For instance, Go to Project > Projects, click on any project, you are than redirected to tasks/issues of this project
If you reload the page, an error pops up, complaining that active_id cannot be found
the height of the oe_view_manager_header is variable, and the top can't
be positioned correctly with pure css without a lot of work, so this
commit adds a touch of javascript to make sure that the view is
correctly positioned.
This commit is related to 8d49639933 and b88755c431
When hitting buttons of type object, the active_model and active_id(s) were kept, and, therefore, when calling a feature using the active* args, this feature used the active* args from the previous action.
Nevertheless, concerning wizards, the active* args should be indeed the active* args of the previous action, as wizards expects to have the active* args from the previous action. Thus, we reset these active* args only when this is not a wizard (target === 'current')
For example, from a sales order, hit the 'view invoice' button, and on the invoice, hit the 'send by email' button: The active_id in the send by email wizard were the id of the sale order, not of the invoice
add a div parent to oe_view_manager_body, and move the searchview
drawer inside oe_view_manager_body. This is in preparation to the
goal of making the oe_view_manager_body div scrollable
after some thought, the extra method insert was not really necessary.
It was at first a way to force the user to give two nodes to determine
where the searchview and the drawer were to be inserted. However,
the second node can be omitted, a perfectly reasonable default is
to append the drawer just after the searchview.
Then, the role of insert is exactly the same as appendTo, so it makes
sense to override appendTo and remove insert. Simpler, and the job is done.
Before, the searchview and the searchview drawer had to be instantiated by
the user and appended separately to their correct place. Now, the
searchview is responsible for creating/destroying the drawer, and the
user is responsible for correctly using the insert method with
the node where the searchview/drawer are to be inserted.
incomplete work. So far, the search view widget has been split in
two widgets: SearchView and SearchViewDrawer. The SearchViewDrawer
has been inserted inline, and some preliminary work has been done
to improve the layout.