3.1 Chapter Overview

The third chapter named Core Features and Modules discusses core features of a content management system. Core features are basic ideas that are parts of the global architecture and affect the whole application. First part of this chapter describes two fundamental parts of the system, the page axis and the component axis. The page axis deals with vertical partitioning of a website into presentations and a tree-based hierarchy of pages. The idea of component axis is based on modules, components and elements. The second part of this chapter discusses security and the permission system. The section about security identifies typical security problems of a web application and explains their prevention. The permission system is the third fundamental part of the Urchin application that is tightly connected to both the page axis and the component axis. The last minor part discusses several ideas of advanced content management.

3.2 The Page Axis

The page axis is the first of the core features used in the Urchin application. This section discusses vertical partitioning of a website into presentations and pages. The database schema in figure 3.1 displays relations between all tables that make up the page axis. This diagram shows basic tables for presentations, pages, and templates together with additional tables for languages, page groups, or parameters. All important parts and features concerning the page axis will be described in the following text.

Figure 3.1: Schema of the page axis with presentation, pages and templates

3.2.1 Website

In the context of a web content management system, a website is a top-level structure that contains hierarchy of web pages with static or dynamic content. A website deployed with Urchin CMS works exactly this way. Concrete website runs on a single domain and uses a single installation of the system for its administration. Typical website contains one or multiple presentations, each with a customized page hierarchy. A presentation usually represents a language mutation or an independent part of the website, e.g. a product micro-site.

3.2.2 Presentations

A presentation is the basic part of the website, the website must contain at least one presentation. Each presentation has assigned a language and is composed of a hierarchically arranged tree of web pages. Presentations might be either used as language mutations of the website, e.g. English and Czech version, or as independent sites of the website, e.g. company and product presentation. Combination of both approaches is also possible. Different presentations in the front-end are recognized using a unique url segment. In the future, running each presentation on a different sub-domain will be supported.

In the administration, basic SEO settings for presentations are provided. The website administrator is allowed to set up presentation title, pretty url, keywords and descriptions. All of these settings are shared across pages in the same presentation. Presentation parameters enable adding custom variables in the presentation scope. This feature is very useful for custom modules or functionality, but is not used in default application. In the administration, the user always selects a single presentation to manage. This severely reduces complexity of the user interface.

3.2.3 Pages

Pages represent the basic structure of a website. Each presentation contains its own different set of pages forming a tree-based hierarchy. A typical page has zero or more sub-pages according to its position in the hierarchy. Main purpose of pages is to present website content and allow user interaction with the website. The page content is managed using components and elements. These units will be discussed in section The Component Axis. Each page uses a single template with multiple pre-defined positions that serve as containers for components. In the administration, pages for currently selected presentation are managed in a tree view. This tree view allows user to perform all basic actions for modifying both pages and content elements. Page groups are used in the permission management, each page by default belongs to the main page group.

The page administration provides many additional and useful features. Basic settings include page title, heading, pretty url and flags for displaying page in the main menu and in the site-map. It is also possible to redirect page to another page in the same presentation (cyclic redirections are not allowed). This option is commonly used to redirect to the first sub-page in the lower level of hierarchy. Each page might have planned publication for a chosen interval or belong to the restricted zone. Pages in the restricted zone are available only to the logged users in the front-end. Similarly to presentations, pages allow user to edit basic SEO parameters, e.g. pretty urls, keywords and description. Changing position of a page is possible manually or using a drag-and-drop feature in the tree view.

The diagram in figure 3.2 shows a simplified structure of a company website. This website is designed using the described principles. The website has two different presentations that serve as English and Czech language mutations. Each presentation has several pages, the structure of pages differs with the presentation. In the diagram, the English presentation has five different pages: home page, news, services, references, and contact while the Czech mutation has only three pages: home page, services, and contact (all system pages are omitted).

Figure 3.2: A sample website with two presentations and several top-level pages

3.2.4 Templates and Positions

Templates are important for displaying page content. A template represents page layout and is very closely related to the graphical design of a website. In example, a website has three graphical layouts: a home page, a common page, and a product page. Each layout corresponds to a different template. The template usually contains one main and several other positions for assigning components. The number and location of positions depends on the concrete template and is fixed. Templates and their positions are designed before the website content is created. These settings are static and cannot be changed by the user via administration (manual change in the database is possible without any harm). Each page uses a single template that is selected during the page creation. Available positions, as well as assigned components and their elements are visible in the page detail in the tree view. All templates internally use a built-in PHP templating system [36], which is the most minimalistic solution.

3.2.5 Page Parameters and System Pages

Page parameters enable setting up custom variables within the page scope. With appropriate permission, the user can edit these parameters in the administration. There are two different types of page parameters, custom and system. Both types work similarly, they are key-value pairs assigned to the selected page. Custom parameters are used for implementing custom modules and functions. In every presentation, there are five system pages, distinguished by system parameters. System pages and parameters cannot be deleted because they provide fundamental functionality. The default system parameters are:

• is_homepage = 1
• is_sitemap = 1
• is_fulltext = 1
• is_error_404 = 1
• is_error_403 = 1

The home-page serves as the default page in the presentation, the site-map displays a simple tree with pages and links. The full-text page shows results of built-in search. The error pages are shown to the visitor if he requests non-existing page (404 Not Found) or is not authorized to view the requested page (403 Forbidden).

3.3 Internationalization and Localization

Urchin CMS is a completely multi-lingual application. Many languages are supported both in the administration and in the front-end. Each language has assigned a locale for formatting strings and adjusting user interface. All files and translations in the system use the UTF-8 [46] encoding. The Czech and English languages are default for the administration, the Czech, English, German, and Swedish languages are available in the front-end. Adding a new language to the front-end requires translation of all terms and putting them to the configuration file. This new language must be added to the a_language table and selected in the presentation settings. Internationalization and localization applies to all strings, such as titles, labels, and feedback messages.

3.3.1 File-Based Translations

From the technical point of view, two different approaches are used for translating terms. The first technique is very simple and flexible. It uses a translation method of the Context class. This method takes a string as an input and returns a translated term. The input string also serves as a default value, no artificial keys are necessary (but sometimes used for feedback messages). Hence this method is suitable only for short terms up to a single sentence. Values are looked up in the array with translated strings that serve as a simple key-value storage. Dynamic parameters in the translated terms are also supported. This system is hugely influenced by the QT framework [41] for C++ and its internationalization system.

3.3.2 Database-Based Translations

The second method is used exclusively for database-stored system terms in the database. For each database table and column using this approach, an additional table exist. This translation table appends suffix *_ext and contains translated strings along with a foreign key to the language table. In example, module or state names are translated using this method. Terms translated this way are never modified by the user and are often cached to counter an additional join required to retrieve these records. Moreover, this method is used only in the administration. Other popular approaches for translating strings are gettext [12] or storing all terms in the database thus allowing the user manipulate this data.

3.4 The Component Axis

The component axis represents the second most important core feature employed in Urchin CMS. This concept deals with horizontal partitioning of a website that is implemented using a unique system of components. Components are derived from modules and serve as simple containers that are assigned to web pages. A typical component contains one or multiple elements. An element is basically a specific database record with specific parameters and behaviour, such as a simple text, an article, or a web form. Elements represent the lowest level of website content. Diagram in figure 3.3 shows all database tables of the component axis and relations between these tables. Main tables work with modules, components and elements. Remaining tables enable linkable modules and store additional information, such as module templates or parameters. All major parts of the component axis will be discussed in detail in the following text.

Figure 3.3: Schema of the component axis with modules, components and elements

3.4.1 Modules

A software module in Urchin CMS is an independent unit of code that serves a single purpose. Each module always contains one or more administration controllers and a database script. Most modules employ additional files, such as model classes for all database-oriented modules or templates and web controllers for front-end modules. Regardless of type, each module has a public interface and hidden implementation. Public interface is used for communication with other parts of the application whereas all internal operations are separated from other system units. This design serves both flexibility and maintainability of the Urchin application. Installing a new module is simple and has two phases, copying files and running the database script. The installation script connects the new module to the system, adds new database tables if required and sets up desired permission for default user groups.

Two basic types of modules exist in the system, called system and web modules. System modules form integral part of the system that is used exclusively in the administration for internal tasks and settings. System modules never contain sub-modules and therefore use only one controller per module in the administration. Content modules are used in the front-end for presenting website content to the visitor. In contrast to the system modules, more complex content modules consist of multiple sub-modules. Content modules are also managed from the administration utilizing crud-based or custom controllers.

3.4.2 System Modules

System modules are used solely in the administration and allow managing system settings, permission and various other features. Most system settings are restricted only to the administrator group, not ordinary editors or supervisors. Only user settings are available for all user groups. Main areas handled by the system modules are shown in the following list.

• permission - users, groups and access rights
• modules - internal settings and parameters for modules
• caching - manual purge of cached data
• lookup tables - system states and enumerated values
• user log - logging of user actions in the administration
• user preferences - personal settings, favourite links, internal contact form

3.4.3 Content Modules

Main purpose of content modules is to enable administration of the website front-end. Content modules are used to manage website structure and content from the administration. As denoted in the previous text, some content modules contain multiple sub-modules. Content modules are divided into two categories according to the module type. These two categories are application and element modules. Complex modules commonly contain sub-modules of both types.

3.4.3.1 Application Modules

Application modules work in the same manner as the system modules. The administration of system modules is exactly the same as for system modules and uses similar common crud-based or custom-implemented controllers. Unlike element modules, these ones do work only with standard database records, not elements. The application modules either provide basic data for the front-end or support element modules in delivering content. The following list shows most relevant areas that use application modules outside the content module scope. Application modules cooperating with element modules will be discussed in the following text.

• the page axis - presentations, pages, templates, positions
• the component axis - components and elements
• localization - languages, locale, translations
• files - file and image manager
• indexing - transformation of content for full-text search
• clients - front-end users and groups

3.4.3.2 Element Modules

In contrast to application modules, element modules are used especially to provide content of various type to the front-end. These modules work with special database records entitled elements. Elements share common features but differ in module-specific options. Element records are always managed using a controller that is instanced from the element crud. Administration of elements closely cooperates with permission sub-system and content work-flow. Technical details about elements will be described in a separate section.

A simple content module always equals a single element module. A complex content module is usually composed of a single element sub-module and one or more application sub-modules. In this case, the element module is responsible for publishing content on the website while the supporting application modules take care of additional information. See figure 3.4 that shows examples with structure of several content modules. In the diagram, three of basic content modules are present. These are Article, Event, and QuickContact module. Component entities in figure represent whole modules, class entities mirror both administration controllers (sub-modules) and database tables.

Figure 3.4: Organization of content modules into element and application sub-modules

3.4.4 Components

Components are derived from the element modules and used for publishing content on the website. The module serves as abstraction while components realize this abstraction. In example, the module Articles has derived two components entitled Sport and Business with articles about these topics. A component serves as a simple container for elements and is used to manipulate these elements as a group. The maximal number of elements allowed in the component is defined in the element module. There are modules that allow zero, one, or unlimited number of elements per component. Modules with unlimited number of elements are used to group similar entities, e.g. news, articles, or events. Modules with a single element represent content without records, e.g. simple text, any forms, enquiries. Modules without elements do not have any content and are used only for default system pages with search results and a site-map.

Components are being assigned to website pages. As described before in the previous section The Page Axis, every page has defined a template with positions. These positions work as place-holders or slots, one position for each component. In example, a page Contact contains components with a short text, a map, and a contact form on three different positions. All menus are built-in and do not require components. Components do not have any settings beside title, internal description and a voluntary module template. All settings are managed on the element level, a component either is or is not assigned to the page. Components are very flexible, the same component might be assigned to multiple pages, even across the presentations. This possibility prevents unnecessary duplication of the website content.

3.4.5 Elements

As already denoted, elements are specially designed database records. Elements represent the low-level layer of website content. From the technical point of view, each element is composed of two parts, the element part and the module extension. Both parts are connected via a 1:1 database relation using the class table inheritance design pattern [9]. The element part is always stored in the a_element table and the module extension in a module-specific table, e.g. m_news for news elements. The diagram in figure 3.5 displays relations between the a_component table, the a_element table and three module-specific tables.

Figure 3.5: The relation between the element table and module-specific tables

The administration of elements provides a handful of useful settings and features. Managing element title and planning publication is available to each element. This includes setting up dates and the work-flow facility. The dates define the interval when the element is visible on the web, the content work-flow will be discussed in section Context Work-Flow. Other settings and options vary with the module. Many additional content-oriented features of the application are also handled on the element level. This includes content indexing for the full-text search facility, content approval, online preview or logging users' actions in the administration.

3.4.6 Module Templates and Parameters

Module templates is an optional front-end feature of Urchin CMS. In the former versions of the system, each module had exactly one set of templates for the front-end. All components of the module therefore had to look exactly the same on the web. In contrast with this situation, module templates allow the user to choose a set of templates separately for each component of the same module. All additional files for templates must be created and installed before the selection is available.

3.4.7 Linkable Modules

Linkable modules add an additional and slightly different concept for handling front-end content. Instead of assigning components to positions on the page, components of the linkable modules are connected to elements. A linkable component cannot be published on its own, the parent element is mandatory. Concept of linkable modules enables additional functionality for elements, such as adding a photo gallery, a discussion or voting, or adding a map with coordinates. In addition to the graphical appearance, the assigned component has information about the parent element. At the moment, this feature is experimental with only the Gallery module available. For logical reasons, each element might have assigned only one component per linkable module, e.g. one discussion and one gallery but not two discussions.

3.5 Security of a Web Application

This section lists typical and wide-spread security problems of web applications. The following text discusses details of four common security problems according to the OWASP project. The investigated areas are: SQL injection, cross-site scripting, authentication and session management, and cross-site request forgery. Each problem is shortly described along with its common causes and solutions, both general and Urchin-specific. Other types of security problems are omitted in this work. The most recent stable list of top 10 security risks is available at [29] and the most present but pending list accessible at [32] for details.

Additional security features in the Urchin application are related to either the permission sub-system or specific modules. Details about permission and access rights are discussed in the following section entitled The Permission System. The most remarkable content modules are described in chapter Extending Modules including security aspects of these modules.

3.5.1 SQL Injection

SQL injection [31] is a most common but under-estimated type of attack in the web environment. It is not difficult to perform this kind of exploit even for an average programmer. A successful attack often results in data loss, theft, or corruption. A software application is vulnerable to the SQL injection if its database queries allow putting untrusted data in the query construction. Untrusted data come usually from the user's input or a similar source. The injection occurs when the data are incorrectly escaped or directly concatenated into the query. Other types of injection also exist, this includes exploiting operating system commands or various application parameters.

The solution for this problem is to never trust the user's input and use a secure API to prevent the vulnerability. The user's input must be always validated and sanitized before using values in the application. The validation checks e.g. the data type of the value, allowed interval or white listing. A good API must enable separation of database queries and their arguments. Well-known libraries for the PHP language that satisfy these requirements are PDO [39], ADOdb [1], and MySQLi [38].

In the case of Urchin CMS, validators are widely used for controlling input, input values are sanitized and the PDO library is employed for building database queries. The whole model layer uses this library for building prepared queries. A tricky part comes with the crud library that in addition uses dynamic queries. Crud queries include parameters such as table or column names that cannot be parametrized this way. But this is not a security risk because table and column names are always statically defined in the crud instances so they never come from the user's or other dynamic input. The limit clause cannot be parametrized either, a simple solution here is to check whether the value is a valid integer.

3.5.2 Cross-Site Scripting

A cross-site scripting (or XSS) vulnerability [30] occurs when a non-escaped value is output to the user. This value comes from the user's input or another source and contains a text-based script that exploits the website. The attack then performs a malicious action, e.g. redirects the user, steals his cookie or inserts unwanted code into the page content. In example, a stolen session identifier from the cookie is often used to further exploit the site using a CSRF attack. The solution for this security problem is to correctly escape all untrusted values before propagating them into the browser. The concrete escaping depends on the context, e.g. a safe string for HTML output differs to a safe string in the JavaScript context.

Urchin CMS employs this approach on the view level. Templates include slots that are used to output variables in the HTML context. All template values are sanitized in the Pool object before sending them to the template. Inserting cascading style rules or client scripts is not allowed in any content field and automatically excluded from rendering. Displaying HTML is only possible in fields that use the TinyMCE [44] WYSIWYG editor. The Link object escapes all parameters in automatically generated links.

The caveat of the WYSIWYG content editing is that it naturally requires modifying and rendering of the HTML code. The automatic escaping procedure therefore cannot be utilized. WYSIWYG content editing is allowed only in the back-end by editors and all actions in the administration are logged. This protection is far from being perfect, but sufficient. More sophisticated solutions also exist, in example the HTML Purifier project [17], lightweight mark-up languages, such as BBCode [4], or a mark-down syntax. The first library is a verified solution but is a total overkill comparing its size to the Urchin application. The second one is a possible option, but offers only a reduced comfort and set of functions for the user.

3.5.3 Authentication and Session Management

This section shortly describes security vulnerabilities tied to authentication, session, and account management. The attack of this type is possible in several different ways. Plain-text passwords in the database present severe risk if the attacker gains access to the database. The authentication process might be exploited if non-secure or weak hash functions are employed. The session is vulnerable to attacks if the session identifier is exposed in the URL, an application is vulnerable to XSS attacks, or the session is not regenerated after significant actions, e.g. logging in. A stolen session ID enables exploiting user accounts and data, especially in the case of privileged accounts.

The Urchin application uses several steps to prevent this kind of attacks. This prevention begins with the authentication process. Passwords in the database are stored in an encrypted form and salted to prevent a rainbow table attack. In the current minor version, the former hash function SHA-1 [11] used for storing passwords has been replaced with the stronger SHA-2 variant. Functions for account management do not expose vulnerable information, such as user identifier, login, or mere existence of the user in the database. All actions in the administration are logged, including authentication.

The session identifier is changed after significant actions, such as when user logs in. The log out link is provided to explicitly log out the user and remove his session data. If the user closes browser instead of logging out, the session time-out applies after the defined interval. As described in the previous text, additional XSS protections are utilized to prevent stealing the session identifier. In addition, a completely custom session handler and an optional use of SSL connection for the login form are planned to further improve security.

3.5.4 Cross-Site Request Forgery

The cross-site request forgery (or CSRF) [33] is the last type of attack listed in this text. This attack occurs when the hacker forges a HTTP request. The user is then tricked to submit this request, generally using social engineering methods. In example, he unwillingly submits this request via the image src attribute that includes a malicious link. XSS exploits are also used for triggering this attack. The success of the attack depends on predictability of the forged request. The simple but sufficient solution for this problem is to generate a unique and non-predictable token for each request.

Urchin CMS employs exactly the previously stated method. Requests that modify data in the application are always sent via the POST method. This includes all forms in the application. The token is generated before the page is loaded, so it is unique for each non-AJAX request and shared for multiple AJAX requests on the same page. On the other side, simple links do not need this security mechanism because they do not change any data in the application.

3.6 The Permission System

This section of chapter Core Features and Modules discusses the permission system that is the last of the three fundamental concepts of the Urchin application. The first part of the text explains main ideas behind managing user accounts and permission in a web application, e.g. access control, authentication, authorization and access rights. The second part describes application of these ideas in Urchin CMS. This part describes user groups, managing access in the system and differences between the administration and the front-end. The last short part discusses planned permission management on the front-end.

3.6.1 Authentication and Authorization

Authentication and authorization are the two most important mechanisms concerning controlled user access in an online application. Authentication is the process of identifying the user and verifying his identity. Authentication systems depend on a unique information known only to the system and the user. Such information is usually a common password. Other methods are also possible, e.g. using a client certificate or a fingerprint. The user is challenged to provide his unique information in the login phase.

In contrast to the authentication, the authorization mechanism is used to determine the level of access the user should have assigned. Authorization mechanism is utilized after the user is successfully authenticated. Based on the permission settings, the application authorizes the logged user to perform particular operations and access system resources. Both mechanism could be either separated, e.g. using different software or servers, or tightly coupled, e.g. inside the same application. The latter option is common in web applications. Figure 3.6 shows a simplified login process for a web application with both authentication and authorization facilities.

Figure 3.6: Login process in a regular web application with authentication and authorization

3.6.2 General Access Control

Every content management system requires some kind of access control to recognize the user and grant him permission to work with the application. The most primitive systems use a simple authentication mechanism that checks user credentials against static configuration. User accounts in such an application cannot be added or edited. More complex systems work with users. Access rights are connected to the users and this kind of application supports multiple user accounts.

Advanced applications employ a more sophisticated system of permission for the administration, including user accounts and groups. User groups serve as roles, e.g. admin or editor. Access rights are therefore granted to the groups instead of users. User groups are effectively used both to combine access rights from more than one user group and manage permission for many users at once. User groups could be either fixed or dynamic, or both. In addition to the administration, many web applications also manage user access to the front-end.

3.6.3 Action and Data Permission

There are two most important models to manage permission for web applications, either an action-based approach (also called action control list) or a data-based approach. Non-trivial web applications and content management systems combine both methods up to some extent. The action-based approach works with roles, objects and operations while the data-based approach works with roles and records. User roles are represented by user groups and accounts as already denoted in the previous text.

The action-based model defines objects and operations. Objects represent various entities that have attached a set of operations. Entities are in example files, modules, or resources. Each entity-operation pair has defined the basic access, either allow or deny. User roles have assigned these access rights as required. The data-based approach allows fine-grained permission management within a single entity, such as a database table. This method enables differentiated level of access to records of this table that would not be possible with the action control list.

3.6.4 Users and Groups

The administration of the Urchin application uses a combination of security mechanisms described in the previous text. Users belong to zero or more user groups and access rights are associated with the user groups. Four user groups with predefined access rights are provided with the installation, as enlisted in table 3.1 along with summary of permission. Access rights for both default and custom user groups are completely customizable. New groups and accounts might be added later.

Table 3.1: Default user groups available in the Urchin application.

user group	visible	used by	summary of access rights
editor	yes	client	create and edit content
supervisor	yes	client	as editor + publish content, manipulate pages & files
admin	yes	client	as supervisor + manage accounts, system tasks
root	no	developer	as admin + manage user groups and permission

The permission system includes three independent levels of controlling user access, these are modules & actions, presentation and pages. Figure 3.7 displays a database model with all important areas of the permission system. Details of all levels of permission will be discussed in the following text. Access rights to all areas are denied unless explicitly assigned to the group. Even the root user group does not have unlimited permission.

Figure 3.7: Database tables of the permission system and their relations

3.6.5 Permission for Modules and Actions

Implementation of access rights directly follows the already described action-based approach. Urchin modules serve as objects and options as operations performed on these objects. There are six defined options in the Urchin system, as explained in table 3.2. Each module has assigned one or more options (the view option is always present). The module-option pairs are immutable and provide the basic matrix for assigning permission to the user groups. In figure 3.7, the a_module_in_option table contains all available pairs and the a_user_group_in_module_option table stores access rights assigned to the user groups.

Table 3.2: Options available to the modules.

access option	common use
view	view list of records
detail	view detail of record, access nested crud instances
edit	edit existing record
add	add a new record
delete	delete an existing record
approve	publish element (element modules only)

Assignment of options depends on the module's purpose. Simple modules have only view while more complex modules employ up to all five basic options. The approve option is connected to the content work-flow and therefore available only to element modules. Content work-flow will be further described in the last section of this chapter. Table 3.3 shows sample modules together with available options and additional information.

Table 3.3: Sample modules of various types with assigned options.

module	type	assigned options
Caching	system	view, edit
Content	element	view, detail, edit, add, delete, approve
Language	system	view, detail
News	element	view, detail, edit, add, delete, approve
Page	application	view, detail, edit, add, delete
Presentation	application	view, detail, edit
Tree (of pages)	system	view

Common crud works with all five basic options, element crud with all six options, and cross crud only with view and edit options. Main crud actions are directly mapped to the options, the crud instance is adjusted according to the assigned access rights. Several actions (methods) usually share a single access option, both in crud-based and custom controllers. Access rights are managed using the matrix crud, as seen in figure 3.8 that displays part of these settings. This is the only use of a matrix crud instance in the application.

Figure 3.8: Managing access rights to actions in the detail of the user group

3.6.6 Permission for Presentations

Data-based access rights in the Urchin application are managed on two levels, the presentation level and the page level. This feature is not available nor planned for e.g. components and elements although custom implementation is possible. Presentation-based access rights are very simple. If the user has sufficient permission, he can perform actions in the presentation, otherwise he cannot. As displayed in figure 3.7, the table a_user_group_presentation stores these settings. This settings is useful when different users are responsible for different presentations. Users are allowed to access all presentations according to default settings, so this permission is in fact suppressed if not required.

3.6.7 Permission for Page Groups

Permission for page groups is a mechanism similar to the presentation access. The idea behind this feature is to separate responsibility for pages of a large website into smaller groups. Page groups are then assigned to the user groups. Each page group could contain pages from different presentations. The table a_user_group_in_page_group is used to store these settings, see figure 3.7 for details. As well as for presentations, use of this feature is optional. Each page belongs by default to the main page group, this cannot be changed. The main page group is pre-selected for all predefined user groups. Additional page groups are then added for advanced page management.

3.6.8 Additional Features

This short text describes two minor features connected to the permission system. The first must-have feature is detailed logging of all modifying actions in the administration. Modifying actions change data in the database, e.g. edit or delete. Logging in and out of the application is also tracked. Non-altering action are not logged to prevent excessive size of the log. Each log record includes information about the user, module and action performed, unique record identifier, IP address and the time of change.

The second feature is the built-in soft delete. The soft delete sets record status to deleted (or similar) instead of physically deleting the record. This option avoids potential data loss and might be also useful in the future for content versioning or a recycle bin facility. There are also two minor drawbacks of this approach, the larger size of the database and the necessity to exclude those 'deleted' records in queries, such as counting records. Complexity of queries is slightly reduced using views for all content modules.

3.6.9 Front-End Permission

Even though the front-end registration and user have not been yet implemented, basic ideas for front-end user management already exist. The same concept of users and user groups will be utilized for the front-end. Two user groups are planned, registered user and member. Table 3.4 shortly summarizes all front-end user groups. Page settings already enable putting the page into the client zone. Users on the web will register and log in to the system using a pair of new modules. Those that do not register will remain visitors. Visitors are allowed to browse any public page of the website.

Table 3.4: Front-end user groups available in the Urchin application.

user group	is registered	access rights	notes
visitor	no	view public pages	any non-registered visitor
registered	yes	browse client zone
member	yes	browse client zone	for implementing custom options

3.7 Additional Features

This short section briefly describes three minor but important areas connected to the core features, especially to elements and permission management. These topics are content work-flow, content preview and personal settings. The content work-flow describes the built-in facility for approving content while the content preview enables previewing elements before they are published. Personal settings is about customizing user account and settings.

3.7.1 Content Work-Flow

A simple work-flow management is an integral part of the Urchin application since its first version. The work-flow is realized on the element level, so it is automatically applied to every element module and therefore to any publishable content of the website. Pages are not part of this sub-system because they in fact do not store any content, only contain positions for components with content.

The element life cycle includes five possible states, as displayed in figure 3.9 featuring a comprehensive state diagram. Element work-flow states are closely coupled with the permission system and its approve option. There are four states used in the work-flow: the edited, the waiting, the approved, and the rejected state. The user can switch between element states as depicted in the diagram if he has the corresponding permission. The delete state is not a part of the work-flow management, it is used only for the soft delete feature. Softly deleted elements are never displayed in the administration.

Figure 3.9: The life cycle of an element with visible and hidden work-flow states

Newly created element have always assigned the edited state. If the user has assigned the approve option for a concrete module, he can change element of this module to any state according to the element life-cycle. Without this permission, the user can only switch between the edited and the waiting state (assuming he has rights to edit or add the record). Table 3.5 summarizes all work-flow states with further description. Talking about the default user groups, administrators and supervisors have assigned the approve option for each content module. These users can both create and publish content. In contrast, editors do not have this option so they cannot publish anything.

Table 3.5: Summary of work-flow states and their use.

state	permission required	typical use
edited	edit or add	newly created and incomplete elements
waiting	edit or add	completed elements waiting for approval
approved	approve	elements published on the front-end
rejected	approve	rejected elements that require re-working

3.7.2 Content Preview

Content preview is a simple feature that does exactly what the title says. Content preview allows the user to preview content elements before they are visible to the website's visitors. Preview links are available in the tree menu either for a page, a component or a selected element. In example, the component preview shows a list of articles while the element preview shows detail of a selected article. Previewed page looks exactly like the original front-end page with addition of non-approved elements and a simple panel with summary of preview details. Content preview does not support previewing changes during element editing as this information is not saved in the database before saving.

3.7.3 Personal Settings

Personal settings and options in the administration are rather simple. Basic settings include changing user's password and language for the administration. The second feature is a simple contact form. This form allows the user to directly submit a bug or contact the system's developer. Favourite links serve as bookmarks in a browser. The user can add any visible page in the administration to these bookmarks, e.g. a page, a concrete record or a quick link to the module. Added links are available both in the welcome page of the administration and in the system module Favourite. The last user-oriented option is help. Help module is planned for the future and should contain user-friendly instructions for basic tasks and operations in the system.

[Pages 19-38]