Section Segmentation and User Permissions Part 1 of 2

On its own, a section consists of only a section ID, a name and a navigation part. It is best to think about a section in terms of how its ID is used. Consequently, the most applicable definition is "a virtual collection of nodes that belong together". In other words, it is a logical hierarchy or structure, different than the content node tree but applied to the nodes within it, as shown in the illustration below.

Segmentation example

The following functionality is provided through the eZ Publish section mechanism:

• Segmenting the content node tree into different subtrees, as shown above. Segmentation is usually a prerequisite for the other features listed below.
• Setting up custom template override rules. By using sections in the configuration of when to use which template, it is possible to have only a few rules that apply to all nodes within a logical group, in contrast to having a large collection of special-case rules. For example, you could choose a different layout for news articles than for company articles, according to their section. If the class attributes are the same, there is no need to define multiple classes. This is described in the eZ Publish Basics book.
• Limiting control and access to content. This is the focus of the second article in this series.
• Specifying content that is to be subject to approval in the built-in collaboration system. This is discussed in eZ Publish Advanced Content Management but will not be elaborated upon in this article series.
• Assigning discount rules to a group of products of the Webshop. This is discussed in eZ Publish Advanced Content Management but will not be elaborated upon in this article series.

Section properties

A section ID is an identification number that can be assigned to an object and denotes which section that object belongs to. It is stored in a special-purpose attribute within a content object, and you will not see this attribute in the main editing window. A section can be assigned to many objects, but a single object can have only one section.

It is the assignment of different section IDs to different objects that enables you to have a logical hierarchy in parallel with your sitemap-like content hierarchy. Your site can have as many virtual collections of nodes as you have section IDs.

Each section ID is also associated with a more user-friendly name, such as "Standard" or "Restricted", and a navigation part, such as the Content structure or Webshop tab. The name is used for easy identification of sections in the Administration Interface. The navigation part determines which main menu tab is accessed when you work with an object. In other words, when an object is requested in the Administration Interface, the system looks up the section that the object belongs to; the system then looks up the navigation part of that section and then displays the object in the tab as specified by the navigation part.

Built-in sections

eZ Publish comes with a set of built-in sections. The following list shows the built-in sections for sites with the Website Interface. Note that the first five sections correspond to the top-level nodes, although the section corresponding to the Content top-level node is named "Standard".

• Standard
• Media
• Users
• Setup
• Design
• Restricted

The Setup section is used to isolate configuration-related objects from ordinary content. This is achieved in conjunction with the permission and template systems. Similarly, the Design section is associated with the Design tab. It isolates template and look settings (such as the site title and URL, labels and footer text) from ordinary content and other configuration. The Restricted section is a protected area of the site, as achieved in conjunction with the permission system. By default, it is applied to a partner area, which can only be accessed by users in the Partner user group (or higher). Additional sections can be added as needed, as described later.

Section inheritance

When an object is first created, but is not yet published and thus has a "Draft" status, its section is set to the default Standard section. Recall that an object is not visible to site visitors, nor does it show up in the left menu of the Administration Interface, until it has been published. In other words, a Draft object does not have a location within the hierarchy, and it is only accessible to the user creating it. As a result, it does not matter what the section ID is at this time.

When the object is published, usually when you click the Send for publishing button, it automatically inherits the section ID assigned to the object encapsulated by its parent node. For example, if you create and publish a new object within a folder belonging to the Media section, the Media section is automatically assigned to the newly created object.

The picture is slightly more complicated when multiple locations exist for the parent node's encapsulated object. Cross-publishing is usually used only for non-container objects such as articles and documentation pages or product sheets, since adding a location does not include a node's subtree. In these cases, the section ID inheritance follows the main node of the object referenced by the parent node.