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
The `use_parent_address` flag is meant for advanced use
in companies that want to make sure their contact/company
addresses are always in sync, at the possible cost of some
usability loss when editing existing addresses (need to
open the company form view, contact fields are read-only).
The embedded mini-form view of the contacts also need to
be inherited to make it match the main view.
bzr revid: odo@openerp.com-20130410170437-2v4ehptknk6yf1x2
We should never turn the `use_parent_address` option on
unless the user explicitly wants to use it. It makes
further editing more convoluted (need to go to the
company address) and is really an advanced feature.
It was only set by via context defaults when adding
contacts to a company ; we can replace that with a
set of defaults that will copy the company address
fields to the contact. Users can still switch to
automatic synchronization if they really want it,
or simply further edit the address of the contact.
Also fixed the layout of the mini-form view, now
using a simpler vertical layout with address at
bottom, since the main info of a contact needs
to be entered first.
bzr revid: odo@openerp.com-20130410170101-t9covdj6nmyn44jf
Being able to choose a contact to invoice is very important
because the invoice must go to the right person.
When the invoice creation is automated by e.g. a Sales Order
any partner can be used (even though the system will
preselect the `invoicing` partner of the company if
one exists).
We have to keep that freedom when manually creating invoices.
bzr revid: odo@openerp.com-20130410135308-pd54c7ml8t3pcefl
It is valid to use the parent address but still set a different
type of address - the name, email, phone, etc. could be different.
bzr revid: odo@openerp.com-20130410123229-9l60sbcks3tpmy7x
Using the commercial entity is not a very good default choice
in many cases. If a new contact is created on-the-fly for a
new document (e.g. sales order), his/her company may be an
empty shell and/or a large corporation that should not be
directly used for e.g. billing/invoicing purposed.
Once a contact/company is set to "invoicing" or "delivery"
we use it, but in other cases we stick to the provided
partner/contact as a saner default.
This should not change anything for cases where advanced
contact management is used and proper address types are
set.
bzr revid: odo@openerp.com-20130410121536-vm93o6vxhi3b8feu
Quentin (OpenERP)
Thibault Delavallée
Launchpad Translations on behalf of openerp
Stephane Wirtel
Cedric Snauwaert
Christophe Simonis
Antony Lesuisse
Olivier Dony
Fabien Meghazi
Josse Colpaert
Frédéric van der Essen