openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 10/25/2011 05:17 PM, Alan Lord (Gmail) wrote:
> We have a customer that - not unrealistically IMHO - wants his sales 
> staff to be able to see a list of their todos (activities) all in one place.
> 
> The way I see it in OpenERP you have phone calls and meetings in the 
> CRM, tasks in the Project Manager but they are not visible in one place 
> and Project Tasks are not really the same as my daily todo list...

Short answer:
You can't do that at the moment, but you can use workarounds, like
making a dashboard with the calendar views of all relevant documents, or
using your preferred calendar application (e.g. outlook) to aggregate
multiple calendar feeds coming from OpenERP.

Long answer:
OpenERP does not have a concept of a generic "multi-object" calendar
yet. There are many reasons for that, such as the fact that OpenERP
calendars are designed as just another view, another way to represent a
certain list of documents. In the same way that you can't have mixed
lists of Sale Orders and CRM Meetings, you can't easily have a calendar
that mixes them.

This limitation is well-know and we are looking for an elegant way to
improve the situation. However, even if we provide this in a future
version, OpenERP may likely still not offer the features of full
calendar application, like Outlook. Such applications are highly
specialized, while OpenERP aims at being as generic as possible.

Some possible workarounds:
1. Import the multiple calendar feeds from OpenERP into your specialized
calendar application (via .ics export or CalDAV as of 6.0), and use the
aggregated calendar there.
2. Make a custom dashboard view that includes multiple calendar views
for all the relevant documents you are interested in. At least you'll
have them in one screen.
3. [quite technical] Implement a custom OpenERP object that acts as a
"proxy" and aggregates the documents from multiple models into a single
model. There are many challenges to solve here: this proxy should
normally have a single "form" view that can't fit the various underlying
documents, etc. This has been reported to work in limited cases (I don't
have any pointer to a working implementation).