- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415181108-b2ytpuxflr8srpqf
With the 7.0 model all accounting-related fields are synchronized
from company to contacts (both are res.partner records), so the
unique check is not a trivial unique constraint. It must be updated
to use a *partial unique index* that applies only to "commercial
entities" and not to contacts. The condition for being a commercial
entity is "is_company is true or parent_id is NULL".
If companies have unique vat/nrc numbers, then their contacts
will be consistent because they are automatically synchronized,
so the uniqueness between contacts does not have to be checked.
(The auto-sync is performed by res.partner automatically and covered
by tests in the "base" module)
bzr revid: odo@openerp.com-20130415175258-l15meqin80sbhggu
- res.partner must prevent creating loops in partner
hierarchies, and this can be done easily with an
extra _constraint using the ORM's builtin _check_recursion
- _check_recursion's implementation incorrectly
assumed that the provided 'ids' were unrelated
(not part of a common hierarchy).
- add tests for _check_recursion via extra
tests on res.partner structure
(explains why both patches are in the same
commit)
bzr revid: odo@openerp.com-20130415171732-aj3j2e2mycvzf4kp
super() finds the MRO parent of the provided class to resume the
execution chain from there, so the class being defined should be
provided.
Here view called super(osv.osv, self).create so if osv.osv (Model) had
a create() defined (which luckily it does not) it would've been
skipped.
bzr revid: xmo@openerp.com-20130415105744-cfx47t01oc7loyes
project: privacy_visibility now has basically 'public', 'employees' and 'followers' possible values.
portal_project: add 'portal' to the privacy_visibility values
- public: everybody see the project and all tasks
- portal: employees see the project and all tasks; portal users see the project and the followed or assigned tasks
- employees: employees see the project and all tasks
- followers: employees see the project if follower and the follower or assigned tasks
portal_project, portal_project_issue: added tests for access rights
bzr revid: tde@openerp.com-20130415083130-buklyo8kdpzrbzb7
html fields are sanitized just before saving data into the database.
In the composer, this cause the sanitization of the templated
message (for mass mailing messages) before the rendering, forbidding
the use of templated html links.
The html of the message is sanitized by message_post()
bzr revid: chs@openerp.com-20130411182226-lwnpkh4tmyswjjnc
The existing tests were modified to explicitly cover
the case where the "invoice partner" is set on the
Sales Order. This minimal change was done with a
!python block because !record triggers the on_change
calls on the SO and cause undesired changes.
This could be improved by creating a new customer
with a real invoicing contact and creating a new
SO.
bzr revid: odo@openerp.com-20130411145636-emmagu7uu5kis1aa
refers to a default_section_id field that is added in sale_crm bridge module.
New behavior is : one of the team user_id is a member (crm), or
default_section_id if defined or default behavior (sale_crm)
bzr revid: tde@openerp.com-20130411123356-kc8ty16i71nwgzsm
The way attachments are linked to the document has been cleaned. Posting method message_post may receives 2 arguments:
- attachment_ids: those linked to the wizard model (mail.compose.message) are linked to the document (res_model, res_id)
- attachments: the tuples are used to create new attachments linked to the document
The wizard does not set the res_model and res_id of attachments anymore, delegating this job to message_post.
The mail.message and mail.compose.message now use their respective attachment_ids field when possible. This is done instead of reading/creating new attachments based on the attachments tuple each time a mail.compose.message is processed. Email templates now also use attachment_ids, in particular when generating emails, instead of using the attachments tuple. Only reports are still generated on the fly and put into attachments instead of attachment_ids.
A cron job has been added to unlink 'lost' attachments. Those are attachments:
- linked to 'mail.compose.message'
- with res_id=0 (due Chatter used in minimal mode or reports generated by templates before the wizard has an ID)
- with no activity for more than one day (create_date and write_date)
bzr revid: tde@openerp.com-20130411112033-mqph9vjlcjkoolfs
Launchpad Translations on behalf of openerp