Developer Insights

iCal invitations with Plone

Posted in ical, Plone, Python, Zope by Ricardo Alves on May 31, 2009

I recently released the first beta of collective.eventinviter — sorry for the name, but couldn’t come up with a better one. It’s a simple add-on package that enables Plone to send an iCal invitation (email with an attached .ics file) to each event attendee. Something that may be desirable in collaboration/intranet environments.

The emails are sent based on the content of the attendees field. So it checks each value at the attendees field, and sends email messages if:

  • The value is the username of a registered user, and if that user has a valid email address.
  • The value is a valid email address.

Values that match none of the these conditions are simply ignored.

Although it is intended to work out-of-the-box for the most common use cases, it is also possible to adapt collective.eventinviter to other event content types, i.e. other than ATEvent. For example, if we have a custom content type ‘MyEvent’, to enable iCal invitations it just needs to implement the marker interface IInvitationAware:

from collective.eventinviter.interfaces import IInvitationAware
...
class MyEvent(...):
    ...
    implements(IInvitationAware)
...

If, for some reason, MyEvent holds information about attendees at different field(s), an adapter implementing IAttendeeEnumerator must retrieve such list of recipients properly, which should be pretty simple to implement:

from collective.eventinviter.interfaces import IInvitationAware
from collective.eventinviter.interfaces import IAttendeeEnumerator
...
class AttendeeEnumerator(object):
    implements(IAttendeeEnumerator)
    adapts(IMyEvent)

    def attendees(self):
        # return list of valid email recipients
        ...
...

Currently there are some changes that I would like to include, maybe after some discussion, before a final release:

  • Make it optional to invite attendees, using a global configuration (property) or a checkbox for each event edition.
  • Include more information at the email message sent. Currently, the message includes only the event title and an attached .ics file.
  • Should this feature be available as a content rule?

Feedback, suggestions and testing results would be very much appreciated.

Advertisements

New release cycle is good

Posted in Plone by Ricardo Alves on April 15, 2008

The new release cycle is, without a doubt, a big step forward for Plone. More regular and predictable releases will attract more attention for new features, and more visibility means new potential users. Making a major release last for a while, complemented with periodic upgrade releases, also contributes, ultimately, to a more robust code base.

Now we don’t have to wait for a year, or even more, for a new feature-rich release. There is, obviously, a lot to improve, but Plone-3.1, which includes a set of handy features like new portlets, dependency handling in GenericSetup and more, is already a clear evidence of the new release cycle success.

Tagged with: ,

Universities choices for content management

Posted in content management, education, Plone by Ricardo Alves on December 11, 2007

The University of California at Davis released the preliminary results of a survey on web CMS adoption by universities. It was released October 22, 2007, but it’s worth the reading. This survey may be of little significance, since the sample includes a total of 129 respondents, but, as Kas Thomas states in CMSWatch Trends, we can confirm the idea that “even the best minds in the world can’t agree on how to do content management”.

It’s also interesting to see that for universities using a web CMS, a large number uses a custom built solution. For the ones using solutions available on the market, Plone is the most adopted. The comments page also includes some interesting opinions about the issues raised in this particular context of content management.

Another important information is that a large majority of universities don’t consider mandatory the usage of the adopted web CMS. This means that each department, faculty or institute will make its own choices. But that’s the nature of universities, and maybe that’s the way it should be.