[translation] : placeholders are missed out for Translation  (Case:585261)
[translation] : placeholders are missed out for Translation  (Case:585261)
[FIX] ir_attachment filestore read on windows
Launchpad automatic translations update.
[FIX] ir.model: properly signal registry change for multi-process mode after altering model/db schema
Launchpad automatic translations update.
[FIX] base: allow admin to freeze the value of "web.base.url" config parameter.

This config parameter is automatically updated when the admin log-in.
As this value is mean to be used in emails and links given to users, we sometime don't want
it to be updated inconditionnaly. In some cases, the admin may use alternative, private or
even local uri to connect to the server, which may not be suitable for users
[FIX] *: fix/rationalize db logging to avoid incorrect values during logging

The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.

The tracker is now set at the earliest points
of request handling where we can:
- in web client, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)


The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
[FIX] registry: another pass of cleanup for registry signaling

Some important points to consider:
 - signaling should be done after any schema alteration (including module [un]installation),
   service registration (e.g. reports)
 - the changes need to be committed to the database *before* signaling, otherwise an
   obvious race condition occurs during reload by other workers
 - any call to restart_pool() must be considered a possible candidate for
   signaling, and the 2 above conditions must be checked

The number of explicit calls was reduced by forcing the signaling at the end of
Registry.new() in case `update_module` was passed as True. In that situation
we always want to signal the changes - so all the redundant signaling calls
can be centralized. We can also assume that the relevant changes have already
been committed at that point, otherwise the registry update would not
have worked in the first place.
This means that there is no need for explicit signaling anymore everytime
`restart_pool` is called with `update_module=True`.

Some missing cr.commit() and explicit signaling calls were added or
moved to the right place. As a reminder: signaling must be done
*after* committing the changes, and usually *after* reloading the
registry on the current worker.
[MERGE] registry: another pass of cleanup for registry signaling

Some important points to consider:
 - signaling should be done after any schema alteration (including module [un]installation),
   service registration (e.g. reports)
 - the changes need to be committed to the database *before* signaling, otherwise an
   obvious race condition occurs during reload by other workers
 - any call to restart_pool() must be considered a possible candidate for
   signaling, and the 2 above conditions must be checked

The number of explicit calls was reduced by forcing the signaling at the end of
Registry.new() in case `update_module` was passed as True. In that situation
we always want to signal the changes - so all the redundant signaling calls
can be centralized. We can also assume that the relevant changes have already
been committed at that point, otherwise the registry update would not
have worked in the first place.
This means that there is no need for explicit signaling anymore everytime
`restart_pool` is called with `update_module=True`.

Some missing cr.commit() and explicit signaling calls were added or
moved to the right place. As a reminder: signaling must be done
*after* committing the changes, and usually *after* reloading the
registry on the current worker.
[MERGE] *: fix/rationalize db logging to avoid incorrect values during logging

The setting/clearing of the tracking were not done
consistently, causing log messages that appeared
to come from one database while coming from another
one or none at all.

The tracker is now set at the earliest points
of request handling as possible:
- in web, when creating WebRequests (dbname, uid)
- at RPC dispatching in server (uid)
- at cron job acquisition in CronWorker (dbname)
- at Registry acquisition in RegistryManager (dbname)


The tracker is cleared at the very entrance of
the request in the WSGI `application`, ensuring
that no logging is produced with an obsolete
db name. (It cannot be cleared at the end of
the request handling because the werkzeug
wrapper outputs more logging afterwards)
Launchpad automatic translations update.
[FIX]res_users : add missing on_change function for res_user simplified view
[FIX] strip server action code before passing it to eval

Python 2.7's compile handles trailing whitespaces correctly, Python
2.6 does not and blows up.
[MERGE] base, res.users: added onchange_state() on res.users. Was crashing because the _inherits is not a real python inheritance
Launchpad automatic translations update.
[MERGE] OPW 585261: translations: corrects extraction of translation for placeholders
[FIX] setup.nsi: fix the posgresql registry check:

My understanding is that EnumRegKey will index (the last argument)
the given registry path. When nothing is found, it sets the first
argument to the empty string. Only if the given path is wrong an
error is generated. So we have to go to the DoInstallPostgreSQL
label.
Launchpad automatic translations update.
[IMP] deduplicate trans_parse_view code, rename for clarity

also correctly handle all translatable attributes in a <attribute name=...> extension tag