Chapter 1. Introduction to Plone

A default Plone installation gives you an open, portal-type site, of a kind that harmonizes well with its inclusive, open source roots, and due to the amount of freedom given to a new user, perhaps fits best in an intranet-type setup. All comers can register themselves, and receive a workspace unencumbered by quotas where they can add content and collaborate to their heart's content. This is a shortened version of the page you see when you arrive at a new Plone site:

Figure 1.1. Plone Frontpage

Most public Plone deployments will require some customization to lock down various aspects, whether tightening the workflow permissions to control who gets to see unpublished content, or limiting the amount or types of objects that may be added. Any non-trivial site will also involve the creation of roles and groups that fit the domain of the user community. For now, we'll explore the dynamics of the default configuration.

The default homepage displays most of the visible common elements of the Plone UI. The page is divided into a header, a central section consisting of a content area flanked by columns on both sides, and a footer area. These are the visual divisions that the Plone stylesheets and templates make provision for. The content of the Plone page is arranged in terms of these divisions. The content comes from various sources. On this page, there are actions that come from the portal_actions tool, portlets that come from the portal_skins tool, and a view ("Welcome to Plone") that comes from the content type being displayed (a Document). The actions feature in different parts of the page, depending on their category. The main tabs in the header are global actions:

Figure 1.2. Global actions

Just beneath them are the personal actions:

Figure 1.3. Personal actions

Once you log in, these actions link to aspects of the Plone site of relevance to you specifically, such as your workspace and your preferences. The global actions tend to be the same for all users. Depending on your roles, the personal actions may also include worklists of items in workflow states that require your attention, or a link to the Plone Control Panel.

Also in the header are site actions. The fontsize selectors are the only ones in the default Plone:

Figure 1.4. Site actions

In the columns on the left and right of the content area there are portlets:

Figure 1.5. Left portlets

Portlets are selfcontained UI elements that may be supplied by any Plone product. Their order and position in the left or right columns may be configured per folder.

In the main content area, the icons to the right of the document headline are document actions, that display as icons rather than text, like the site actions:

Figure 1.6. Document actions

The responsibilities for site navigation is split between the breadcrumb trail, the navigation portlet, and the global tabs. These all form points of customization at different levels of Plone.

The remaining visible aspects of the page (the logo, the search box and the footer) are relatively static: unless they are overridden in parts of the Plone site, they are the same for all pages. That said, they are complex elements in themselves; e.g. the footer incorporates a separate colophon template (stating the standards implemented):

Figure 1.7. Footer

There is more to the page than what is immediately visible. Viewing the page with all stylesheets stripped reveals text ( Skip to content, Sections, Personal tools) that will show up for people browsing Plone using textmode or audio browsers, for example:

Figure 1.8. Plone page with CSS stripped

There is a further hidden aspect to a Plone page: the printed view. Here are two views of the frontpage (for the browser, and for printer):

Figure 1.9. Browser frontpage

Figure 1.10. The same page, for the printer

That's the same page, with the same source. The browser just applies the media="print" CSS stylesheet when printing, which drops out all the elements that don't make sense away from the browser. Similarly, there is a media="projection" for overhead projection (only honoured by Opera, for now).

Following the join link takes you to the Registration Form. The fields marked with red dots are required. (In order to get a page that fits well in screenshots, I moved all the portlets on the right over to the left column, causing the right column to collapse, not taking up any space.)

Figure 1.11. Registering as member

We'll see a bit later how a Plone manager may configure this form (configuring whether members are allowed to choose their own passwords, for example).

After logging in, the personal actions and a recent items portlet appears in addition to the anonymous view:

Figure 1.12. Logged in

Apart from these, the Plone homepage looks almost the same as that seen by anonymous users. Two other differences are worth noting: the personal actions have been augmented with a circular icon (showing Add to Favorites if you hover over it), and the document has gained a byline:

Figure 1.13. A member's document actions

Figure 1.14. The document byline

Following the link to my folder, you'll see the content framed by a green border with tabs and two javascript dropdowns. The tabs are yet another category of actions (they're object actions, actions pertaining to this content type specifically), and so are the dropdowns (they're content actions, that are valid for any content type). This frame appears around all editable content. A member will see it in their workspace, and in folders shared with them by other members.

Figure 1.15. "Editable" border

The my preferences link takes a member to a page where they may set global preferences. The interesting ones here, for now, are Content editor and Allow Editing of Short Names. At the moment, the only TTW editing option available is HTML 'textarea's. Once we install Epoz and/or Kupu, they will be available for choosing here. The short names mentioned here are the ids of the objects in the object filesystem, that also show up in URLs. Allowing users to choose them can make for clean URLs if you have technically-oriented users, but it is worth consideration to provide a generateUniqueId script that fits your site.

Figure 1.16. Personal preferences

We can visit the public interface of the Plone site as our Zope Manager user. When we do this, Plone creates a blank workspace for our user, but it does not create a user object in the Plone acl_users folder: the manager user is acquired from an acl_users folder higher up. This does have some impact on the integration of this user in Plone: for example, even though he has all the rights to administer the Plone site, he cannot belong to Plone groups.

Therefor, it's advisable to add a group such as Administrators to our Plone site, in order to have Plone's user administration facilities available for managing our Plone managers (e.g. adding and removing members from administration duties). You'll see that the personal actions of users with the Manager role includes a Plone Setup link:

Figure 1.17. A Manager member's personal actions

Follow that link to reach the Plone Control Panel. Here, all the global site settings that need to be administered on an ongoing basis are accessible. (For customisation, you'll need to drop to the ZMI or Python level.) The first one we'll pay attention to is the Users and Groups Administration.

Figure 1.18. Plone Control Panel

Managers can add members, and edit the preferences of members. For example, here are the preferences that member saw on their personal page earlier:

Figure 1.19. Member preferences

Managers can also add groups. Here I've added a member called manager and a group called Administrators. The Administrators group has the Manager role, and manager has been assigned to that group:

Figure 1.20. Added a manager user

Figure 1.21. Added an Administrators group

Figure 1.22. Added the member to the Administrators group

To switch to this user for administration purposes, follow the log out link. Note that you may still be logged in via HTTP Basic authentication (Plone uses cookie-based authentication). If you are, browse to /manage_zmi_logout and you should be set.

You'll also notice that with the creation of a group, a Groups folder has been created with a workspace for Administrators. This is visible in the navigation tree for members who belong to some group ( manager sees it; member doesn't):

Figure 1.23. Manager logged in

Members of the Administrators group have editing permissions in this group folder:

Figure 1.24. Manager editing in shared workspace

It is a good introduction to Plone access control to visit the Sharing tab of the workspace. This is quite a long page. The top part of it shows the permissions currently granted on this object:

Figure 1.25. Sharing permissions for Administrators workspace

They fall into two categories: Acquired roles and Assigned roles. In the first category fall our manager users: admin that was created during the creation of the Zope instance, and jean, who I added afterwards to work with. As users with the Manager role, they have rights everywhere. The Administrators group falls in the second category. When this workspace folder was created, this group was assigned the Owner role on it. Therefor, members of this group also get this role, and may add and edit contents.

When logged in as a Manager user, you will see the editable border around all pages of a default Plone site, including the front page and member pages.

for permission in permissions:
    # The user must be able to match at least one of
    # the listed permissions.
    if _checkPermission(permission, context):
        verified = 1
        break
    else: #DBG 
      from zLOG import LOG; LOG('info',0,'',
      'failed. action.id: %s, '
      'permission: %s, '
      'context: %s'%(action['id'], permission, context))
  

The acquired roles appear here by virtue of their definition elsewhere in the site. If we wanted admin to go away, we would visit the object at http://server:8080/acl_users/manage_users and revoke their Manager role --- we can't edit that here. Only the assigned roles can be edited here. The remainder of the page makes provision for sharing the folder with more people in the site:

Figure 1.26. Sharing the Administrators workspace with other groups and members

Local roles may be assigned per user or per group. This creates a flexible way of enabling collaboration with an appropriate measure of privacy. Note that members may only delegate roles that they themselves possess at that point. So, in a default Plone, a member may assign the Owner role to other members, while a manager may assign Manager, Member, Owner or Reviewer.

I've added another group, Reviewers, assigned the Reviewer role to it, and added a reviewer member. At the workspace of reviewer, she can delegate both the Reviewer and Owner roles:

Figure 1.27. Roles the 'reviewer' member may delegate