With Safari, the function content_disposition must return "attachment; filename=\"%s\"" % filename
to avoid that Werkzeug raises an UnicodeDecodeError.
Fixes#6160
opw:634205
Allows exporting fields whose string is a non-ascii *byte*string (rather than unicode).
backport of 7286f4e424 fixing #773 to branch 7.0 by request of @flotho
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.
This reverts rev. 9f9e7ef0e1
As explained in 9f9e7ef0e1,
if a field "lang" is present in the view, clicking in any action item
in the more menu leaded for the action title to be translated
in the lang value of the form, such as in the partner form.
9f9e7ef0e1 fixed the issue,
but has as side-effect to not update correctly the active* keys.
So, if "active_id" was used in the context of the action button,
and the active_id was set in the dataset context, for example
because you come from another form, trough another action button
(For instance, Customers > Opportunities > Logged Calls),
the active_id was not updated with the current id of the record.
opw-620293
opw-617321
fixes#3462
In cases where data is directly given to the saveas_ajax controller,
the filename was not correctly set, as no read method was performed.
(The read call is useless as the data is already avaiable in such a case)
In such cases, the filename must be given in advance
opw-626707
In some cases, the data dispalyed in a list depends on the context
This context needs to be passed to the export method, so the exported data reflects correctly the data from the list view
If you redirect an user not logged, into /web?redirect=xxx, he was correctly redirect to /web/login?redirect=/web?redirect=xxx. But when user come back on /web?redirect=xxx, he was not redirected to xxx.
The question should be to have only one behavior when we redirect people, as well /web?redirect as well /web/login?redirect. But because we use both in actual code, we need to accept both for retro-compatibility.
bzr revid: jke@openerp.com-20140321115018-x4e3l3d1v0tp0dyo
Without that, OpenERP become unusable in IE due to the follows limitations:
- All style tags after the first 31 style tags are not applied.
- All style rules after the first 4,095 rules are not applied.
- On pages that uses the @import rule to continously import external style sheets that import other style sheets, style sheets that are more than three levels deep are ignored.
(http://support.microsoft.com/kb/262161/en)
bzr revid: jke@openerp.com-20140307174411-hejt3x324nlv6tjr
When user ask a specific database on a new session, the nodb router
has been used to find the route.
Depending on installed module in the database, the rendering of the page
may depend on data injected by the database route dispatcher.
Thus, we redirect the user to the same page but with the session cookie set.
This will force using the database route dispatcher...
bzr revid: chs@openerp.com-20140207154703-o0gl58i2b56eridx
Since we removed auth="admin" in favor of auth="none" with explicit superuser id usage,
the disable_db clause in ir_http#...auth_none() has only sense for /web and /web/login routes.
The web module is an exception because it's routes are registered for the nodb dispatching.
This is why the ensure_db() helper is moved to web client and will take care of the
web's auth="none" routes that needs a db to work with
bzr revid: fme@openerp.com-20140130091820-xezgqezsv2vnmlq1