Using the Zope management interface
The ZMI is the basic interface that gives us access Plone's underlying Zope functionality. Before Plone existed, the ZMI was the only way to access, edit and manage a Zope site and it's content.
Plone tries to give you a more user friendly interface to the functionality found in the ZMI, like for example it's control panel, and efforts are underway to add more ZMI functionality to Plone itself, but sooner or later any Plone administrator will have to use the ZMI. The ZMI follows a tree structure similar to a file browser on a desktop computer, and you can enter the ZMI from almost any point in a Plone site by appending '/manage' to the URL.
Top level tabs
Properties
The properties form allows you to set some of the properties of the current object, in this case the Plone site. Some of these can also be set through the Portal Settings configlet in the control panel.
Note that portlets can be added and removed here by editing the left-slots and right-slots fields.
Security
The root level security form shows all the permissions on the site and the roles that they are mapped to. The left-most checkbox Acquire permission settins indicates wether permission settings are aquired from a higher level, in this case the Zope root. Every object in Zope and Plone has a security form similar to this one.
It is usually not a good idea to change the security settings for an object through this form since you will quickly lose control of the security of the site which may result in some unforseen changes and frustration. To finetune the security, it is better to change the workflow of an object.
Undo
One of the great features of Zope and thus Plone is that it allows you to undo some of the changes that you have made to the site. This is possible since the Zope object database (zodb) is transactional. Undo is a useful feature but don't relay on it too much since there are instances where you won't be able to undo a transaction. When values changed by the transaction that you want to undo, have been changed by a later transaction, it is impossible to undo.
Ownership
All objects in Zope can be owned. The ownership tab tells you who is the owner of the current object.
Interfaces
Zope objects are described by classed which implement certain specifications that are called interfaces. Interfaces describe the functionality that the class and thus the object instance of that class will have to provide. Another use for interfaces is to use them as markers. A marker interface is basically an empty interface that doesn't specify any functionality. The idea is that an object whose class implements that interface is marked or singled out. In this way developers can apply operations to only certain types of objects, by specifying their marker interfaces.
This section allows you to add marker interface to the current object. You can then enable or disable views on objects based on their marker interfaces. This is best done by a Plone developer and on the server's filesystem instead of through the web.
Find
The find tab provides a form that allows you to search for content in the Zope site fulfilling some criteria. The values of the fÑ–elds will be used as the criteria while empty fields will be ignored. The expr field allows you to use a regular expression as part of the search criteria.
Workflows
This tab presents portal type and workflow information of the current object and provides a link to the portal_workflow tool that will allow you to assign a different workflow or change the object's workflow state.
Tools
Plone consists mostly of objects called tools. Tools are unique objects, this means that there can be only one instance of a tool class. Compare this for example to the folder content type, of which there can be multiple instances in a Plone site. They are usually found in the root of a Plone site (the topmost level) and usually start with the prefix portal_. Tools are usually shared between objects and applications and can be used for various configuration options in Zope and Plone.
portal_properties
The portal_properties contains two other tools that allow you to configure even more portal functionality.
navtree_properties
Here you set the properties for of the NavTree, which is the top left portlet in a default Plone setup. This tool Ñ–s the backend for the navigation settings configlet in the Plone control panel. The settings specified in that configlet are all here.
See page 66 in Building websites in Plone.
site_properties
Here you can change properties that affect the look and behaviour of the site. The names are chosen to be self-explanatory.
See page 67 in Building websites in Plone.
portal_types
Here you can manage the content types of the site. Initially you see the view of the Contents tab which list all the types as links which you can follow to change their settings.
portal_actions
The portal_actions tool can be used for configurating the actions that are found throughout the site. We use actions to define UI elements in such a manner that they are separated from other UI code, so that we can customize them without modifying any other UI code.
portal_skins
In the contents tab of the portal skins tool, we can see all the all the available layers as defined by all the products that make up the site. The skins are layered, with the top most skins in the layers taking precedence. This means that a page template in a layer higher up in the stack will be rendered instead of a page template with the exact same name lower down. This allows for customization of the Plone site by overriding certain templates without actually editing the original templates.
The custom skin layer is a built in layer that is included specifically for customizations. It is automatically the topmost layer and templates in the other skin layers even have a button to copy it to the custom skin folder, from which it can be edited. Customizing templates by putting them in the custom folder is usefull but not a good permanent solution since it makes life difficult when we want to upgrade or redeploy the site.
portal_workflow (more in depth later)
One of Plone's impressive features is it's workflow functionality. Workflow gives a number of states (i.e visible, private, published) that the content can be in, which have certain permissions attached to them. This makes workflows an attractive mechanism to finetune the security of the site without having to change the roles and permission through the security tab which has it's shortcomings.
The workflows also define transitions between the states. Transitions can also be protected by permissions or restricted to certain roles. Some transitions are automatic although they are usually invoked by the user.
The intitial view of the portal_workflow tool is the Workflows tab which contains a mapping of workflows to content types. In the Contents tab, you can choose between the different available workflows and edit their states and transitions or create a new custom workflow.
portal_catalog
Plone provides a catalog for the indexing of content to allow for fast searching. In a relational database this function would be performed by SQL queries. All content is cataloged with some specific properties indexed. A different set of properties is stored as metadata in the catalog so that these values can be retrieved directly from the catalog without having to fetch the actual object which can be time consuming.
portal_form_controller
The portal_form_controller provides a mechanism for abstracting the validation and destination of forms in the Plone UI (Building websites P.78).
Users and groups tools (p.78)
The portal_membership and portal_groups tools provide a number of options to change the behaviour of workspaces and roles from non-default users' sources.
The portal_meberdata and portal_groupdata tools control what properties are available on members and groups. The properties that exist on the Properties tabs of these tools are copied onto the member or group objects when they are created. The contents tab can be examined to view all the members available on the site and prune orphaned records.
content_type_registry (p.79)
The content_type_registry tool defines what type of content is created when content is created without its type specified, as with FTP or WebDAV.
portal_factory
The portal_factory tool provides a temporary space for new objects to be created in before they are populated wÑ–th values to prevent the creation of object in the site that don't have any values which happens when the user adds an object, but then navigates away from the edit form without submitting it.
