Showcasing Personnel with Faculty/Staff Directory using Plone 3

Erik Rose

December 2009

(For more resources on Plone, see here.)

Faculty/Staff Directory is practically a departmental web site in a box, but it doesn't stop there. The product is general enough to serve in non-academic settings as well. It is also not limited to people; it has been repurposed to such diverse applications as cataloguing tea leaves. It really is a general-purpose taxonomy engine—albeit with an academic bent in many of its naming choices.

This article is an exploration of a product that will likely provide the framework for much of your site. We'll tour its features, get ideas on how they're commonly used in a school setting, and, finally, get a sneak peek into the future of the product.

Install the product

Faculty/Staff Directory depends on several other products: membrane, Relations, and archetypes.schemaextender. Thus, the easiest way to get it, as documented in its readme, is by adding Products.FacultyStaffDirectory to your buildout.cfg, like so:

eggs =
...(other eggs)...

Then, shut down Zope, and run buildout.

After starting up Zope again, install FacultyStaffDirectory in the Add-on Products control panel, and you're ready to go.

Test drive Faculty/Staff Directory

Faculty/Staff Directory (FSD) is tremendously flexible; you can use it as a simple list of phone numbers or as the foundation supporting the rest of your site. In this section, we take FSD for a spin, with ample pit stops along the way to discuss alternative design possibilities. Keep in mind that FSD's features are given to creative repurposing. We'll not only see their typical uses but some more inventive ones as well.

Create a directory and choose global roles

Faculty/Staff Directory centers around the idea of collecting people in a central folder called, fittingly, a faculty/staff directory. Our first step is to create that folder. Once you've installed FSD in the Add-on Products control panel, choose a place in your site where you would like to place a personnel directory, and add a faculty/staff directory there.

Plone 3 for Education

You'll be prompted for two things: Title (which is usually something like People) and a selection of Roles.

Plone 3 for Education

These roles, part of FSD's optional user-and-group integration, are granted site-wide to all people in the directory. Thus, as with the similarly scoped roles in the Users and Groups control panel, it's best to use them sparingly: choose only Member or, if you don't intend the people represented in your Directory to log in, no roles at all. Most roles should be assigned on a per-folder basis using the Sharing tab, and FSD provides facilities for that as well, as we discuss later in the Integrate users and groups section.

Add people

Now that you have a place to keep them, it's time to add actual personnel. FSD represents people through the aptly named Person type. A fully tricked-out person might look like this:

Plone 3 for Education

People, without exception, live directly inside the faculty/staff directory—though they often appear to be elsewhere, as we will soon see. Each person can track the following information:

Basic Information


Access Account ID

Doubling as the object ID (or "short name") of the person, this field should contain the person's institution-wide login name. If you choose to take advantage of FSD's user-and-group integration, this is how logged-in users are matched with their Person objects.

The name of this field and its validation requirements can be changed (and should be, in most deployments) in the Faculty/Staff Directory control panel under Site Setup.


First, middle, and last names, as well as a suffix such as Ph. D or Jr.


A picture of the person in GIF, JPEG, or PNG format, for use on their page and in some listings. It will be automatically scaled as necessary.


Classifications are FSD's most prominent way to group people. This is a convenient place to assign one or more when creating a person.


Another way of grouping people. See Group People, below, for an in-depth comparison of all the various types of groupings.


If the Person objects provide user passwords option in the FSD control panel is on, one can log into the Plone site using the Access Account ID as a username and the contents of this field as a password.

Personal Assistant(s)

Other people who should have access to edit this person's information (excluding password and the fields under User Settings).

Contact Information



This email address is run through Plone's spam armoring, as yet not widely cracked, before being displayed to visitors. An alternative armoring method ("somebody AT here DOT edu") is available from the FSD control panel under Site Setup.

Street Address



Postal Code


The required format of the Office Phone field, along with its example text, can be set in the FSD control panel-a must for installations outside the United States and Canada.

Professional Information


Job Titles

As many job titles as you care to provide, one per line. These are all listed on the person's page.


A rich text field for the person's biographical information. Since this field can contain all the formatting you can muster-headings, images, and all-it is a wonderful thing to abuse. Fill it with lists of published journal articles, current projects, and anything else appropriate to show on the person's page.


A plain text field where every line represents a conferred degree, certification, or such.

Web Sites

A list of URLs, one per line, to display on the person's page. There is no option to provide link text for these URLs, so you may wish to embed links in the Biography field instead.



The committees and specialties to which this person belongs. See the full discussion of FSD's various methods of grouping people under Group People, below.

User Settings



Content Editor

If you leave FSD's user-and-group integration enabled for the Person type, these duplications of the standard Plone options will apply. Integration can be disabled on a type-by-type basis in the FSD control panel under Site Setup.

That's a lot of information, but you can fill out only what you'll use. Fields left blank will be omitted from directory pages, labels and all. For more thorough customization, you can write a Faculty/Staff Directory extender product to hide inapplicable fields from your content providers or to collect information that FSD doesn't ordinarily track.

Here's how to add people to the directory:

  1. From within the directory, pull down the Add new… menu, and choose Person.
  2. Fill out some of the person's attributes. Be sure to assign at least one classification to each person, but don't worry about departments, specialties, or committees yet, as we're about to cover them in detail.

(For more resources on Plone, see here.)

Group people

Most of FSD is geared toward categorizing and correlating people. It provides several different grouping types toward this, each with its own abilities and limitations. When you create a new directory, a few groupings are included as examples:

  1. Three classifications: Faculty, Staff, and Graduate Students.
  2. A committees folder. This special type of folder holds committees, which in turn represent collaborative groups.
  3. A specialties folder. This special type of folder holds specialties, also known as "research interests", with which people can be associated.

A fourth grouping type, not created by default, is the department. Like the other types, departments can be added using the Add new... menu.

The default groupings can be used as-is or, as is more often done, deleted and replaced with more organization-specific ones. The top-level folders can also be renamed. It is common, for instance, to rename the Committees folder as Workgroups and the Specialties folder as Research Interests. (The latter is a particularly good idea, as it increases consistency with the labeling elsewhere in the product.)

People can be assigned to groupings from either of two ends: by editing the grouping itself or by editing the person. (The following screenshots have some options omitted for size.)

Plone 3 for Education

Of people and plants: more general taxonomies with FSD
If your organization doesn't divide neatly into committees, departments, specialties, and classifications, don't panic—you are by no means locked into those categories. While the grouping types have conventional names to make it easy for the majority of academic users to get started, FSD has been stretched as far as to be a catalog of plants rather than people. For example, imagine the Specialties folder renamed to "Taxonomy" and filled with phyla, genera, and species rather than research interests. Add some creative repurposing of fields on the Person type, and you have a serviceable little botany database. You can even write an extender product to relabel the fields.

All the grouping types collect people, but each has its own additional strengths and weaknesses. Let's examine each in turn and explore some suitable applications.


Classifications are the most prominent way of grouping people; all but one of the built-in views have headings for each classification, with lists of people underneath:

Plone 3 for Education

In fact, people lacking a classification won't even show up in these views—a common point of confusion—so be sure to assign at least one to each person.


Committees' special talent has to do with FSD's user-and-group integration: members of each committee implicitly gain the ability to add and edit items—pages, folders, and so on—within the committee object itself, which acts like a folder. This makes it easy to provide collaboration workspaces without having to teach people how to use the (often confusing) Sharing tab.


Specialties have two special tricks:

  1. They can nest inside one another to make a hierarchy.
  2. When a person is associated with a specialty, a "research topic" can also be provided, describing their specific interest.

Plone 3 for Education


Departments have a similar trick to that of specialties: their associations can be labeled. For example, a person associated with a department can be dubbed the Department Head:

Plone 3 for Education

Departments can also exist outside the faculty/staff directory: a big win for many site organizational schemes. What's more, a department can contain committee folders, making it easy to represent, for example, the Budget Committees of different departments.

Avoid the unexpected: stick with one directory.
Though it does little to enforce it, Faculty/Staff Directory encourages the use of only a single directory object per Plone site. This heads off several common pitfalls. For instance, consider a scenario where colleges within a large university are subdivided into departments. If you were to make a separate directory for each college, imagine the trouble when, inevitably, you needed a committee to represent a cross-college collaboration. In which directory would you put it? What about the members of this committee—would you keep two separate copies of them, one in their home college and another in the college housing the collaboration? Real-world scenarios like this abound, and using a single directory up front saves many hard decisions later.
There's also a technical reason to avoid multiple directories. Departments can be placed outside any directory, but, if they are, there is no way to associate them with any particular one. In practice, they will pick one more or less arbitrarily, and they may not always make the choice you expect. Future releases of Faculty/Staff Directory will add proper support for multiple directories for those cases where lists of people really are disjunct, and they will rethink how to represent lists of people outside the directory. See the section Coming attractions below for more.

How grouping works: relationships, not containers

Plone's underlying data storage, the ZODB, is a monohierarchy: that is, if Page A is in Folder B, then it cannot also be in Folder C. This presents a challenge for representing membership in FSD groupings by containment. So, while the groupings look and behave like folders in many ways, they do not actually contain people. Instead, membership is modeled using relationships, care of the Relations product. Relations keeps a record that "Peggy Smith is related to the Budget Committee and the Security Committee", circumventing the one-container limit. Meanwhile, Peggy herself lives in the top level of the faculty/staff directory, along with everyone else. In database lingo, Relations helps FSD act as a miniature relational database—sidestepping ZODB's strict hierarchy.

You, of course, can model your organization's groups without worrying about any of this—except for the following few places where the underpinnings poke through into the user interface:

  • If you have the Manager role, you will occasionally see a Relations tab while editing within the directory. This is part of Relations' built-in machinery, and you could theoretically use it to manually alter relationships. However, you are more likely to damage internal data structures, so it's best to avoid this and stick to the nicer ways FSD provides. Ordinary users will never see the Relations tab, so only site administrators need to watch their steps.
  • Since groupings are only related to people, no one will show up on their Contents tabs. Similarly, it's not possible to add a person to a grouping using the Add new… menu, though a future FSD release will include a workaround for the sake of convenience.


FSD provides four views that can be applied to groupings or to the directory itself.

Gallery view

The gallery view shows each person's portrait along with their contact information. Like most of the views, the gallery view groups people under headings representing their classifications, for example Faculty, Staff, or Graduate Students. In practice, gallery view works best for smaller groupings, since its many images make for slow-loading pages. All images are scaled, proportionally, to a single width controllable through the EditDisplay tab on the directory.

Plone 3 for Education

Tabular view

Tabular view is a more selective view, listing only name, phone number, and email—great for larger groupings. Like gallery view, it divides people according to their classification.

Plone 3 for Education

A-Z view

A-Z looks a lot like tabular view on the surface, but it is strictly alphabetical, not splitting people by classification. Its main means of navigation is a linked alphabet at the top of the page, where each letter jumps to the corresponding position in the list. The A-Z view is the best choice when users often need to search by name, without necessarily knowing a person's job function.

Plone 3 for Education

Textual view

Available exclusively on departments, the textual view provides only links to each classification, deferring any listing of people until the user burrows deeper. This is often appropriate for entities of department size, where a full listing of personnel would be unwieldy.

Which views for which types?

Most of the grouping types support only a subset of the four views. As of FSD 2.1.3, they are...




















Integrate users and groups

One of FSD's most powerful features is the optional integration of its types with Plone's built-in access control facilities. Both people and grouping types are imbued with this user-and-group magic, a huge timesaver to schools that don't already represent these groups in a shared system like LDAP or Active Directory.

Integration begins with the Person type. Any person you create in FSD can act as a normal Plone user: the login name is the person's Access Account ID, and the password is the one specified on the person's Edit tab. As with a normal user, FSD people can have local roles assigned via the Sharing tab or be put into normal Plone groups. In addition, logged-in FSD people automatically get the Owner role on their own Person objects, which lets them edit their own biographies and such without having to be manually assigned privileges.

Groupings comprise the other half of the integration story. FSD's groupings act just like normal Plone groups: committees, departments, classifications, and even the directory itself can be searched for and assigned roles on the Sharing tab. Give the members of a department access to a departmental intranet, or set up a collaboration area for faculty only—it's all possible without having to tell Plone a second time who belongs in those groups.

Interoperating with enterprise authentication

In the case of fancier setups, with another plugin like PloneLDAP or WebServerAuth handling authentication, FSD needs to be dissuaded from trying to authenticate people using the FSD-managed password: just uncheck the Person objects provide user passwords box in the FSD control panel. However, you can still get the advantages of user-and-group integration for Sharing tab purposes: after a person authenticates through whatever mechanism you've set up, FSD tries to match up the login name with a person's Access Account ID. If a match is found, the loggedin user gets the privileges due the FSD person. (Note that, while logged-in persons are able to edit most of their personal information, they are not allowed to add themselves to groupings like committees, since they would effectively be putting themselves into access-control groups.)

Delegating group administration

Typically in Plone, one needs the Manager role in order to manage groups. This can create a drain on the site administrator's time, since he or she has to be bothered for every addition to or deletion from a group. To help solve this problem, FSD comes with a new role: Personnel Manager. Anyone with that role gets the ability to assign people to departments, specialities, and other types of groupings, as well as to create and edit FSD people. The role can be assigned, like any other, in the Users and Groups control panel or locally using the Sharing tab.

Coming attractions

In development for over a year, the FSD release code-named "Hateful Haberdasher" represents a major redesign of the product. Its version number may turn out to be 3.0 or 4.0, depending on whether an interstitial infrastructure-focused release, currently under consideration, is made. Planned changes include...

  • Proper support for more than a single directory within a site. As a result, departments will no longer need to be able to exist outside a directory; instead, this niche will be served by a full set of FSD views on collections.
  • Merging of the grouping types. User feedback has shown that the profusion of slight differences between the types is confusing and arbitrary. The distinction between them will be removed, and the various "special tricks" of each will be applicable on demand.
  • Re-implementation of all presentation logic as viewlets. This will let site administrators reorder bits of FSD pages using Plone's @@manage-viewlets page. In addition, extenders will be able to add to views without having to customize entire templates.
  • A portlet for searching inside faculty/staff directories.
  • Many, many under-the-hood improvements which will improve performance, ease future development, and enhance extender products' potential.


In this article, we've explored the capabilities of Faculty/Staff Directory, a flexible product for representing information about people and their organizational relationships. We've seen how to organize people into committees, departments, and classifications and how to represent their research interests. We've also learned how to leverage those groupings for access control and, finally, had an inside look at the future of the product.

Further resources on this subject:

You've been reading an excerpt of:

Plone 3 for Education

Explore Title
comments powered by Disqus