For assistance, please send an e-mail to: websinanet@isprambiente.it
Naaya is a multilingual content management system. It is built as a set of core Zope products, to which additional Naaya-specific components can be added (e.g. Survey tool, Photo Gallery), as well as generic Zope products (e.g. RDF Calendar).
Naaya portals address the need to have the administration and content management operations done by non-technical people from the portal pages. The Managers can access the ZMI in order to make changes, but this requires some technical understanding and can result in errors. Therefore, Administrators and Contributors have folder-level and portal level administration pages which allow executing the operations most frequently requested.
All Open Source, including the components created for customers other than EEA.
The Naaya content consists of Folders, which can contain the following Naaya specific sub-objects:
Naaya HTML Document – HTML page that can contain images (folderish)
Naaya File – an object containing one single file for all languages, but multilingual metadata
Naaya Extended File – an object containing one file per language
Naaya Media File – an object containing a Flash file which is displayed using a Flash editor; along with multilingual subtitles; providing a converter is installed on the server, it is able to transform a movie in all common formats into Flash at upload or editing time
Naaya URL – an object containing an URL to an external page
Naaya Pointer – an object containing a reference to an internal page; when adding or editing such an object, the referred page can be chosen from a sitemap
Naaya Contact – an object containing data about individuals or organisations
Naaya News – a news item with an expiration data
Naaya Event – an object containing data about an event, for which the
Naaya Story – an object containing data on a timeless story, with the possibility to add images
Naaya GeoPoint – contains data about a location of a certain type; when the location is added or edited, the coordinates are calculated by the system based on the address, using a Yahoo API. The location types are defined at portal level and a Yahoo or Google map displays all locations at portal level with the possibility to filter by type of location
In the case of all types that contain files, the files are kept on the hard disk.
All Naaya content types have:
a common set of properties – metadata (e.g. title, description, release date, contributor);
a custom set of properties (e.g. location for events , expiration date for news);
a dynamic set of properties, which are are only relevant for one website and are defined by Managers for each portal, individually (e,g, CV for experts).
Since multiple Naaya portals can reside together on the same Zope server, dynamic properties of objects allow fulfilling the needs of each portal without impacting on the genericness of the software product.
Recently, the possibility to geo-code all content types has been added. For instance, there were requests to see events and contacts on the map. Now it is possibly to define for each Naaya portal which types of content will allow geo-coding.
At the time of writing this document, a new feature is about to become available: the properties schema for Naaya content types can be changed at portal level. This means that Administrators can decide how each property will be called, if it will be displayed or not and if its value will be chosen from a selection list or or have free input.
Aside from the generic content types, others have been built over the time for specific types of portals. For instance, SEMIDE portals include by default objects for “Funding source”, “Project ” and a more complex type of “Organisation”. Naaya portals have a Control Panel for content which allows to install/uninstall types of content available in the NaayaContent Zope product. This allows keeping individual instances of Naaya as simple as needed.
The Naaya publishing workflow for content is “hardcoded” into the product, because the need for another approach was never expressed by the users.
The states an item can be in are approved and pending . Pending content does not appear in the folder listing for regular users and is not found in searches. At submission time, the content is added as pending or approved depending on the type of user that submits it:
if the user has the “Naaya Publish Objects” permission (granted by default to Administrators and Managers), the item is approved
otherwise, the item is in a state of pending and can be later approved and again un-approved by Administrators and Managers using a form called “Basket of approvals”
Naaya content can be commented on by users if that particular item has the option “Open for comments” enabled. By default, Authenticated users can comment, but the security settings for the commenting can be changed.
Comments can be deleted by Administrators, but not changed.
If the email setting are filled in at portal level, notifications are send to the list of emails set there and to local folder Administrators when content is added in the portal. Additionally, email notifications can be send in case of errors encountered by end users while accessing the portal pages.
Naaya objects have an editing form which allows changing their properties with immediate effect to the users and also a versioning form which makes a copy of the object and allows repeated savings of that copy until the needed version is reached.
The version is closed when either of the “Save version” or “Discard changes” are pressed. While the version is edited, all users aside from the owner see the online version. When the version is saved, the existing online one is replaced by the new version and this one is deleted.
When a user starts a version, editing from other users is blocked until that version is closed.
By default, the folders display its title, the HTML description with links and images and the listing of its subobjects. It is possible to have a different view for individual folders. From the ZMI, a copy of the default folder index is made and Managers can edit the Page Template to change it.
The portal-level content management operations are:
setting the main sections of a the portal, which are folders that can be displayed in the standard header, in the chosen order. This allows quick access to the most important entry points
basket of approvals – listing of all pending items from the portal, with links to the corresponding folder-level basket of approvals
versions – a listing of all opened versions across the portal. Administrators can see and edit their own and discard others, if they for instance have left the job and forgot the versions opened
map settings – the API used, center of the map, level of zoom and other similar properties can be set for the map that displays geo-codable content published in the portal
Portal Administrators or local ones can execute the following operations at folder level:
users' management (add users and grant them local roles)
set a folder logo that will be displayed in that folder
configure the right portlets displayed in that folder
restrict the folder and its content for certain roles
set the sub-objects that can be added in that folder
approve/un-approve content
cut/copy/paste/delete items
add content
customise the feedback form that visitors call from that folder
change the order the contained items are showed in
edit the folder and, in particular, setting the option for users to apply for a Contributor or Administrator role for that folder
Each item of content can be added in one language and individually translated from its edit form. When a new language is added in the portal, all content receives that language version. When the content is migrated from one portal to another, it maintains all language versions.
If an item is not translated in one language and it is also not available in the portal default language, its id is shown, along with a message informing users what language version(s) are available for that item.
When an item is edited and a language version was marked wrongly (e.g. the content provided added an item in German and the adding language was English), it is possible to mark that version as being from another language (which corresponds to the English version being deleted and the German version being added in the previous example).
The properties Geographical coverage and Keywords common for all Naaya content can be freely entered by content managers or picked from glossaries or thesauri if this option is enabled at portal level.
Naaya has two additional products to support this facility, NaayaGlossary and NaayaThesaurus. They both allow import and export in SKOS format and translation of terms and themes.
Users' management – aside from the acl_users which is by default added in Naaya and that keeps an enhanced set of properties for each user, additional users sources can be used. In particular an interface was written for searching and assigning roles to LDAP users.
layout customisation
select the skin or colour schemes
change the portal logos, title, subtitle
edit the HTML text from the front page
content management (described above)
syndication - allows defining and managing local and remote channels in RSS/RDF and ATOM format
translation centre for the messages across the portal, with import/export in PO, XLIFF and CSV
Link checker configurable to search for broken links in any subset of properties of certain types of content
portlets' management – various types of portlets (e.g. lists of links, remote channels, HTML content) can be easily defined and arranged on the left side, front page or right side of the pages
All the components described below are Naaya objects that can be added either inside a Zope object or in a Naaya folder.
A forum contains discussion topics on certain themes. Each topic contains a description, on which users can post messages, either referring to that topic or in response to other messages.
Permissions are defined for adding topics, messages, managing topics and messages, etc., which allows tailoring any kind of open or closed forums.
The forum is not moderated, but Administrators can delete messages.
Notifications can be sent when messages are posted.
A photo gallery can contain albums, which contain photos, all described by metadata. Photos can be added either one by one or from a zip file. Visitors can download a subset of the photos in an album as zip.
A photo can be chosen as album cover. Administrators can fully manage this content. A search is made to find photos inside a gallery.
The navigation in an album can be made from the listing or to the next/previous photo. When displaying a photo, Administrators can rotate it in any direction.
Photos are displayed as thumbnails, but 6 sizes of thumbnails can be generated at first use and users can also download the original image.
The survey tool is a folderish object that can be added anywhere in a portal. It requires Administrators to define the questions one by one and choose their type:
simple text
longer text
file
date
matrix of questions with only one answer option on a row/culumn
matrix of questions with multiple answers on a row/column
single pick from a list of options (possibility for the respondents to add own option is available)
multiple piks from a list of options (possibility for the respondents to add own option is available)
etc.
The survey has a start and an end date, before and after which users cannot comment. The answers are available (to Administrators) one by one, with details about the respondent. Also, statistics are generated for each question in a tabular form, graphs, lists or pie-charts, using the Google API.
Respondents can receive a link to their answer by email.
This tool allows uploading a file for each portal language, on which users can comment:
freely, as overall comments
on each line, in which case case the PDF must contain line numbers
by answering guided questions previously defined by Administrators
by adding files in support to their answers
Email notifications can be sent when users respond to the consultation. There is a start and end date, before and after which users cannot comment anymore.
Statistics are automatically generated for the answers. In case more significant statistics are needed, Administrators can rate answers by various criteria, which will conduct to additional statistics.
This tool allows defining chapters like an online book, each chapter being divided by the system in paragraphs on which users can add comments. Administrators can merge the paragraphs (which can be images, objects, or other types of HTML tags), delete them and edit each one.
Visitors can see the text of each chapter with or without the comments.
A chat room can be added by Administrators and access can be granted to certain roles or individual users for it. When entering a chat room, users see who's participating to the chat and the chronological list of messages like in any other chat.
The history of a chat room is kept after the room is closed – access to it can be granted to a certain role of users.
When chatting in a room, private chat rooms can be opened for two users if there is a need for them to discuss separately.