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.
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.
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 by RefTracker. You . 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. You may also want to reduce this period if you are running short of concurrent user licences, and you want to ensure that staff users log out regularly to allow others to come in. , 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.
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:
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.
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.
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.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
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.
Dialogue only –
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.