How Permissions Work

By default, folders and components, such as topics and publications, do not have any permissions in place. Any Paligo author can view them and edit them. By using the permissions feature, you can restrict access to the editing features. When you restrict access to a folder, the permissions also affect who can edit the items inside the folders.

The permissions are applied from the top down, in cascading order. When a user attempts to edit a component, Paligo checks to see if the folder that contains the component has permissions:

The following sections explain how the permissions affect access in the various possible scenarios.

No Permissions Set

By default, when you add a new folder or a component such as a publication or topic, these items have no permissions in place. This means that any Paligo author can edit them.

It works like this:

• Folder:

  No permissions set.

• Items inside folder:

  No permissions set.

Result:

Any Paligo author can edit the folder and the components inside the folder. There are no permissions in place to restrict the folder or the components.

Permissions Set on Folder

If you apply permissions to a folder, those permissions apply to the folder and also the components inside the folder.

To show how this works, we will use the name "Curtis" for the person who created the folder and components (the "owner") and "Product Team" as the name of a group of users. This group has members called "Dani", "Martin", and "Jo".

The permissions are set up like this:

• Folder:

  The folder has these permissions in place:

  Everyone can view, only some can edit.

  Users with permission to edit: Curtis (owner), product team group.

• Components inside folder:

  The components inside the folder do not have any permissions in place.

Result:

The only people that can edit the folder or any of the components inside it are Curtis (owner) and the members of the product team. All other users will be able to view the folder and components, but cannot edit them.

Permissions Set on Folder and Components Inside Folder

You can apply permissions to a folder and then add additional permissions to the components inside the folder.

But note that there is a cascading relationship between the permissions of the folder and the permissions of the items inside it. The permissions for the items can only be a subset of the permissions for the parent folder, you cannot apply completely different (and conflicting) permissions.

To show how this works, we will use the name "Curtis" for the person who applies the permissions (the "owner") and "Product Team" as the name of a group of users. This group has members called "Dani", "Martin", and "Jo".

• Folder:

  The folder has these permissions in place:

  Everyone can view, only some can edit.

  Users with permission to edit: Curtis (owner), product team group.

• Topic A inside folder:

  Topic A has no permissions set. It inherits the permissions from the parent folder.

• Topic B inside folder:

  Topic B has its own permissions set to:

  Everyone can view, only some can edit.

  Users with permission to edit: Curtis (owner), Dani.

• Topic C inside folder:

  Topic C has no permissions set. It inherits the permissions from the parent folder.

Result:

Curtis (owner) and all of the members of the product team group can edit the folder, Topic A, and Topic C.

Curtis (owner) and Dani can edit Topic B. The other members of the product team group cannot edit Topic B. They have access to the folder, but are excluded from having access to Topic B by the permissions set for Topic B.

Notice how the restrictions are applied downwards (cascading). To edit an item in a folder, a user must also have permission to edit the parent folder. (The only exception to this rule is if the parent folder has no permissions set).

You can use permissions to restrict user access to editing features for components, such as topics and publications. This can be useful when you have certain topics that should only be worked on by particular people or groups of people. For example, let's say you have a topic about thermodynamics and you have a writer named Jo who is a specialist in that subject. You could use permissions to make sure that Jo is the only person who can edit the "thermodynamics" topic.

When you apply permissions to individual components, it is important to understand that permissions are cascading. You can only give a component permissions that are a subset of the permissions for the "parent" folder (the folder that contains the components).

There is an example of how the folder and item permissions work in Permissions for Folders.

To learn how to apply permissions to a component, see Set Up Permissions.

If you have topics that contain other topics as components, the permissions still apply. You can only edit or delete the topics that you have permission to edit, irrespective of where those topics are used.

For example, let's say you have a "Specifications" topic and it contains a "Battery Specifications" topic as a component (so "Battery Specifications" is a subsection).

You have permission to edit the "Specifications" topic, but not the "Battery Specifications" topic. This means that you can:

Content reuse is one of Paligo's most important features, so it is important to understand how permissions may affect it. For the most part, you can only make changes to content that you have permission to edit.

But there are two exceptions: reused text fragments and variables. With these, it is possible to make changes to topics that you do not have permission to edit directly.

To learn about the various types of content reuse, see: About Reusing Content.

You can create a branch of a publication or topic even if you do not have the Edit permission. Once you have created a branch, that branch is regarded as new content and so has no permissions in place.

With a branch, you can edit most of the content without affecting the original version. This is because most of the text content in a branch is given a new ID, so it is unique and separate to the original version of the same text. But there is one exception — reused text fragments. If the original version contained reused text fragments then the branch will also contain the same reused text fragments. If you change those, the changes you make will affect the text fragments wherever they are used.

To merge a branch back into the original version (the source of the branch), you need to have the Edit permission for the original version. If you do not have the Edit permission, the merge option is unavailable. This is to prevent users from being able to make changes to topics that they should not be able to edit.

To learn about using branches, see Branching.

Users that do not have permission to edit a folder, topic, or publication can still view those items and make copies of them. For each copy, Paligo will:

The copy is completely separate to the original, with the exception of any reused content. To learn more about copies, see Duplicate Topics and Duplicate Publications.

The permissions feature affects your Paligo users' ability to change the workflow status of topics.

If a user has permission to edit a publication or topic, they can change the status, for example, change a topic from "Work in Progress" to "In Review".

If a user does not have permission to edit, they cannot change the workflow status.

To learn about workflow status, see Workflow Status.

The permissions feature can affect whether a user can export Paligo content and also import external content into Paligo. Access to the import feature is dependent on whether you have the edit permission:

To learn how to apply permissions, see Set Up Permissions.

To learn how to import and export content, see Use the Import Wizard and Export and Backup to XML.

If you prevent a user or group from being able to edit a component (publication, topic, admonition, etc.), they will still be able to access most of the translation features for that component. For example, they will still be able to:

A user who does not have the edit permission for a publication or topic can:

But they cannot:

If Paligo displays this message:

If you try to change languages or make changes to something that you do not have the permission to edit, Paligo displays this message:

Some documents cannot be updated

Below the message, Paligo displays a list of the documents you cannot edit due to your permissions. To change the permissions (see Set Up Permissions).

To learn more about translating Paligo content, see About Translating.