Personal tools

Federica D'Elia

Apr 13, 2010

GDIP: Integration of Google Docs services in Plone

Filed Under:

Packages for integration of Google Docs services in Plone were released on pypi and on plone.org

The purpose of GDIP is to provide the Google Docs services to Plone users.

Advantages:

  • Plone users can save their files on Google servers, instead of in the ZODB;

  • Plone users have multiple access points to your files: they can manage their documents using two systems: Plone and Google Docs;

  • Plone users can edit their documents directly from the Google Docs application, embedding that page in the current window of the Plone application;

The products collective.googleauthentication, collective.googlesystemstorage, collective.googlesharing and collective.googlemodifycontent provide the integration of Google Docs services in Plone.

Packages were released on pypi:

http://pypi.python.org/pypi/collective.googleauthentication

http://pypi.python.org/pypi/collective.googlesystemstorage

http://pypi.python.org/pypi/collective.googlesharing

http://pypi.python.org/pypi/collective.googlemodifycontent

and on plone.org:

http://plone.org/products/collective.googleauthentication

http://plone.org/products/collective.googlesystemstorage

http://plone.org/products/collective.googlesharing

http://plone.org/products/collective.googlemodifycontent

 

The system integrates Google Docs services in Plone using the gdata-python library provided by Google, which in turn uses the Google API.


GOOGLE AUTHENTICATION collective.googleauthentication

To let the Plone application access the documents stored on Google servers, it is necessary to complete the authentication procedure for Web applications provided by Google Docs. The procedure allows Web applications to authenticate users through their Google accounts. For security reasons, the application acquires an authentication token which will later be used to dowload or upload documents from Google servers without explicitly providing the user's credentials. The Plone user is redirected to a Google page that invites him to insert his credentials. Once he logs in with his Google account, the user is asked to authorize the Plone application to access his documents. Then, if the user grants access, he is pointed again to the Plone site. The URL of the last redirection embeds the authentication token which, as mentioned above, allows the Plone application to access the user's documents on Google servers for the following requests. GA inititates the authentication procedure upon Google Docs immediately after the user has logged into the Plone application. The procedure will be executed just once, as when the Plone application obtains the authentication token, it will store as an attribute, google_token, in the user profile.


GOOGLE SYSTEM STORAGE collective.googlesystemstorage

GSS saves the document types supported by the Google Docs service on the Google servers, while storing all the other files in the local filesystem, so that Plone users to access their files from both the Plone application and their Google Docs account. GSS extends FSS through a meta ZCML directive will trigger the adoption of GSS as storage. GSS provides several utility methods: a method that takes an authentication token and returns a client for Google Docs, methods that take care of uploading, downloading and deleting the documents on Google servers, and a method that performs queries on documents stored on Google servers.


GOOGLE SHARING collective.googlesharing

GS manages the sharing of documents stored in the Google servers and their synchronization from the Plone application to Google Docs service. In this way, when a Plone user changes the roles of other users on a specific document, GS changes the document sharing attributes in the Google Docs service accordingly. So, if a Plone user assigns another user the Editor role on one of his documents, the other user will be able to read and modify that document through his Google account. To associate Plone and Google accounts, the system assumes that the email address attribute of Plone users corresponds to their Google account. The sharing attributes of documents stored in Google servers is managed through the feed access control list (ACL), a list that shows the Google users that have access to a specific resource. GS redefines the googlesharing view to perform the mapping of roles and the ACL feed retrieval and changing operations.


GOOGLE MODIFY CONTENT collective.googlemodifycontent

GMC extends the Plone content Edit function by adding the GoogleModify operation, which only applies to documents stored on Google servers. GMC embeds the Google Docs application inside the GoogleModify panel, allowing Plone users to edit their documents directly from the Google Docs application. GMC provides the new googlemodifycontent view, that takes care of discovering the specific URL of the Google Docs document function and of embedding that page in the current window of the Plone application.

 

One idea for improving the system is using the workflow, instead of directly manipulating roles and permissions associated with content.

Mar 01, 2010

Integration of PloneGazette with plone.app.discussion

Filed Under:

The new product collective.discussionintegration.plonegazette provides the integration of PloneGazette and plone.app.discussion.

The product plone.app.discussion is becoming the standard way to add comments in Plone. If both products plone.app.discussion and Products.PloneGazette are installed the creation of any PloneGazette content type fails, because PloneGazette content types not provide the adapter for "IConversation":

Traceback (innermost last):
  ...
  Module plone.app.discussion.catalog, line 29, in total_comments
TypeError: ('Could not adapt', <NewsletterTheme at /ausl/newslettertheme.2010-01-26.2440135204>, <InterfaceClass plone.app.discussion.interfaces.IConversation>)

 

 

To solve the problem we set an adapter for the types defined in Products.PloneGazette. This adapter provides the interface "IConversation" of plone.app.discussion. The adapter provides the attribute "total_comments" and the method "enabled", which returns False (means that the commeting is disable).

<adapter
      for="Products.PloneGazette.interfaces.INewsletterTheme"
      factory=".newsletter.NewsletterConversation"
      provides="plone.app.discussion.interfaces.IConversation"
      />

 

So you can create objects Newsletter without any problem.

Unfortunately PloneGazette does not define an interface for each content types, so through zcml we say that these content type implements a particular interfaces.Then we give the adapter for those interfaces.


The new product collective.discussionintegration.plonegazette makes possible the creation of the PloneGazette content types if there is an installation of plone.app.discussion in your instance.

http://svn.plone.org/svn/collective/collective.discussionintegration.plonegazette/

 

 

Oct 14, 2009

New version of redturtle.video

Filed Under:

Released version 0.2.0beta of redturtle.video

A new version of redturtle.video was released on pypi:

http://pypi.python.org/pypi/redturtle.video/0.2.0beta

The package redturtle.video is a video support for Plone, based on collective.flowplayer.
In the new version of redturle.video two new fields are added to content types Video files and Video link. These new fields are "Year" and "Duration".

The information on the lenght of video is achieved through the use of packages: 'hachoir_core', 'hachoir_metadata' and 'hachoir_parser'.

The "Video Gallery" portlet shows content image fields taken from videos. In the new version "Video Gallery" portlet shows also the new informations on the year and duration of the video and also the title of the video.

Oct 06, 2009

Improve the compatibility of collective.plonetruegallery

Filed Under:

I created a branch of the product collective.plonetruegallery, extendible.gallery, which allows to use the features of the package for new types of content and not only for the type "Gallery".

I tried to use the functionality provided by the product collective.plonetruegallery, such as the view "gallery", for my content type, and I had a problem: these features are applicable only to the content type "Gallery". This is because in the code of the package conditions are evaluated on the value portal_type of the content type, eg. if(object.portal_type == 'Gallery').

So I changed some parts of the original product by ensuring that the controls are no longer performed on the value portal_type of the type of content, but on the interfaces implemented by the type of content. In this way the functionalities of collective.plonetruegallery can be applied to any type of content, different from "Gallery", if it implements the interface "IGallery", eg.: IGallery.providedBy (object).

I take advantage using my content type "Cartridge" that extends ATBTreeFolder, which functions as a folder can hold a large number of elements, rather than the type of content "Gallery" which is not a large folder, and then was not suitable for my purposes. But the point is that I could still use the view "gallery" of collective.plonetruegallery to view images from the cartridge, because my type of content implements the interface "IGallery".

I have proposed these changes to the developers of the product and now see if they are interested in applying this modern approach!