Indeed using fromkeys with a list / dict as argument leads to the creation
of shared list / dict. This could create some ugly side effects when
used in loops. This commit fixes or cleans this kind of statement to avoid
unwanted side effects.
leading to potential issues.
Now the behavior is back to its previous version, posting on the user creates a private
discussion. Fixed management of model variable in message_post to avoid posting messages
on the mail.thread model.
Classic inbox writes on partner, with hr it writes on the employee profile, like previously.
This can give a performance boost on large databases
and should not be a concern in terms of access control
as the inheritance already grants access to the parent
records.
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
The delete-rule was initially set to `cascade` in revision
6897.16.13 revid:odo@openerp.com-20120705141706-5gm5mmqode3bvkuc
because the ORM would not allow anything else for the FK of
an _inherits relationship.
This constraint was later lifted in 7.0 server at revision
4681 revid:odo@openerp.com-20121212210247-emrz5rf9ewcwdggu
so we can now switch to the intended default behavior:
when deleting mail aliases we never want to cascade delete
the child records, as that could lead to unwanted deletions.
On the other hand the aliases are automatically deleted when
the record they belong to is deleted, as a kind of internal
dependency. This is the intended safe way to delete them.
There is a special case when the same alias is manually set
on multiple records, in which case you will not be able to
delete any of those records. This is an acceptable exception
and should be manually handled if ever needed, by temporarily
linking the records to delete to new dummy aliases.
bzr revid: odo@openerp.com-20130827150708-62hqk8p7twd527n0
The parent record is the record that holds the alias. It is different
from the record updated or created using the alias. For example
projects have aliases whose parent is the given projet, and that creates
new task inside the project.
Updated alias creation and management accordingly.
This ownership concept is used to compute the 'followers' contact
settings of aliases.
bzr revid: tde@openerp.com-20130516164207-1zr0q6abw6a34ndf
Partner profile is now classic, no more email-routing.
Writing on res.users, basically, begins a private discussion.
With HR, emails on res.users are private discussions, other
are post on employee profile.
Some cleaning in Chatter about Followers of ... , now talking about
partner or employee profile.
bzr revid: tde@openerp.com-20130515153159-cm52byvb7w6m1sxs
alias_name is not required anymore
crm, hr_job, project, mail_group, res_users: alias creation is now different
and done more like other inherits, except an alias_model_name that is given
to the context to find the alias alias_model_id.
crm, jr_job, project, mail_group, res_users: updated form views using
aliases
mail_alias: added a filter on 'inactive' aliases (alias_name False) and
added a button to redirect to the related document if any
bzr revid: tde@openerp.com-20130409111158-bv04n5o01z9l3c17
Thibault Delavallée
Olivier Dony
Christophe Simonis
Raphael Collet
ssh-odoo
Amit Vora
Denis Ledoux
Christophe Simonis
Martin Trigaux
Vo Minh Thu
Christophe Matthieu
Cecile Tonglet
Fabien Pinckaers