2 – Policies parameters

Policies parameters allow you to decide factors affecting what Full and ServicePoint users see and how they operate with their RefTracker signons.

2.0 Login as General when licence exceeded: This parameter allows your organisation to choose whether full users will be offered the option to sign in as a general user if all Full licences are in use, but Service Point licences are available. 
The default for this parameter is Yes.  Here is what staff see if this parameter is set to Yes and all Full licences are in use, but Service Point licences are available.  If they use the provided link they will be logged in but only have General user capabilities – i.e. they can work on answers but not correspond with the client.  If they need to close the question it will go to their Work reviewer to be sent out

If this parameter is set to No, the “Continue login with general user permissions” link will not be offered.  You will want to use this option if your staff find general use confusing, or if your Service Point licences are all allocated to physical locations so you do not want these licences being used for other purposes.

2.3 Login timeout: This is the amount of time in minutes that a RefTracker staff session can be inactive before it is automatically logged out.  Its primary role is to close sessions that have been unintentionally lost because the browser running them was closed.  This parameter uses a Microsoft function to forcibly close down the session to the server and happens at a level that has no visibility to whether any unsaved data has been left open on the screen.  So, although you can reduce this time period if you are concerned about security, please be aware that if a user has left unsaved data on there screen for this period of time, their data will be lost when the idle session is automatically closed.

If you need to manage a shortage of licences, the best way is to obtain some more licences, but, in the absence of that, RefTracker will automatically manage your licence usage.  If someone tries to log in when there are no more available licences, RefTracker sends your Active system administrator an email advising who is trying to log in and providing a link so the administrator can easily go directly to the RefTracker Concurrent users screen and choose to close another user’s session (so the new user can get in).  The Concurrent users screen provides helpful information about how long since each logged in session has been used so you can choose the session that is most likely unused.  Importantly, the Concurrent users screen session end function is completely controlled by RefTracker.  The user whose session is chosen to be ended WILL be able to save what is currently on their screen without losing anything.  When the user whose session is ended next clicks Submit, what is on their screen WILL BE SAVED, but they will then see a log in screen that explains they have been closed down by the administrator but may want to try logging in again.

2.4 Attachment delete type: Choose whether removing a Private attachment from a Question (as provided for by the “Manage attachments” functions) will result in the attachment being completely deleted from the question, or simply dropped from the list of currently applicable attachments (removed). The default is Delete as it will be most appropriate for most customers.
Delete ensures that viruses are completely removed and that copyright obligations are extinguished because the attachment is completely Deleted.  The History will show that the attachment was added, but the attachments name will not be clickable (as there is no copy of the file in RefTracker any more).
When attachments are only Removed, they no longer show as a current Question or Answer attachment, but, in the History, you can still see that the attachment was previously attached and if you click on the History entry you will still be able to see contents of that attachment. Note that Public attachments are intended to be used in more than one question, and so they are only ever Removed from the list of currently applicable attachments, they are never Deleted. If you need to delete a Public attachment go to System>Utilities>Administration utilities>File upload/Download.
A third option, Destroy, not only deletes the attachment but removes any notes about it from the History.

2.7 Maximum attachment size staff (MB): Determines the maximum individual file size that staff can upload to RefTracker.  Default is 50Mb.  The maximum value that can be set here is controlled by the maxRequestLength entry in the RefTracker web.config file.  You can choose a lower value if you are concerned about the time to upload a file of this size.  Parameter 8.5 will ensure that, even if the client’s email system cannot receive a file of this size, they will still have access to it via a hyperlink.

If your clients are all on your Intranet (as some special libraries do), you may want to try making a web enabled directory available for your library staff to save very large files into.  They can then quote the URL of the file in that local web enabled directory, in RefTracker, instead of handling it as an attachment. This approach has at least two important advantages – staff do not have to wait for these very large files to be uploaded across the Internet to RefTracker, saving them time, and, the very large attachments do not take up space in mail boxes or overload email spam filters.

If you have external clients, you might want to consider using a large file transfer service like WeTransfer.  If WeTransfer (or a similar service) is set up to send its confirmation emails to the RefTracker service email address, they will be detected as “unable to be applied as an update”, but the email RefTracker sends to Parameter 8.3 to advise this provides a ReSubmit function that allows the RefTracker question number (that will appear in the body of the email from WeTransfer), to be entered and the WeTransfer email resubmitted as an update.  It will then be added to the relevant RefTracker question history as a record of the file having been delivered to the client via the WeTransfer style large file transfer service. 

2.8 Maximum attachment size client (MB): Determines the maximum individual file size that client’s can upload to RefTracker via client interface forms, or through email importing.  Default is 20Mb.  The maximum value that can be set here is controlled by the maxRequestLength entry in the RefTracker web.config file. The lower value for client’s is recommended to limit frustration with the time to upload the file, and importantly, to remove the opportunity for mischievous loading of large files by spammers.

2.9 Maximum attachments per upload (client): Specifies the maximum number of files that a client interface user can add to a request at one time.
This is a security measure designed to mitigated the risk that a malicious end user might decide to upload a very large number of files with the intention of creating disk space and bandwidth usage issues.  They can only add one file at a time, but they can add a total number of files as defined in this parameter in any one use of the attachment function.  It is true that a user could enter a request with the maximum number of files and then use the Amend request function to add another maximum number of files, but this parameter means that adding a very large number of files will become too cumbersome for the malicious user to pursue.
This limit does not impact on the number of files that staff can upload to a request, or the number of files that staff can concurrently drag and drop into the request.
Implementation hint: The default value for this new parameter 2.9 is 5 which is quite generous.  You might want to reduce (or increase) this number.

2.11 Change password: This parameter allows the user level at which users will be offered the opportunity to change their own password in My preferences, to be set. The default value allows all Regular users and above to change their own passwords. You should not allow passwords to be changed for any levels of users for which you provide shared signons. If you are enforcing regular password changes (parameter 2.31) you should set this parameter as low as practically possible to limit the number of passwords that the system administrator will need to maintain.

2.12 Minute intervals: This parameter determines the values that will be offered in drop down boxes giving time options e.g. Last useful date. Objective response dates will also be rounded down to the closest minute interval. e.g. 9:00, 9:05, 9:10 etc. if the minute intervals are 5 minutes. Note that parameter 3.10 determines whether these times are displayed in 12 or 24 hour clock format.

2.13 Target date: This parameter allows you to decide how target date will be calculated for your library. “Target date” is the date by which the system indicates a question should be responded to. This parameter provides three options:

•  Earliest (of objective response date and last useful date): This is the default setting, and is the way in which target date was set prior to this release. Under this setting the system compares any Last useful date supplied in the Request form, with the objective response date (calculated as received date plus objective response time specified in the request form used to accept this question), and sets the Target date to the earlier of these two. This setting is most commonly used by all types of libraries.
• Last useful date Under this setting the system uses the Last useful date supplied in the Request form as the Target date. If a last useful date has not been supplied, it will use the Objective response date (calculated as received date plus objective response time specified in the Request form used to accept this question). This setting is most commonly used by special libraries with long research times who negotiate the expected time for response with the client and enter it in the last useful date (either in the Request forms when the question is entered, or at a later time using the Change screen).
• Objective response date Under this setting the system uses the Objective response date (calculated as received date plus objective response time specified in the request form used to accept this question) as the Target date. Last useful date is not taken into account. This setting is most likely to be used by public/state libraries whose response time policies do not allow for consideration of client’s last useful dates. If your library chooses to use this option, then you should not offer the option to specify a Last useful date in the request forms that your library designs.Note that the “Display target date” option in the Request forms Options page determines whether the Target response date information is displayed in the client confirmation screen and email. It may also be useful to consider your setting for “Display target date” in each Request form if you are considering a change to this parameter. If you have set all your Request forms so that “display target date” is set to No so that Target response dates are not shown to clients, your setting for this parameter 2.12 will only effect the Target date shown to your staff.  2.18 First day of week: This parameter determines the first day of the week for the weekly search and report options.  The default start day is Sunday.  If your week starts on any other day of the week, change it here. 2.19 Financial year start: This parameter determines the first month of your financial year.  The default value is July. If your financial year starts on any other month of the year, change it here.  A calendar year reporting option already exists, so, if your financial year is the same as a calendar year, choosing January here will result in the “This financial year” and “Last financial year” searching and reporting options not being offered.

2.14 Reminder – active days: Regarding the Reminders and holds functionality, reminders will only be calculated to be sent on the days selected in this parameter.  If the calculated date is not on a day that is ticked here, the date will be incremented by one day until a selected day of the week is found.
2.15 Reminders – shoulder period: Also regarding the Reminders and holds functionality, because a reminder sent at or after your closing time is of little use, and similarly reminders set at or before opening time won’t get immediate attention, the system uses a shoulder period – notices will be sent parameter 2.15 minutes before closing time, or after opening time for that request’s staff location.

2.20 Log questions views: Some customers dealing with questions of a private or secure nature need to know who has viewed that particular question and/or answer (Parliamentary libraries need to do this, for example). This parameter 2.20 “Log question views” should be set to Yes only if you need to record this extra level of activity. When this parameter is set to Yes, a “Views” history record showing who viewed the record and when is created whenever a staff member views this question/answer record. Any use of any screen that allows the question text to be seen will be recorded which means that “Views” records are created for every question that appears in a search results screen, as well as uses of screens specific to that question such as Answer, Record time, Qprint, and many more. To minimise the number of View records, a View record is only created if the question has changed since the last time it was recorded that this staff member viewed this question. Views history records are only available for questions viewed when parameter 2.20 is set to Yes, and even then, do not show in the History screen by default – to see the Views records, tick the “Views” option under “Individual event filter” in the History screen for that question.Note that, in order to ensure that ALL Views have been recorded, this parameter can only be changed by contacting Altarama.

2.21 Change staff location on reallocation: Some organisations want to implement a policy whereby questions are automatically reclassified so that the Staff location of the question reflects the Staff location of the staff member to whom a question in being reallocated.
Selecting “No” here will mean that there is no automatic change of Staff location on reallocation.
Selecting “Yes” will result in the Staff location always being changed to that of the Staff member that the question is being allocated or reallocated to. You will select “Yes” if you always want the staff location of a question to reflect that of the staff member working on it, even if they are from a different location to the one that originally owned the question.  You will use this option when your staff work in teams.  When you select “Yes” here, staff choosing to Reallocate back to the Pool of unallocated questions will see a Staff location field appear directly below the Pool tick box, showing the current Staff location and allowing another to be selected.  This function allows staff to Reallocate to another team/location without having to select a specific member of that team/location. 

2.24 Update journal for closed questions: Set this parameter to “Yes” if you allow time and cost journals to be added to questions after they have been closed. Set to “No” to ensure time and cost journals are not added after questions are closed (Record time and Record cost will not appear in the Actions menu for closed questions.

2.25 Backdate cut-off: If you operate under strict monthly reporting periods, as is common for customers that bill, you will not want staff entering new questions, or journals (time or costs), or closing questions for a reporting period after the statistics have been taken off for that period. Customers who use the Time used field or who use the Post date function should consider implementing this parameter.
The value entered in this parameter should be the last day of the following month on which journals and new questions can continue to be entered, or questions can still be closed, for dates in the previous month – if you report monthly you may want to set this parameter to 28th day of the month.
The default value for this parameter is “0” which means that journals and new questions can be entered for any time in the past life of your RefTracker system.
To force timely entry of time and cost information (such as when this information has been transferred to a billing system) Parameter 2.24 and 2.25 are often used together to prevent journals being added to closed questions, and prevent journals from being added more than X days after the end of the month.

2.26 Allocation sort: The question Allocation regime allows questions to be automatically allocated to staff one an even distribution basis. The Allocation regime select the staff member to whom the question will be allocated by:firstly discounting all staff who have their Availability set to No, then discounting all staff who are not at the Location, or with the Request type, that you choose in Allocation type,then discounting all staff who do not fit the Allocation method that you have chosen (the levels of staff to be taken into account),then retaining only the staff members currently allocated the lowest number of questions.As there may still be more than one staff member in contention, the final selection criteria is that the question will be allocated to the staff member in this remaining group for whom the most time has elapsed since they were last allocated a question.  Parameter 2.26 specifies that the last two steps of this selection process are “count then date”. Should you need another option please contact Altarama.

2.29 Logoff delay: When the “Prompt for Availability” function is selected in a user signon (see the “Answering preferences” tab of each user’s signon), the prompt that advises the user of their current Availability and allows them to change it before their log off is completed, displays for the number of seconds selected here (default is 5 seconds).  This parameter works system wide so you need to set it to suit your slowest users – increase it if they need more time to decide whether an availability change is required.

2.40 HTML data entry (staff pages): This parameter determines whether HTML can be used when entering data in the RefTracker staff interface.  The staff interface requires a valid login for access so its users are trusted and use of HTML is allowed by the default value for this parameter.  Customers should not need to change this parameter, but if you do,, please contact Altarama to have the change made for you.

2.41 HTML data entry (client pages): The RefTracker client interface is open to all to use so that there are no barriers that might discourage genuine users.  This means that we need to take special precautions to discourage unwanted users like hackers and to prevent all opportunities for their dangerous activities.  One of these precautions is that, by default, the RefTracker client interface prevents submission of HTML, as the HTML might be malicious code.

An important exception to this is the Question field, which is specially set up to allow HTML and to present it to RefTracker in an encoded fashion that prevents it from ever being able to be executed.  Most systems are also set up to allow HTML in client correspondence screens.

However there are instances where customers want their clients to be able to provide HTML in any request form field (not just the Question field), and other instances where secure organisations want to prevent it entirely.

This parameter determines whether HTML can be used when entering data in the RefTracker client interface. Choose the most appropriate value for this parameter given the security policies of your organisation.  Because of the security implications of this setting, especially for other users of Altarama’s hosted networks, you will need to contact Altarama if you wish to have this setting changed.

None –
This setting prevents entry of HTML through any RefTracker client interface page (except where specifically allowed for such as the client interface Question field which encodes all text entered through it so that HTML formatted text cut from web pages can be pasted into this field).  It is the safest value and may need to be chosen by highly secure customers.

Dialogue only –
In addition to the question field, this setting allows use of HTML in RefTracker client interface pages where information about an existing question has been retrieved, such as the screen that allows questions to be changed and update notes provided, the reopen page, the cancel page, and the page that allows clients to respond to queries.  These pages use additional security measures that ensure that they can only be used via a temporary URL provided by the RefTracker server.  It is highly improbable that a spammer could correctly generate one of these temporary URL’s, so it is safe and Altarama will implement this setting for any customer using email importing that requests it.  This is the default setting for this parameter.
If you use email importing you will most likely want to use this setting as imported emails often include HTML.  This setting will ensure clients can use the client interface features in relation to questions created from imported emails, even if the imported email included HTML.
Note that this setting allows HTML to be typed, or copied, into the client interface correspondence fields.  It does NOT allow clients to submit HTML in any other fields than the Question field (with its additional encoding of HTML that allows copy and paste of information from web pages) when submitting a new question. 

All –
This option allows clients to submit HTML in all client interface pages, including all fields when new questions submitted through RefTracker forms, not just the Question field. 
For security reasons this setting can ONLY be used by customers running RefTracker on a server in a secured network, or by hosted customers that have their system IP access controlled.  You can contact Altarama to request a change to this setting if you are a hosted customer with IP access control enabled, or you are an in-house customer and your IT security staff allow Request validation to be turned off.  However, other than the Question field, pasted formatted text will still be automatically converted to unformatted text before insertion – we hope to provide an option that allows formatted text to be cut and pasted into all client interface fields, and the formatting retained in all fields, in the future. 

2.50 Data export retention: Specifies the amount of time for which files created by the Data export process (either run manually or when this process is run by the Data export background process), will be retained.  The Housekeeping routine will delete all files in the exchange/export subdirectories (as that is where Data exports are placed) that were created before the period specified in this parameter, except for the most recent one – the system will always keep the most recently generated output from each Export process because this file may need to be referred to next time the process is run in order to obtain “date last run”.

Exercise:

Consider the effect of these parameters on your library’s requirements. Make any desirable changes, and if you make any, click on Save. Then in Select parameter group choose 3) Formatting.