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.1 Allow staff remember me cookie: Allows the staff remember me functionality to be turned off, but before you decide to turn it off, consider the following.

  • The cookie used is encrypted and does not contain any password information.
  • When a user is automatically logged in, the system clearly identifies who they have been logged in as and provides clear instructions as to how to log in as a different user.
  • If a different user logs in, the cookie will be updated to their details if they tick "Remember me", and if they do not tick "Remember me" the previous staff login details will be removed from the cookie.
  • The system log clearly indicates whether a logon was manual or automatic so administrators can tell how access was obtained. 
  • The details facilitating this "Remember me" functionality for staff are stored in the same RefTrackerUser cookie that the client interface "Remember me" details are stored in – but the details are stored separately so it can be used for both purposes on one computer.
  • This parameter works in co-operation with parameter 2.2.

2.2 Staff remember me expiry: In co-operation with parameter 2.1, this parameter provides control over how long a staff Remember me cookie will remain if it is not being used, ensuring that staff logon details that have not been used for the period that you specify in this parameter, will expire, and be unable to be used.


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.5 Maximum email attachment size (Mb): This parameter determines the total size of attachments to an email generated by RefTracker, that will result in the attachments being delivered in that email as hyperlinks instead of the traditional attachment. The value set here (default 9Mb) applied to both client and staff emails. This parameter is important in reducing the volume of traffic passed over the internet, and in ensuring that emails to clients can be received even when the client's email system has a small size limit on attachments, or their email box is nearly full. It will also reduce the number of non-delivery notices that staff have to deal with, and eliminate any possibility of an infinite loop of emails being generated by non-delivery notices being imported from a full email box, only to generate a confirmation email that generates another non-delivery notice, and so on. Please take the time to review this parameter. The default value is 9Mb, to ensure that emails fit under the common email size limit of 10Mb, but If you are a public library you may want to lower this figure to 4Mb or even 1Mb to ensure your emails can be delivered to systems that have low attachment size limits. If you run a system where emails are only ever sent in house you may want to increase this limit to match the limit of your email system. There is a web.config file parameter that sets the maximum file size that can be uploaded to RefTracker, and this web.config parameter would also need to be increased if you need to deliver files larger than 50Mb. You will need to balance the benefits of not having large documents occupying email boxes and the convenience of having attachments where clients traditionally expect to see them – in the attachment line, versus them being provided as hyperlinks at the end of the Answer test in that email. Note that hyperlinks to access attachments presume that the attachments are file types that can be viewed by a web browser. If you deliver attachments that cannot be viewed by a web browser, you will need to ensure that the value you set here is larger than the largest size of the files you send that cannot be viewed by a web browser (though the browser should offer an option to download files it cannot display). Setting this parameter to 0 will ensure that all attachments go out as hyperlinks, should you wish that to happen. 

2.6 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 2.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 1.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.7 Maximum attachment size client (MB): Determines the maximum individual file size that client's can upload to RefTracker.  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.

2.8 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".

2.9 Access preferences (ServicePoint): This parameter determines whether ServicePoint users will be allowed to use the My preferences function in their Main menu and Preferences in their DeskStats screen. Both of these preferences functions allow individual users to determine how RefTracker is going to work for their individual signon. However, often ServicePoint user signons are shared, and when they are shared, you will want to set this parameter to No, so that only Systems Administrators/Supervisors can change how the shared signon works – individual users will only then be able to the use the functions as they are set up by the System Administrator/Supervisor.

2.10 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.11 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.12 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.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 Qutilities menu for closed questions.

2.25 Journal update period: 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 number of days after the close of a month that journals and new questions can continue to be entered, or questions can still be closed, for dates in the closed reporting period - if you report monthly you may well want to set this parameter to 28 days or less.
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.6 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.30 Allow blank password: In order to protect the integrity of hosted systems, blank passwords are not allowed on hosted systems. If you have an in-house system and would like to allow blank passwords, please contact Altarama about allowing this feature for your in-house system.

2.31 Enforce password change: Set this parameter to "No" if you do not want to force users to change their passwords. If this parameter is set to "Yes", all users will need to change their passwords according to the policy chosen in Parameters 2.32, 33, and 34. If a user's password has expired and they can change their own password, they are presented with their My preferences page so they can immediately make the change. If the grace period has expired they will not be able to do anything else in RefTracker until they correctly change their password. If a user's password has expired and they cannot change their own password, the user will be allowed in. The Active System administrator will be sent an Alert email asking them to provide a new password for this user's signon (and let the user know about it). So, to enforce your password policy it is critical that you change the user's password whenever you received one of these emails – it may mean that someone who should no longer be using your system, is using it!

2.32 Password expiry: If parameter 2.31 has been set to "Yes" select the time period after which the password must be changed (how often it needs to be changed).

2.33 Password expiry grace period: If parameter 2.31 has been set to "Yes" select the time period after expiry of their password that staff will be allowed in. If a user tries to log in during the grace period they will be shown their My preferences screen that allows them to change their password, or, if they do not have permission to do that, an email will be sent to the System administrator advising them that the password for that user needs to be changed.

2.34 Password strength: Leave this parameter as "Not controlled" if you do not want to force users to use a password of a particular strength.

"Regular" - requires at least 8 characters including at least two character types
"Strong" - requires at least 10 characters including at least three character types
"Very strong" - requires at least 14 characters including at least four character types

The four possible character types are:

Lower case, Upper case, Numbers, punctuation/symbols.

An attempt to use a password that is not strong enough will result in a validation message to the user.

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.

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. 

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. 


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.