* Some literal actions (not stored) provide an empty string for
domains and contexts instead of (respectively) an empty array or an
empty dict literal inside the string. Treat those case as nothing
being provided.
* Likewise some literal actions provide nonsensical (but falsy, but
not False) values for view_id (such as an empty list). Yield a
``False`` view_id for all falsy ``view_id`` received (``0`` should
not be a valid view_id, so ``False`` works)
bzr revid: xmo@openerp.com-20120606123508-ndh3jpzw1nabf98n
* The action's context and domain are needed because they are
explicitly ignored by those codepaths when the action is ultimately
executed in the dashboard, and their data are needed: such flags as
group_by_no_leaf may be set in the action's context, or things like
the leads/opportunities filters which need to remain in the
dashboard view.
* On the other hand, some keys in the action's context may be
detrimental to the correct behavior of the action in the dashboard,
one such key (group) is the search_default_*: these default values
for the search view may have been unset by the user before adding to
the dashboard, we must not add them back. And since the dashboard
will instantiate a full action/view manager for each action there
will be (empty) search views which will try to make use of those
defaults.
As a result, add the action's context and domain to those of the
research while *creating* the dashboard action/section, *but* filter
out search_default_* context keys while doing so.
If new problematic context keys are discovered, they should be added
to the filter.
bzr revid: xmo@openerp.com-20120516153309-3eq957p1pbj99fun
The concatenator tries to only work with bytes without ever wondering
what is in the byte bucket: files are read to `str`, concatenated with
`str` (via join) and returned as `str`, usually considered to be utf-8
encoded. It's the author's job to correctly encode files to utf-8.
So far so good.
On runbot, there's apparently an issue in some CSS files in some cases
on the runbot: `web_dir` finds itself to be typed `unicode` (because
it contains non-ascii characters? Not sure at all), as a result
`re.sub` will decode the corresponding file data when trying to inject
the dir as replacement and the CSS reader will return a `unicode`
object.
Then, when concat_files try to compute the checksum it will need bytes
thus re-encode everything using the default codec (ascii) and the
non-ascii character(s) will blow up the encoding with a
UnicodeEncodeError.
Solution:
* Assume CSS files can contain non-ascii characters (they can, and
do), decode them using `utf-8` to get `unicode` strings in the CSS
reader
* Inject web_dir as usual via replacement, this still yields a
`unicode` object (a `str` web_dir will simply be decoded using the
ASCII codec, a non-ascii web_dir should have been decoded to
`unicode` using sys.getfilesystemencoding)
* Cleanly re-encode evrything to utf-8, so that the code outside the
reader only ever manipulates 8-bit "byte" strings
bzr revid: xmo@openerp.com-20120405070711-vjyw8g4mge2goyik
also removed custom blockUI and error management hooks since it's now a perfectly standard RPC call and webclient is already available
bzr revid: xmo@openerp.com-20120309140536-21u2ked9oc7eaie5
When selecting a saved filter, its data is now saved inside the
searchview's state, and re-used any time there's a search performed
(until the filter is replaced or the search view is cleared).
Some cleanup of the support code for loading filters
(SearchView.get_filters) also had to be performed in order not to fill
contexts with (potentially incorrect) crap in case the filter is
re-saved.
lp bug: https://launchpad.net/bugs/948219 fixed
bzr revid: xmo@openerp.com-20120307120323-pub0yuwjqk1r3y0p
Vidhin Mehta (OpenERP)