Author Groups
Currently, all Authors, regardless of Group, will have the ability to modify any Template within the Institution for ease of template creation and modification.
Admin
Introduction
Who are the Admins?
The Admins create various classes of users, whether it be Authors, who create templates or end Users who create documents using the templates. They set various permissions individually or via groups so that sharing of the templates, projects or other resources are done in a secure and efficient manner. Typically, an institution's IT personnel will be the Admin.
Comparing Admin vs. Author
The Admins, like the Authors, have the ability to create Templates and give access to such Templates to other groups or individual users. Unlike Authors, however, Admin also have the power to create and disable Users, and they are also able to delete and disable Templates. Authors do not manage Users and Authors do not have permission to delete Templates, even though they have authority to create them.
Disabling vs. Deleting Templates
The main difference between Disabling a Template is that Disabling will permit existing projects to work, whereas deleting a Template will prevent the project from working (there are safeguards in place, such as the system not letting the admin to delete a variable if it is in use). The Disabling feature is useful when there is a new version of the Project Template available, when you want to encourage the Users to use the new version of the Project Template, while allowing older projects that still use older version of the Project Template to still function.
Managing Users
Creating Users
To create a new User, click on the left hand-side of the dashboard and click on Users --> New User. Even though the term "User" is used, you can create either Author or User as its Role. Username should be an email, as that is the unique identifier of the User.
A user can have multiple attributes to it, such as: Delete Access Level (Maximum permits the user to delete any projects; Normal permits the user to delete only his/her projects; Minimum does not permit deletion); URL based login permission; Initial View (Projects view vs. Calendar view); Calendar Access (Master permits viewing of all events; Individual permits viewing only his/her calendar); Default Mode (Clean vs. Redline); and the Calendar Color associated with the user.
Managing Groups
Groups make assignment of privileges easy by allowing granting permissions to a larger group of individuals. If there were no Groups, then the Admin would have to grant privileges and permissions one-by-one, which would be a time consuming process.
There are two types of access within User Groups:
- Template Access: This privilege, which is always turned on, allows a User within the Group to access Project Templates that have been made available to the Group.
- Shared Project Access: This privilege, which can be turned on or off, allows Users within this Group to access projects created by other member Users of the Group.
The difference is that if you assign a Role Group to a User or Author, it will be given privileges associated with that group; namely the ability to modify a Project Template, in the case of an Author Group, and the ability to use a Project Template, in the case of a User Group. Role groups are a convenient tool to organize groups of Authors and Users, and permits easy management of the accounts.
Alternatively, if you assign an Institution Group (or be assigned to an Institution Group), your privileges of the Project Template would be limited within that domain. Institution Groups follow the parent entity to its children entity. If, for example, an Admin account was created with Institution Group of "Payroll Department", all of the Authors and Users created by that Admin would belong to Payroll Department, and all of that Admin, Author and Users will have access limited to assets and resources belonging to the Payroll Department. This Institutional Group provides strong access controls by asserting information segregation consistent with institutional policy.
Login via URL
User Groups are explained in detail below. The URL Login toggle is useful for when you would like the User or Author to be able to login via URL sent over via link, via email or messaging service. The default behavior is to prevent this practice as username and password becomes visible in the URL, but there are times when you would like a quick feedback from a potential customer, who might otherwise not be bothered to create an account. This feature is also helpful for demo purposes. To make the link, use the following syntax:
http://[domain.com]/auth?user=[username@example.com]&pass=[password]URL Login
Use extreme care if you are using this method to permit users to login. There is a reason why default behavior is to prevent this practice. Assume that the account's login and password will be made public and never store any sensitive information in that account.
Import/Export Users
It is easy to import a number of users at once. Simply click "Import" button and upload a Comma Separated Values (CSV) file.
Fields are:Email,Username,Role,Institutions,UserGroups,Status,UrlLogin,Password
Sample data:
test@test.com,test,user,Institution1,,active,FALSE,
To get a properly formatted CSV, it is easier to simply export an existing data and use that as the basis to create new CSV. To export the user list, simply press "Export" and it will be prompted for download. Password will not be exported for security reasons.
Opening CSV File
Most computers with Microsoft Excel will open the CSV file with Excel, but please note that it has the potential to corrupt the CSV file, even if you save it as CSV. To ensure greatest compatibility, consider using text based program, or at least review the CSV file generated by Excel with a text program.
Managing Templates
Although both Author and Admin can create various Templates that ultimately congregate into the Project Template, only Admin has the authority to delete or disable Templates.
With great powers come great responsibilities. Deleting templates that are being used can crash the app, as the expected information is suddenly not found. Therefore, safeguards are in place: in order to delete a Term Template, it must not be used in any Provision Template. And to delete a Provision Template, it must not have been used in any Document Template. And to delete a Document Template, it must not have been used in any Project Template. And to delete a Project Template, it must not have been used by any User to create a project. Therefore, to thoroughly delete a Project Template, you must make sure that no User has created a document with it.
The above limitation may not settle with some, but it should be noted that the Template maybe modified in any way shape or form by both the Admin and Author. If some sensitive information has been included, such information could be deleted. In addition, there is also the ability to Disable the template. Disabling a Template (whether it be Project Template or Term Template, etc.) prevents it from being used for a new higher-tier template (so if a Document Template is disabled, it will not be available to create a Project Template) and if a Project Template is disabled, it will not be usable by Users to create a new document (but it will not affect existing documents created with that Project Template).
Disabling the Template is a good option if there are multiple revisions or versions of the Template. Admin can roll out a new version of the Project Template and disable the old Project Template; then all new user projects will be created using the latest version (which addresses a significant version control problem). This makes it easy to let users know that the Template had been deprecated.
Creating Templates
Both Admin and Authors have the ability to create Templates. The details of Template Creation are covered in the Author page.