Notes on a new Products.FacultyStaffDirectory

FacultyStaffDirectory is old, Archetypes-based and somewhat cranky. There are some implementations already, we need to collect what's useful out of these and decide what to base a new add-on around.

Once there's a base / new add-on repo, this discussion could be moved to Github.

FacultyStaffDirectory is old, Archetypes-based and somewhat cranky. There are some implementations already,

Asko and Rikupekka know about one, see

Yes, we're currently using something called collective.roster in our university. Here's an example:

Here's some info on the product:

Can be extended using behaviors
Folderish, containing Person-objects
Editor can add groups (simply a list), and link persons to those groups
3 differen views: alphabetical, grouped, gallery
Can show/hide columns in the table view, can reorder table contents (z3c tables)
Running on production sites (4.1.6, 4.2.x and 4.3.3) for a year now, works fine


  • not released (will be)
  • no ldap-integration like in FSD
  • haven't used it on huge listings (with thousands of persons)

Also, here are alternatives to look at, already at pypi:

Some of the features of ibme.persondirectory:

  • Dexterity-based
  • Person schema is designed to be defined using TTW:
  • ~no predefined fields
  • Will display any fields that have been added TTW to the person schema
  • Any number of textual facets can be added, which are automatically indexed and then selectable at view time.
  • Designed to be themed with Diazo (and is missing some default CSS)
  • Currently optimal for smaller groups of people (could be solved):
  • Results shown in a list, not a table
  • No pagination on results
  • CSV import can be done via. transmogrify.dexterity support
  • No special support for users to edit their own entry, or links to the Plone member database.

@lentinj ibme.persondirectory sounds very nice.

Our (unreleased collective.roster, started already in 2012) is not as TTW-compatible. We have fixed base schema (with dexterity.membrane compatible field names, but no membrane forced membrane integration) and it has been designed to be extended with file-system code behaviors:

  • Optional fields are implemented as behaviors
  • Field display is implemented as viewlet for the behavior
  • Field displays as registered for Person-specific viewlet manager
  • Person-viewlets can be reordered, disabled and enabled globally with manage-viewlets -view
  • Behavior can also provide custom columns for the tables *)

On searching, we rely on collective.dexteritytextindexer.

*) For table, we use z3c.table, which is a bit over-engineered for a table, but makes it easy to have optional columns and has also paging support with plone.z3ctable.

I'll work hard to finish this sprint early, so that I could polish our add-on from our internal cruft, so that it would be easier to evaluate.

For this discussion, it would be figure out common requirements. Our main issue with FSD was its tight coupling with Membrane.

We have over 200 sites and probably over half of them use FSD, in various ways but with at most several hundred (max ~250 profiles). Some examples are at

We have some extensions for adding external collaborators and affiliating people to a department/collect/institution, and we have a default set of fields for the profile that can be extended with a further 10 or so extra fields (from the ZMI). If their credentials are added to their profile, users get edit access via our local web-auth based authentication rather than using ldap. It would be essential for us to have a migration strategy from the current add-on to the new one.

I can add more about likes and dislikes, and what users would like to see, but all in due time!

Might a good step would be to agree on what features should be in a new FSD equivalent, as a base?

There was some notes made in our open space on desired features, I'm not sure what happened to them. However, I think the main next decision is if one of collective.roster et al could be grown into a new FSD.

Cris Ewing was going to write up some notes, but they haven't appeared as yet. Will try and get something together by the end of the week but I have a couple of busy days before then.

Here are the transcribed notes.

Faculty Staff Directory Open Space

There was an open space discussion at the 2014 Bristol Plone Conference about Faculty Staff Directory. This is an old-style Archetypes add-on used by many universities, and we need a way forward for Plone 5. Here are the notes.


Cris Ewing
Helen Sagan
Jamie Lentin
Rikupekka Oksanen

Existing Work

A number of new add-ons have been developed that provide portions of FSD functionality.


ibme.persondirectory: Jamie Lentin, there is one at

collective.roster: Rikupekka and Asko, there is one at

collective.workspace, groups/memberships/rosters for

Products.FacultyStaffDirectory, the original, which is not in github but is on pypi

We discussed the need for a central location for information about this project, and decided to create a FSD discussion on


Open space participants brainstormed requirements. Here they are in no particular order.

    Research group
    Research subject
    Person type
Membership/rights - on/off switch
External data sync (which may go to a separate content type, like for a bibliography)
Less Fragility (renaming causes failures)
Front-end rendering
Settings for site admin to choose fields

1 Like

We finally released the source code for our product (collective.roster) after refactoring it from grokked Dexterity 1.x into Dexterity 2.x without grok (for Plone >= 4.3):

Cris Ewing is possibly working on c.roster membrane integration early this year.

1 Like

Related blog post from Jazkarta

But collective.roster is still missing a public release. That's because as long as our Uni is still mostly in Plone 4.1.x, we need to stay in c.roster 1.x, while the current unreleased master has been refactored to Plone 4.3 and greater (with Dexterity 2.x).

So, because there's no release at PyPI yet, please, stand up, take the maintenance of c.roster master (>= 2.0) and make a maintained release.