This decision comes from the following bug:
- Go to Sales -> Quotations, and open any existing quotation in form view (the
partner must have an address defined)
- Click on the partner
- Click on the stat button "Claims"
- You notice that the address of the partner is included in the search
This is due to the context property show_address which is set to 1 when a
quotation is open. Therefore, it is necessary to filter out this keyword.
Since the prefix "show_" is used for only few context variables, it was decided
to define this pattern as a standard pattern to filter out.
opw-642893
To be able to see record attachments, you need to have
read access to the record.
To be able to add or delete attachment, you need to
have write access to the record.
The button add/delete were displayed as soon
as you had the read access, but if you had not the
write access, both buttons failed.
This revision do not display the add/delete
buttons of Attachment dropdown menu if you do not
have the right to add / delete attachments to the record
(you do not have write access to the record)
opw-640242
The menu was not present in 8.0 when going back from the mass mailing email
composer to the backend. This fix adds the current action id as a return_action
query string parameter and return to the correct action.
fixes#5591
opw-629526
27a48f8026 introduced the use of self.dataset
It appears it is not always defined.
Few lines above, self.getParent().dataset is used,
and looks to be always defined.
We therefore now use this dataset in order to get the context,
to correctly pass the current session language.
Closes#5416
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