The following tasks have been started or completed during the sprint: CPSSkins / CPS3 integration; ERP5 and CPS Integration; ZSQLCatalog for CPS; Presence (Jabber/CPS integration); Single Sign-On (SSO) using CAS; Plone2 exporter plugin for CPSIO

The followings tasks have been started during the Zope/CPS/ERP5 sprint in Paris on 25-27 August 2004:

• CPSSkins / CPS3 integration
• ERP5 and CPS Integration
• ZSQLCatalog for CPS
• Presence (Jabber/CPS integration)
• Single Sign-On (SSO) using CAS
• Plone2 exporter plugin for CPSIO

CPSSkins / CPS3 integration work during the Nuxeo CPS / ERP5 sprint

Jean-Marc Orliaget <[email protected]>, Chalmers University Julien Anguenot <[email protected]>, Nuxeo

Goal

Completely integrate CPSSkins within CPS3.

Summary of what has been achieved during the sprint

On CPS3 side: a new component, CPSPortlets - a brand new portlet engine for CPS3 - has been designed which will:

• unify the overall CPS3 architecture by using CPSSchemas to represent boxes

• be fully integrated with CPSSkins

• separate two concepts:

  • Portlet content (CPSPortlets)

  • Style / portlet decoration / canvas positioning (CPSSkins)

CPSSkins will:

• Manage and display global CPS3 portlets.
• Manage and display local CPS3 portlets (same concept as the local CPS3 boxes)

CPSSkins will become a mandatory component of CPS3.

Benefits from the new design

• CPS3 portlets will be managed through the powerful and intuitive CPSSkins interface.

• Performance will be greatly enhanced by using the CPSSkins caching system on CPS3 portlets.

• Unification of concepts, ease of use:

  • Fewer concepts will have to be understood by a CPS3 user. A CPS Portlet is like a CPS Document and works in the same way (FlexibleTypeInformation / schemas / layouts / widgets.) Reusing document widgets / portlet widgets is possible.

  • No more fixed slots in the layout canvas as in CPS3's main_template.pt.

  • No more complex macro libs to represent boxes.

• Portability: CPSPortlets will only depend on CPSSchemas and it will be easy to port it to other platforms (e.g. CMF/Plone).

Status

The overall design has been completed and a prototype for the two components has been implemented during the Sprint.

CPSPortlets :

• http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSPortlets/

CPSSkins :

• http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSSkins/

Some more work needs to be done to finish the architecture and the interaction between CPSPortlets / CPSSkins as for instance the migration of the current CPSDefault box system (cf. CPSDefault cpsskins-cpsportlets-branch-dev branch)

The results of this work will be available in the 3.3.x CPS3 releases.

ERP5 and CPS Integration

by Tarek Ziadé (Nuxeo) and Sébastien Robin (Nexedi)

Overview

The ERP5CPS products was created in the beginning to make sure the synchronization product (ERP5SyncML) is nicely working with CPS. During the sprint, we have updated a lot the ERP5CPS product so that the integration between ERP5 and CPS is going further.

We wanted to do whatever is needed to make sure both ERP5 and CPS can run on the same site. This allows to very easily jump from CPS to ERP5. You just need to login one time, then you can access the power of CPS and ERP5.

What we did

• We have created a new kind of site: the ERP5CPS Site. We had to create the corresponding installer. It installs all ERP5 and CPS components and tools.
• We have created a new box in order to display the ERP5 toolbar on the top of the default CPS default view.
• We have worked on skins and css. There were several conflicts between ERP5 css and CPS css because we needed both styles within the same page.

Results

• Once you have all products needed by ERP5 and CPS, you can also install the ERP5CPS Products. Then you should be able to add a new 'ERP5CPS Site'.
• Everything is done by the installer, you will have the default view of cps with the tool bar of ERP5. You can add some business templates and then you can jump easily between ERP5 Modules and CPS documents.
• Code is in the Nexedi CVS: http://cvs.erp5.org/cgi-bin/viewcvs.cgi/ERP5CPS/

What we should do in the future

• Make sure the ZSQLCatalog works fine when both ERP5 and CPS are working at the same time.
• Make sure the translation is working fine for ERP5 and CPS
• Maybe solve encoding conflicts. In ERP5 everything is stored as 'utf-8', but that's not the case in CPS.

ZSQLCatalog for CPS

Jean-Paul (Nexedi) and Damien (Nuxeo)

The goal of this sprint item was to replace the standard CMF catalog tool used in CPS by ERP5's SQL catalog in order to:

1. allow tighter integration between CPS and ERP5

2. provide an open and high performance alternative to Zope Catalog

3. remove a central point of conflict in CMF architecture

Another goal of the sprint was to simplify installation of ZSQLCatalog.

ZSQLCatalog has been used for 18 months by Nexedi as a replacement to Zope Catalog in order to provide SQL based high performance queries in Zope. For example, calculating the average of 100.000 invoices is an instant operation with ZSQLCatalog. Displaying 100 worklists out of 1.000.000 documents can be obtained without performance penalty. The purpose of ZSQLCatalog can be considered somehow as adding an OLAP engine to ZODB.

ERP5Catalog relates to ZSQLCatalog in the same way as CMF CatalogTool related to ZCatalog. It was therefore a good start base for the sprint.

In the first phase of the sprint, we removed the standard portal_catalog tool from CPS and copied into an ERP5 catalog. Then we tried to answer the question: what should be changed to ERP5Catalog setting to meet CPS requirements.

We ended up doing the following

• add a new table named "cps" containing all indices specific to CPS

• add support of topic indices to ZSQLCatalog

• finish complete support of range queries in ZSQLCatalog

This allowed us to achieve the result of running a standard CPS site, doing searches in sections, keywords or full text by transparently querying an SQL database through ERP5Catalog. No change was required to CPS code base. Although it is based on Z SQL methods, ZSQLCatalog can mimic completely the behaviour of Zope catalog.

All setting were then changed into an external method which allows to recreate preset ERPCatalog instances in a matter of minutes.

Changes have been committed already to the CVS. We are now proceeding to unit testing.

During the sprint, we used MySQL database for all tests. However, other databases can be used to obtain similar results. The only requirement is to rewrite a few SQL methods to adapt each database vendor specific features, for example in the area of full text indices. We hope contributors will help us extend ZSQLCatalog to other databases. For example, it would be interesting to evaluate the various offers in terms of full text searching provided by mainstrean databases.

Screenshots

• ERP5 Catalog includes many Z SQL Methods which interface a Zope CMF system to an SQL database engine in order to provide ZODB access through SQL based queries ./cps-sql-catalog.png

• ERP5 Catalog lists ZODB object which can be queried by using standard SQL ./cps-sql-catalog1.png

• The CPS table includes columns for each CPS specific index ./cps-sql-catalog2.png

• The Catalog table includes columns for CMF standard index ./cps-sql-catalog3.png

Presence work

Thierry Delprat

Overview

The "Presence" product is a first step to integrate presence awareness into CPS.

This product is using Jabber to get user status.

The following statuses are defined:

• Jabber status if connected
• disconnected
• not declared as Jabber user

Presence includes the following components:

• A python module (ZJabAwareness) that provides an interface to easily

  get the presence and send notification. (based on a xmpp generic jabber python library)

• A Tool called portal_presence that provides

  • a basic API

    • Get presence information for a given CPS User
    • Send a Jabber notification to one or more CPS Users

  • Jabber server's admin accounts configuration

  • a configurable cache for presence info

  • configuration of JabberID/CPS Directory mapping

• A Widget that display user's presence status (Can be added to Common schema to display Author's presence status)

• A Box displaying presence information for the active members of a workspace

Future developments will/should include:

• Notifications via Jabber using the portal_presence API
• Better Directory integration (JUD/CPSDirectory ?)
• Better GUI
• Integration of a skinned Jabber applet
• Integration of CPS Groups with Jabber rooster
• Unit Tests !

Installation and configuration:

• Get the Presence product from the CVS: http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/Presence/

• Through the ZMI, add an instance of portal_presence tool in a CPS Site

• Go to the tab "Jabber Servers Admin Users" in portal_presence

• Add one or more jabber connectivity information.

• To add a server, the following information are required

  • Granted User JID with associated password
  • The port of the jabber server

• configure it with one or more jabber server information. (dns name, admin login and admin password) admin is a normal jabber user with granted role declared on jabber server configuration in "<admin>" tag.

• Choose the name of field JID and JabberPassword for CPS schema and layout in the "User Jabber Attributes" tabs.

• Add to the schema and to the layout of CPS members the fields JID and JabberPassword as you defined on "User Jabber Attributes" tabs.

• Add to the portal_memberdata (which is still for storage for member data) the fields JID and Jabber Password. To check if it works verify if data is still here when you reload your member data from CPS GUI.

• Add the Jabber Widget to the common layout

• Add jpresence box to the site, to do this you can use an External Method with Module Name:"Presence.install" and Function name="install".

SSO work during the Sprint

Lennart Regebro

Me and and three people from Capgemini (Manu, Cedric and JérÎme) looked at single sign-on (SSO) solutions. We looked at three of them:

1. SSL Certificates

   Not really interesting, since it requires PCGI and complicated certificate management.

2. PubCookie

   Turned out to be Apache only, so it also requires PCGI, and if you use PCGI it is already supported through the REMOTE_USER variable.

3. Central Authentication Service (CAS) from Yale university

   This is a well designed, open and platform independent SSO solution that looked easy to implement, so we went ahead with that.

After som troubles to get the CAS server running (it is a Java servlet, that runs under Tomcat) we started working on some different solutions.

The first and most generic one was based on code that we got from Thierry Delprat at Unilog. He had made a version of CookieCrumbler that supported several different authentication setups, including CAS. This code was streamlined to only support CAS. Because CookieCrumbler in itself is a bit of an ugly hack, and this extends on it, several tricky problems appeared in some more obscure cases. With some help from others (most notably Florent) these were finally solved at the end of day three, and the product CPSCasSso was checked in:

-> http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/CPSCasSso

The CookieCrumbler variant will work with most userfolders, but it may not work with those overriding the identify() or authenticate() methods of BasicUserFolder. PluggableUserFolder is one of those, so to get a "reference" implementation so we knew it would work, I did a quick CASPlugin for PUF early on day 2. During day 3 I cleaned this up to a stable and working code (it needed some additions on PUF itself), and then went on to try to make a plugin for Zopes new PluggableAuthService.

-> http://cvs.nuxeo.org/cgi-bin/viewcvs.cgi/CPS3/PluggableUserFolder/CASIdentification.py

PluggableAuthService (http://cvs.zope.org/Products/PluggableAuthService/) works on the same principles as PluggableUserFolder, but splits the plugin interface into many more different plugins. This has various benefits, and I did notice under the later stages of PUF development that a split of plugins would be a good thing. However, PAS is not really finished yet. Version 1.0.2 does not support login-page redirection, it does not support "passwordless" logins (Zope never sees the password), and is pretty buggy. The effort was therefore abandoned during day 3.

However, all my questions about PAS to the zope-dev mailing list had the effect that some Zope users asked me for help now on monday. So, I have spent monday afternoon in fixing these problems, and finishing the plugin. The main developer of PAS, Zachery Bir, seems less than happy to allow useful support of "passwordless" authentication-mechanisms such as CAS, so this may take some effort in convincing him, but other than that it now works.

Plone 2 plug-in for CPSIO

By: Emmanuel Pietriga and Anahide Tchertchian

Summary: making CPSIO work in non-CPS Zope environments (such as a Plone site)

and implementing a plug-in for CPSIO in charge of exporting Plone 2 data using the already defined CPS 3 XML vocabulary, which can then be imported in a CPS3 site using the existing CPS3importer plug-in.

What has been done

• Plone2Exporter exports CMF/Plone workflows, CMF/Plone portal types and CMF/Plone hierarchies present on a site (folders, plone folders, large plone folders), offering different mappings on CPS hierarchies (duplication in workspaces/sections, or only one of those)

• Exporters now generate ZIP archives instead of multiple files in var/

• CPSIO no longer requires Localizer to work properly

• CPSIO generates a log summary presented to the user after termination of the process

What remains to be done

• Exporting content

• Exporting members

• Exporting archetype definitions and archetype content:

  After getting more familiar with archetypes, we realized this is not straightforward as Plone archetypes are positioned at a much lower level of abstraction than CPS's schema/layout mechanism.

  NB: the ArchGenXML product provides the possibility to produce archetype

  using UML, but the generated code cannot be exported back.

  
  

  Archetype definitions rely on python code. For instance, a match for field, widget types and permissions could be found in CPS for "standard" usage, but specific implementations would be a problem.

  Two approaches can be considered, the first one is type-oriented, while the second one is document-oriented:

  1. What can be exported is exported, what cannot be exported is not. The best way to do it would be to warn the user when a type is not exported, so that he is aware of what is lost, including the amount of data relying on this type and/or the possibility to implement this new type in CPS.

  2. Whatever the archetype used to represent a document, the document has to be exported so that no data is lost. The type (schemas/widgets/layouts) used to represent this document in CPS would be "basic", and the user would have to customize this type to get the features provided by the original archetype.