Online administration
Index d'articles
Online administration
All administration task can be performed online through the administration area.
The object edit interface
Whenever a you click the "Create here" button to add content or the "Edit" button, the system will bring up the object edit interface. This interface makes it possible to edit the actual contents of objects and to manage the object's versions and preview it.
The object edit interface usually consists of 5 windows:
- Object information (1)
- Current draft (2)
- Translate from (3)
- The main edit window (4)
- Related objects (5)
The "Object information" window
The "Object information" window reveals information about the object that is being edited. The following image shows how this window looks like.
The screenshot reveals that the ID of the object which is being edited is 5912. The object was initially created on the 11th of January, 2005 by Balazs Halasy at 9:19 AM. The object was last modified by the same user on the 9th of May, 2005 at 12:43 PM. The object exists in several versions and it is the 3rd version that is the currently published version. In other words, it is the 3rd version that will be displayed when the object is being viewed.
The "Manage versions" button brings up the version interface which makes it possible to administer the versions of the object that is being edited.
The "Current draft" window reveals information about the version that is currently being edited. The following image shows how this window looks like.
The "Current draft" window.
Every time an object is created or edited, eZ Publish will automatically create a new draft . A draft only contains the language that is being edited by the user. If a new object is being created or new translation is being added to an existing object then the draft will be empty. However, if an existing language/translation of an object is edited then the system will create a draft which contains this translation copied from the last published version.
This window simply reveals information about when the draft (which is being edited) was originally created, who created it and when it was last modified (stored). In addition, the window also reveals the actual version number of the draft.
Please note that the version number of the current draft differs from the version number of the published version (shown in the "Object information" window). The reason for this is because eZ Publish does not allow the editing of published and archived versions. It only allows you to edit drafts. When an object is edited, a new draft will be created and it is this draft that you will be able to edit.
The "View" button brings up the preview interface which can be used to generate a preview of the content that is being edited without having to publish it. When the "Store and exit" button is clicked, the system will store the draft and exit the object edit interface. The draft will be available in the "My drafts" list located under the "My account" tab. It can be re-edited at any time.
The "Translate from" window
The "Translate from" window reveals information about the existing languages and allows to select the language which the edited translation should be based on. The following image shows how this window looks like for an object that exists in English, French and Norwegian languages.
If the user selects a language using the radio buttons located in this window and clicks the "Translate" button then the main edit window will be switched to a special translator mode in order to make it easier to translate an object from the selected existing language.
The main edit window
The main edit window is where you can modify the contents of the different attributes that make up the object which is being edited. For example, if a news article is being edited, this window will most likely allow you to change the title of the article, the intro text and the body. The attributes will be displayed in the same order as they were set up when the class (which defines the actual data structure) was created. Required fields will have additional text "required" in the label. The following image shows how this window looks like when a documentation page is being edited.
In this case, there are 3 attributes that can be edited: "Title", "Body" and "Show children".
The "Send for publishing" button will attempt to validate the contents of the attributes and send the draft for publishing. If there are problems (for example invalid or missing data) then the system will indicate this using a yellow frame over the main edit window. If everything is okay, the draft will become the current/published version for the object and the previously published version will become archived. Since the draft only contains data for one language, the system will copy other languages from the last published version of this object to the draft when publishing it.
The "Store draft" button makes it possible to store the information that has been entered. This button is particularly useful when you're working on something and want to save your work from time to time. In addition, since eZ Publish will attempt to validate the input, this button can also be used to verify that the inputted data is correct according to the definitions that were set up when the class (the data structure definition) was created. Please note that the published version of the object will not change.
The "Discard draft" button makes it possible to get rid of the draft that is currently being edited. The draft will not be validated or stored, it will simply be thrown away.
The "translator" mode
The main edit window can be switched to a special "translator mode" so that the actual content in the selected existing language will be displayed above all the attribute fields. This makes it easier to translate an object from an existing language into a new one. The following image shows how this window looks like when a documentation page is being translated from English into German.
Previewing content
The object edit interface makes it possible to preview content before it is published. This means that you can for example generate a real preview of an article while you're typing it up. There is no need to publish it first in order to view it. The preview feature can be reached from both the edit and the version management interface. In the edit interface it can be accessed by clicking the "View" button, in the version management interface you can click on the different version numbers and translations. The following image shows how the preview interface looks like.
The "Media library" tab
The "Media library" tab makes it possible to browse and manage the nodes that belong to the "Media" top level node. This part of the tree should be used as a library for storing different kinds of media. For example, it can be used to store images, animations/movies, documents, etc. that are referenced by news articles, information pages, product pages and so on. The following screenshot shows what the administration interface displays when the "Media library" tab is selected.
The "Media library" tab functions in the very same way as the content structure tab. It makes it possible to arrange and manage nodes within a subtree. The purpose of this subtree is to serve as a container for content (typically media, hence the name) that is often reused. For example, it can contain a large collection of images that are referenced by different nodes found under the "Content structure" tab. The following illustration shows this concept.
Object relations
The content model of eZ Publish makes it possible to create relations between different objects. Any type of object can be connected to any other type of object with a click of a button. This is usually done when an object is being edited.
Managing users
The "User accounts" tab allows you to manage the users and user groups that have been added to the system. In eZ Publish users and groups are managed in a similar way as if they were on a filesystem. Users can be put into groups and groups can contain other groups. The following screenshot shows what the administration interface looks like when you select the "User accounts" tab.
Access control
This section explains how eZ publish manages user accounts and access permissions. The system comes with a built-in access control mechanism that can be used to limit access to content or to certain functions. The access control system is based on the following elements:
- User
- User group
- Policy
- Role
The following illustration shows the relations between the elements in the list above.
Users, groups.
A user defines a valid user account on the system. A user group consists of users and other user groups. A policy is a rule that grants access to content or a certain system function. For example, a policy may grant read access to a collection of nodes. A role is a named collection of policies. A role can be assigned to users and user groups.
Enabled and disabled user accounts
The user accounts can be enabled or disabled from within the administration interface. When disabled, an account will continue to exist, but the user will not be able to log in until the account is enabled. Newly created accounts are enabled by default.
Locked and unlocked user accounts
From 3.9, in addition to being enabled and disabled, user accounts can be locked and unlocked. An account will be automatically locked by the system if the number of failed login attempts is exceeded. A failed login attempt is a combination of a valid username and an invalid password. Once an account is locked, its owner will not be allowed to log in until the account is either unlocked by another user with administrator privileges or if the login request is coming from a trusted IP address / range.
Note that the default configuration does not allow different users to be registered with the exact same E-mail address. This is just a built-in precaution mechanism which can be easily turned off.
User ID
Every user has a unique identification number which is the same as the ID number of the actual object that represents the user account.
User group
A user group is a content object (with at least one node assignment) that contains user accounts and other user groups. In other words, a user group is just a collection of users (similar to a directory containing files and subdirectories on a filesystem).
Policies and roles
A policy is a rule that grants access to a specific function or all functions of a module. A policy consists of the following elements:
- Module name
- Function name
- Function limitation
The module name reveals the actual module that the policy grants access to. The function name specifies which function the policy should be limited to. A policy can either be restricted to a single function or grant access to all functions of a module. A module can have none or several functions. The functions are assigned to the module's views and thus the access requirements for a view are controlled by the functions that are assigned to that view. The function-view assignments can not be tampered with from within the administration interface. A policy granting access to a module's function can be further restricted by the way of function limitations. This can only be done if the function itself supports limitations. A function may support none, one or several limitations. The following table shows an overview of the available function limitations.
| Limitation | Description |
| Class | The "Class" limitation makes it possible to limit a policy to objects of certain types. |
| Language | The "Language" limitation makes it possible to limit a policy to object versions in specific languages. |
| Node | The "Node" limitation makes it possible to limit a policy to a specific node. |
| Owner | The "Owner" limitation makes it possible to limit a policy to objects that are owned by the user who is logged in. |
| Parent class | The "Parent class" limitation makes it possible to limit a policy based on the type of the object referenced by the parent node. |
| Section | The "Section" limitation makes it possible to limit a policy to objects that are assigned to certain sections. |
| Siteaccess | The "Siteaccess" limitation makes it possible to limit a policy to a certain siteaccess. |
| Status | The "Status" limitation makes it possible to limit a policy to a certain version status (published, archived, etc.). |
| Subtree | The "Subtree" limitation makes it possible to limit a policy to a certain part of the content node tree. |
Role
A role is a named collection of policies. A role can be assigned to users and user groups. It is possible to assign a role with additional limitations. The role limitation feature is typically useful in a case where multiple users with similar permissions have to manipulate different parts of the content node tree. Instead of creating a role for each user, the site administrator can create a generic role and assign it with different limitations to the different users. The role limitations will override the limitations of the role's policies. The following table shows an overview of the available role limitations.
| Limitation | Description |
| Section | The "Section" limitation makes it possible to limit a role to objects that are assigned to certain sections. |
| Subtree | The "Subtree" limitation makes it possible to limit a role to a certain part of the content node tree. |
Templates can be edited also through the interface and additional stylesheets imported.
