The search view's completion list should be in front of the search
view's drawer, which itself should (probably) be on top of the graph
view's "action" dropdown.
The graph view's dropdown itself needs a z-index > 0 to be in front of
the graph itself, otherwise it is inactive and unusable: it's visible
through the graph but not activable.
bzr revid: xmo@openerp.com-20130305093619-s1e5fbl80r7qnk5l
m2m lists inherit (from listview/view) the handling of access rights
attributes (e.g. @create, @delete) in which the access rights to the
related model are those checked for the view. This is generally true,
but *not* for m2ms: even if a user has no creation rights to the
related model, he can still create a *relation* between the current
and related models.
The m2m access rights are really governed by the *current* (source)
model, in which case the user won't get to see an "editable" view of
the m2m in the first place.
So just override is_action_enabled to disable it in m2ms.
bzr revid: xmo@openerp.com-20130305091956-zn6qtuo4tl0vh3bs
* really call initial get_selection() after binding 'change:selection'
overwise no value are assigned to internal selection list - resulting
to an empty statusbar when field type is 'selection'
bzr revid: xal@openerp.com-20130304230253-0e959r9sintwsd98
It is the call to upload_report() that triggers the registration
of the new reports in the system, as report services.
Unfortunately the `header` property of the report is cached in
the report service and taken from its value at
registration time. So that value *must* be written before
calling upload_report().
Also force the `Corporate Header` to be checked by default
as this is what users want in most cases, and forgetting
it at report creation makes it very hard to set afterwards,
as it is cached in the service.
Updated plugin binary as well.
bzr revid: odo@openerp.com-20130304173125-zky8rtdye64bep07
This leads to any subsequent view overwriting the current user's lang
or timezone with the one active when the filter was created,
generating dismay and discontent (e.g. part of the user interface
switching from spanish to english or english to german, depending on
the respective settings of the current user and the filter creator —
at time of filter creation).
bzr revid: xmo@openerp.com-20130304101414-mm6ai1dkltd7ard5
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)
bzr revid: odo@openerp.com-20130301182510-1fqo9o8di0jw95b5
Could happen when a worker thread is reused for another
database but does not go through all the dispatching levels,
e.g. for static resources served by werkzeug itself.
bzr revid: odo@openerp.com-20130301171616-joit5dvjx51ums1y
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.
bzr revid: odo@openerp.com-20130301151325-2ygvwp1cx4zms1as
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.
bzr revid: odo@openerp.com-20130301143203-e2csf5pkllwhmwqs
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)
bzr revid: odo@openerp.com-20130301120744-jfitcmze2jldecod
Evict record from BufferedDataSet cache as is done with button calls,
otherwise when caller reloads record (read) after having executed the
workflow action, it'll get the old one back from the BDS's cache.
bzr revid: xmo@openerp.com-20130301103543-jra87w2wm417tgyc
Chatter:
- now displays the 'To' of messages, aka notified people,
- now allows to Send a message or to Log a note, that is a message not pushed to anyone; however users that see the document still see the log message,
- fixed suggested recipient behavior: canceling the partner creation popup now correctly avoids creating a partner,
- moved 'Advanced wizard' button on top-right,
- unfollowing or removing someone from followers now displays a warning,
CRM, Recruitment, Issues:
- better management of customers/applicants: Chatter suggests to notify and add as follower the customer, or to create a partner based on the email_from,
CRM, Recruitment, Tasks, Issues:
- changing the user_id (salesman, responsible) still adds the related partner as follower; but now an unread notification is pushed, with the first email or first message if no email,
- updated and added if missing message_summary in kanban views, now displayed only when having unread messages, and the related number, to be more visible,
CRM:
- crm_partner_assign: fixed forward-to-partner wizard,
- crm_partner_assign: geo localization now also sets salesteam along with salesman,
- crm: fixed opportunity email_template,
- crm: removed 'Send mail' button, as the functionality should be covered by Chatter (but the code of the action is left untouched to avoid errors),
Mail:
- merged message_post and message_post_user_api because there was an opportunity to avoid doing similar things in two different methods,
- fixed email_from of incoming email not always stored,
- followers: authors of discussion messages are now added as followers, this is not only limited to incoming emails,
- followers: recipients of emails coming through the mail gateway are not automatically added as followers of the target documents,
- followers: slightly updated _notify, to be able to notify a partner of a specific message; the notification process is therefore accessible outside of the mail_message.create() process
bzr revid: tde@openerp.com-20130301101122-l18mr6hb0j5k4atv
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
bzr revid: chs@openerp.com-20130301095551-fzrlwblnawxqj9di
Could happen when a worker thread is reused for another
database but does not go through all the dispatching levels,
e.g. for static resources served by werkzeug itself.
bzr revid: odo@openerp.com-20130228173530-bs5pun9o09iobosi
Xavier Morel
Cedric Snauwaert
Chris Biersbach
Launchpad Translations on behalf of openerp
Xavier ALT
Olivier Dony
Quentin (OpenERP)
Thibault Delavallée
Stephane Wirtel
Fabien Pinckaers
niv-openerp
Christophe Simonis