* 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
- Moved the web *.po files to /i18n to be consistent
with the addons convention. Using /po was considered
for a while because it played better with LP's auto-
detection of PO Templates, but that is not necessary
anymore, we now have full control on LP templates.
- In order to support addons that contain translations
for both the web addon and the regular addon part,
both kinds of translations are now merged in a single
addon/i18n/addon.pot file. Terms that are used by
the web part are now marked with a PO annotation:
#. openerp-web
so the web client can recognize them and only load
the relevant translations in the browser memory.
This is important because a complete PO file can
be rather large, e.g. account/i18n/de.po = 400KB.
- The web translation export scripts were updated to
behave properly for addons that have a non-web
part, and will merge the web translation in the
original POT file, annotating the web translations
as needed. These scripts are Unix-only and meant
to be used by OpenERP packagers when needed.
- The GetText spec says that PO auto-comments indicating
the source location have this form:
#: /path/to/file:lineno
However OpenERP's POT export system defaults to a modified
version of this format with an extra 'type' field:
#: type:/path/to/file:lineno
The babel extractors we use have the GetText format
hardcoded so a small patch is needed on the server
to make it more lenient and accept the standard
source annotation, defaulting to 'code' type.
This does not matter for openerp-web, but makes sure
the server will not fail to load the new PO files
that contain openerp-web translations with standard
annotations.
The patch for making the server more lenient was
checked in trunk at revision 4002
rev-id odo@openerp.com-20120202143210-05p1w24t6u77cyv8
- The existing translation sync and export wizards for
regular addons have not been updated to consider
web addons, so for the time being we will have
to export regular addons terms first, and run the
web export script (gen_translations.sh) on the
addons directory afterwards. This could be improved
later.
As soon as this change is merged we will have to
perform a full update of addons translation
templates in order to include the web terms as well.
bzr revid: odo@openerp.com-20120202145603-ffo0il0qnfp3r6gt
in stand-alone mode. Changed the import web.common to relative import
(because the the import-hook in the server is not able to load
modules with self-referential import).
bzr revid: vmt@openerp.com-20120116104329-k68li2vul4b3j7ry
turns out ElementTree has a hard time XML-serializing ``None`` (who'd
have guessed...), which is what it gets told to do when concat_xml is
called with an empty list of files.
Return an empty string and no timestamp (should probably be one there
at some point, but...) and fix the QWeb loader to not do anything when
it gets an empty template file.
bzr revid: xmo@openerp.com-20120113150641-6i3ot1jg7r3kpw3d
If the final semicolon of an openerp module is forgotten and the next
file starts with an expression (such as a parens, because it's a
third-party module using the module pattern, see Backbone.js or jQuery
for examples), the JS parser will not perform semicolon insertion and
will instead try to execute the module's wrapper/initializer function
by passing it whatever follows it (generally an other function).
This usually results in an error and stuff blowing out everywhere for
no obvious reason.
Concatenation of JS files now adds an explicit semicolon between files
(ideally it should only add one if it's missing, but that would
require backtracking in the file while skipping comments &etc, can't
be arsed and double-semicolons don't hurt much) to avoid this issue.
bzr revid: xmo@openerp.com-20120113150110-47j90oishtjrib7s
The default configuration for OpenERP Web standalone (launched via the
openerp-web script) is single-threaded for log-readability purposes.
web.common.controllers.main.Proxy.load has been added to wrap a
request to an HTTP handler inside a JSON (and/or JSONP) request, the
initial implementation was to perform a full HTTP call *from within an
HTTP handler to itself*.
Since the server is single-threaded and its only thread is already
busy, it can't handle the new request, and the client deadlocks.
Replaced this crap by also-crap-but-slightly-less-so: instantiating a
Werkzeug test client using the root application and proxying the
request through that. Avoids creating a new request from the server,
therefore does not deadlock.
lp bug: https://launchpad.net/bugs/905384 fixed
bzr revid: xmo@openerp.com-20111219145759-m10zgo3tcd6zjhcu
Ravi Gohil (Open ERP)
Xavier Morel
Raphael Collet
Christophe Simonis
Antony Lesuisse
Turkesh Patel (Open ERP)
niv-openerp
Thibault Delavallée
Fabien Meghazi
Olivier Dony
Vo Minh Thu
Florent Xicluna
vishmita
Roberto López López (OpenERP)