From an author’s perspective the main takeaways from the diagram above are:
The Project provides many customisations that are hidden from the Author and from this point of view it is to simply provide hierarchy and structure for organising Groups.
The Project is usually represented as a company, but it all depends on the what that is required.
A key concept of a Group is that it restricts access to content, such as Documents and Comments to a list of Members.
Within the Group, Members can have different levels of permission (functionality) but all Members see the same content. In other words, there are no additional privacy settings inside a Group.
Groups belong to a Project and inherit many characteristics, such as Labels, document templates and publish scripts from the project.
A Group is a working space that allows users to collaborate on documents and exchange comments.
Everyone in in a Group are Members with a Role. To manage other users, a Group Member must be a Manager or higher. Roles considered higher are Moderator, Approver (when these two roles are the same person it is expressed as (Moderator & Approver) and Administrator.
The Role of a Member is set by the Manager of the Group except for the Administrator Role which can only be granted by another Administrator.
Each Role is associated with a set of permissions within a Group or Project. Members can have different Roles in different Groups.
Guest Role Permissions
Reviewer Role Permissions
Contributor Role Permissions
Manager Role Permissions
Moderator Role Permissions
Approver Role Permissions
Moderator and Approver Role Permissions
A Group contains a collection of Documents that are organised in a table of contents and assembled by cross-references that complete the framework for a tekAuthor Publication.
tekAuthor is bundled with three (3) distinct Document Types, they are:
A Content Document contains Fragments that then contains data rich content.
Tasks usually evolve from a Comment and have additional configurable workflow properties. The default properties include:
They allow existing Comments to be edited so that they can potentially become Tasks.
For more information please refer to Tasks.
Document Types are used to customise the structure, creation, editing, labeling, importing, exporting, publishing, CSS style and validation of documents. They act as a template for Documents.
Each Project in tekAuthor automatically includes three (3) distinct Document Types, they are:
The basic steps for using the Document Types when setting up a Publication are:
For more information refer to Publication Setup.
Labels are a convenient mechanism for adding semantics to tekAuthor artifacts. They are divided into two broad categories:
The following table summarizes the different types of labels used in tekAuthor:
|inline content inside a block of text
|blocks of text
|a document fragment
|a comment or task
|a document upload
|a document creation
|a document version
|a note on a document edit
As an author the two (2) label types commonly used are:
History is a feature that refers to previously saved versions of a Document. The History is kept at the fragment level and displays a sequence of edits that can be used to track changes. There is also a document history page that displays events related to the Document.
For more information refer to Fragments.
A Version is a “named” snapshot of a single Document. A minor or major version can be applied and must have a name which can be:
The XLink architecture means that content is only ever superseded, never discarded. One way to think of a version, is that the version XLink acts as a ‘bookmark’ that provides a named address for the specific state of a Document. Comparisons do not have to be between consecutive document versions, they can be any two versions.
Document versions can be categorised as minor or major. This allows for the flexible management and release of documents. For example, major versions may be used as the trigger to publish externally but minor versions may signify an incrementing workflow status internally.
A particular type of XLink (a note) attached to a specific change in a Fragment (an edit).
The purpose of an Edit Note is to explain the reason for the change, i.e. typographical.
It conveniently displays on right-hand side of edited fragment and in the fragment change history.
Members can validate a Document using Schematron. Validation of Documents need to be setup by the tekAuthor Administrator.