help.sitevision.se always refers to the latest version of Sitevision
Good to know about permissions
To set permissions, SiteVision must be associated with a directory service. Management of permissions and roles can be done for a single page/image/file or for an entire branch. The Permissions tab is located under properties for each page. Permissions assign users different roles that give them different permissions on the website.
Good to know about permissions
- Permission changes do not need to be published but only saved. Depending on the change you make to permissions, you must either refresh the page (for read permissions) or go online (for edit permissions).
- Roles are global per website. This means that they apply to the entire website. It does not matter if you change them on a sub-page or on the website, the change is applied throughout.
- The permissions for modules only apply to add new modules. If a user only has text module permissions, they can still access and edit or copy another module that is on a page that the user has access to.
- Permissions are inherited from the website. If the website is public, templates, image archives and file archives will also be public.
- If a page is made public, login is not required to read the page.
- Permissions are inherited by the underlying pages. To break an inheritance, untick the Allow inheritance of permissions from above box. No permissions will then be inherited from the overlying pages.
- You can set up an IP address range to have read permissions without logging into a non-public website. This is included in the licenses for Portal and Enterprise, but is an add-on to the CMS license.
- Survey and Booking module have their own permissions that are set up in each module.
- There are also permissions on website colours and style sheets. These are good to set so that the editors do not see the colours and style sheets that they may not use.
Permissions on the website
Remember that permissions are inherited. Adding a user to the website inherits the rights to all underlying content including templates, file archives, and image archives. You can break an inheritance by unticking "Allow inheritance of permissions from above" or unticking one or more roles for affected groups/users.
Permissions on templates
Permissions on templates are inherited from the website. If the website is public the templates are also public.
Keep in mind that it can be useful to permissions protect the folder with sub-templates, as other templates are based on them. You can set the sub-template folder not to be public and only give the people who have the right to modify the templates access to it. Untick the "Allow inheritance of permissions from above" box, and then add the users who will be allowed to modify the sub-templates.
If you have an intranet, this is not public. You must give users permission to the templates. This is easiest to do by uploading the entire root of the directory service (where all users are located) and giving them read permissions.
Permissions in image archive
Permissions on the image archive are inherited from the website. So if the website is public, the image archive is also public.
If you want to protect a folder in the image archive, untick that it is public and add only those people who will be able to access the folder. The image archive shows the image, but with a lock on. No one without permission can copy or delete the image. However, it can be used.
If an image is, however, "secret" it is safest to put the image in the archive Page images and instead permissions protect the page. Set the page to not be public, and allow those who have permission to access the page. Should the user have the right to add an image, they must have write permissions to the image/folder, and should the user also be able to delete an image, they must have the Delete right on the image/folder.
Permissions in file archive
If you want to protect a folder in the file archive, untick that it is public and add only those people who will be able to access the folder. The name of the file is visible but does not have the user permission, they cannot see the size of the file, neither copy, delete, or use the file.
External search engines do not search folders that are not public. Our internal search engine searches everything but only gives a hit on what the user has rights to.
Extended permission control
It is also possible to use third-party products for permission controls such as Portwise and Mobility Guard. It is then not sufficient to belong to a particular role in order to obtain permissions, other requirements can also be set. For example, the way the user logs in (SMS, box) or the user is within a specific IP number.
This function requires "Manage permissions" permission
The page published: