Personal tools
Sections
You are here: Home Products Help Center OpenEngagement KMS 2.5 Overview
Document Actions

Overview

Note: This is the print view with all the Reference Manual pages on one page. The paginated version is available here, if you prefer that.

1. Purpose

The Knowledge Management System (KMS) is intended to provide a central repository for software, documents and other knowledge that is not specific to any one client, for a firm. Documents that are specific to one of a firm's clients would more likely go in the DMS.

The KMS may be used to store such information as: holiday & vacation schedules, office phone extensions and email lists, office policies, information about the accounting industry, government regulations, or industry-specific information. This content may be uploaded to the KMS or entered directly, through an editor in the web browser.

The KMS is intended primarily to store knowledge that is viewable by a firm's staff, but it is possible to include some information which is viewable by anyone. That is, firms may make some content available to users who are not logged in and who do not necessarily have user accounts. Doing this, firms may provide some content that is viewable by clients or potential clients.

 

 

2. Using the KMS with the DMS

The KMS is intended to compliment the DMS, and so the OpenEngagement CMS includes, by default, one DMS Area and one KMS Area. This is generally the most appropriate configuration for most firms, however some firms may wish to have multiple DMS Areas and/or KMS Areas within a single site. This may be done to simplify the site organization or the site security system.

Some firms who self-host may wish to have the DMS and KMS on separate servers, or to have two instances of the KMS on two different servers, for example one inside and one outside their network firewall. However, having both the DMS and KMS together provides, in most cases, the most convenient and easy to manage single repository for all content.

The user accounts created in the CMS will be used by both the DMS and KMS, assuming they are on the same server. As well, the site-wide roles given to users will apply equally to the DMS and KMS, though some roles will have no meaning within the KMS.

Most features of the CMS, such as the Site Map, Role Map, administrator contact page, the authors' pages, the Content History, Smart Folders, and so on include the DMS and KMS equally and treat both products in the same manner, so the DMS and KMS are in some respects simply two or more Areas storing the firm's content.

 

 

3. Organization of the KMS

The KMS is organized in a hierarchical manner, though Smart Folders may also be used to provide alternative hierarchies. The KMS uses Folders and other content types similar to Folders to organize the KMS. The hierarchy provides a tree-structure, similar to the Windows files system and to the DMS. This provides a simple means to navigate to specific object, and also provides the structure for the security system. Users are given roles at any point in the tree (though roles may also be assigned to users site-wide) and these roles apply to those users from that point down the tree. For example, if a user is given the Reader role on a certain folder, they will inherit that role on all objects within that folder, even those many levels deep within the Folder.

As well as Folders, the KMS provides a number of object types that are designed specifically to contain a specific type of content: Software Sections, Reference Manual Sections, Tutorial Sections, How-to Sections, FAQ Sections, Glossary Sections, and Video Sections. As is suggested, Reference Manual Sections store only Reference Manuals, Tutorial Sections store only Tutorials and so on. It is, though, possible to have multiple, for example, Reference Manual Sections, where firms wish to organize their Reference Manuals by topic, or wish to assign different users roles in different sections.

 

 

4. Working with the Quick Upload

The Go-Between does not interact with the KMS, as the Go-Between is concerned solely with Engagements, and Engagements may be stored only within the DMS. The KMS does, however, interact with OpenEngagement Quick Upload.

Quick Upload may be used to upload Engagements to the DMS, and Files or Images to either the DMS or KMS. Files and Images may be added to the KMS Area itself, or to any Folder within the KMS.

 

 

5. Views

Most content types in the KMS allow five views:

  • Summary View
  • Tabular View
  • Thumbnail View
  • Standard View
  • Dashboard View

The view is modified by selecting the Display menu on the View or Contents tab. Generally, the Contents tab will use the Tabular View and the View tab will use the Dashboard View, but this is not necessary.

The Summary View, Tabular View, Thumbnail View and Standard View are all similar, but do have different looks. Each of these lists the items immediately within the current location.

The Dashboard view contains a series of boxes. There is one box for the current location, as well as one box for each item within the current location that contains real content (that is, a Page, Image, File, Link, Tutorial, FAQ, Glossary Definition, How-to, Reference Manual or Video, and not simply another containers, such as a Folder, Reference Manual Section, Tutorial Section etc.). Each box will list the real content within that item, regardless of how far down the site tree those items are.

The CMS root also provides views, though the Dashboard View is available only within the KMS. The CMS root also allows users to set a given item as the default view for the root. This, in effect, sets the home page for the site. The OpenEngagement CMS ships with one page which is set by default as the default display item at the root. Users may modify this page or add additional Pages and set one of these as the default item.

 

 

6. Email Notifications

Each item in the KMS has an option to notify users when the item changes. When this checkbox is checked, the Readers, Preparers and Managers assigned to that item will be sent an email. They will not be assigned an email if any item within it changes. For example, if the checkbox is checked for a Tutorial Section, users will be emailed when the Tutorial Section itself changes, but not when the Tutorials within it change. This is to prevent users from receiving excessive quantities of email.