This guide is designed to advise you on the default roles and permissions, and how to make changes to suit your university processes.
This article explains how permissions come together to form a role which can be tailored to suit your workflows and your current set up. You can adjust the permissions in any role to make a change in processes whenever you wish. Simply ask for changes as part of your implementation. If you already have a Talis Aspire Reading List (TARL) tenancy then raise a support ticket in order to make a change or to discuss your options and requirements.
What is a permission?
A permission enables a user to perform actions and make changes on your TARL tenancy.
|Archive Lists||Allows the user to archive and delete lists. Active reviews must be completed in order to delete a list.|
|Delete Lists||Allows the user to delete lists.|
|Assign License||Allows users to assign a licence to a list.|
|Attach list to node||Allows users to attach a list to a node in the hierarchy, for instance to attach to a module.|
|Create Lists||Allows users to create new lists, including copying existing ones (this is scoped to tenancy only, a user with only a list publisher role for a specific list/s cannot create lists).|
|Edit Lists||Allows users to add and remove sections and items to the draft copy of the list, and change the list title and description.|
|Edit Nodes||Allows users to add new nodes, edit existing nodes and also attach lists to nodes to the hierarchy (this does not include the Hierarchy Upload function).|
|Grant any role||Allows the user to grant any role in the system (except System Administrator) to any other user.|
|Grant this role||Roles with this permission allow the user to grant the same role to other users in TARL.|
|Homepage Message||Allows the user to create a message on the Homepage, useful for making announcements quickly to users.|
|List Privacy Control||Allows the user to secure the list, so it can only be viewed by users signed into the system for that institution.|
|Publish Lists||Allows users to publish draft copy of the list.|
|Request Digitisation||Allows users to request a digitisation from the reading list.|
|Receive review requests by email||Any user with this permission will receive an email alert when a review is requested (this can now be overridden to go to just one or more email addresses of your choice ask for information from your support consultant).|
|Request Review||Allows users to request a library acquisitions review for the list (this can now be tailored to suit your preferred review workflow ask for information from your support consultant).|
|Request Rollover||Allows user to request a rollover of lists to be performed by the system.|
|Resource Metadata Refresh||Allows the user to run the background job to link books to the catalogue by doing an ISBN lookup.|
|Upload Hierarchy||Allows the user to upload a Hierarchy Update file, to update, add, and delete hierarchy nodes.|
|View Reviews/Acquisitions Data||Allows the user view the all reviews queue, perform a library acquisitions review.|
|View Reports||Allows the user to view and run reports.|
What is a role?
A role in TARL is a collection of permissions. Our advice is to think less about the role titles and more about the tasks you need a user to be able to perform and then pull that together in one or a combination of roles. More than one role can be held by a user in order to increase a user’s permission range i.e. List Creator and List Publisher, giving combined permission levels of both roles.
The table below shows the default settings for the roles on a new implementation. This can be changed at any point to suit your institutional needs. You can’t currently change the the name of the roles, but you can change the combination of permissions each role holds.
|Can Assign License||yes|
|Attach list to node||yes||yes||yes|
|Grant any role||yes||yes|
|Grant this role||yes||yes||yes||yes|
|List Privacy Control||yes|
|Receive review requests by email||yes|
|Resource Metadata Refresh||yes|
|View Reviews/Acquisitions data||yes||yes|
A common scenario is that a user holding the Library Acquisitions role may need to attach a list to a node and then publish it. These two permissions can be added to the Library Acquisitions role or the user can be given a second role on top of the Library Acquisitions role in order to do that task as well. Roles and their associated permissions can be tailored to suit your university's needs - to do this please raise a support ticket.
Revoking a role
Roles can be revoked on a user’s profile screen which is accessed via the All Users report, so if a user changes job role and no longer needs full system admin permissions, that role can be revoked and the user can be invited to a role that is more suitable to their new job role. See Revoke Roles.
Important points to note
- Role titles cannot be changed from the default titles.
- If a user is only given List Publisher role scoped at List level and not List Creator, they will not get the Create List permission enabled on their My Lists page. List Publisher role scoped at tenancy level will get Create List permission if enabled for that role as per the default settings.
- If a user is only given List Publisher, they can only invite users to be List Publisher for a single list.
- For each list created by a List Creator role, the creator will also inherit permissions of the List Publisher role scoped only to the created list.