Important! To set the system configuration
to suit the needs of your institution, you need to log in as a user with
the RME Application Administrator
role. To apply most changes, restart the RME application, for example,
by IISRESET.In this topic Hide
This page is used by RME administrators to configure system settings, including user authentication and external users, and some specific module settings. Note that HDR Configuration settings are available under the HDR menu. This is to provide access to HDR administrators who may not be given access to System Preferences.
Important! To set the system configuration
to suit the needs of your institution, you need to log in as a user with
the RME Application Administrator
role. To apply most changes, restart the RME application, for example,
by IISRESET.
Menu path: RME menu > System > System Preferences
1. From the RME menu, select System > System Preferences.
2. Complete the fields, using the tables below as a guide.There are various options in this page.
3. In the toolbar, click Save. To go back to the previous page, click it in the breadcrumb trail or use your browser Back button.
These settings allow you to define values that affect all modules in RME.
Field Label (in layout order) |
Description |
Max Idle Timeout (mins) * |
Number of minutes to allow users to remain idle (no activity) before logging them out, as a security measure Example: 120 minutes (default) Minimum value: 10 minutes Maximum value: 240 minutes This setting applies to all users in RME, Crystal reports, Research Costing and Pricing (ReCaP), Costing and Pricing Tool (CPT), and ERA Assist. All open RME tabs in the browser will be logged out. To continue, users need to log back in via the Login page. The last viewed page will be displayed in one browser tab. If other tabs were also previously open for RME, users will need to re-display them.
• It is recommended that users save their work regularly, as a general best practice. If a user enters details but does not save, and then stops using RME and the timeout applies, they risk losing their work. • See Max Idle Timeout explained below for details about how it is applied. |
GST% |
Default Goods and Services Tax percentage to apply to financial records, such as Budget Financials and Transaction Financials related items, as well as the Costing and Pricing Tool, if used |
Show only current records in lookups |
Yes by default Controls whether lookup search results will include non-current items |
If Yes, all RME lookups, such as for org. units or fund schemes, will only list records marked as Current in search results. The 'Current' search criterion line displays by default. Users can remove the default search line and select new criteria to search for non-current items or complete any other search if required. Unlike the No option below, if the 'Current' search criterion line is removed and the Search button is clicked, the search will still only list current records. |
|
If No, all lookups will still display only current items and the 'Current' search criterion line by default. However, unlike the Yes option above, if the 'Current' search criterion line is removed and the Search button is clicked, the search will then list both current and non-current records. |
|
Initialise action date to current date, for sig event? |
If Yes, the Action Date for a new significant event will automatically default to the current system date. To leave the Action Date field blank, change to No. The current date is based on the system time zone set in Time Zone Settings. |
Automatically set the Responsible Person to the currently logged in user? |
For the Notes functionality in all modules in RME If Yes, the Responsible Person field in the note will be auto-populated with the logged-in user's name. |
The timeout is applied with a sliding approach. In general, if the user stops interacting with the system before and including the halfway mark of the set timeout value, they will be timed out after the set time has elapsed based on the start time. If they stop interacting after the halfway mark, they will be logged out after the set time based on the last access time.
If more than one browser tab is open for RME, unused tabs will remain active in the background. When there is no activity in the tab that was last touched, all tabs will be logged out, using the sliding approach described above.
The system does not constantly monitor the elapsed idle time or connection time to avoid impacts to performance. Therefore, a session can exceed the limit slightly (by a few seconds or minutes) before a user is logged out.
Examples with one browser tab
Timeout is set to 30 minutes.
Start Time |
Next Access Time(s) |
Timeout Calculation |
Timeout Applied |
9:00 |
9:10 |
9:10 is less than 50% of the timeout period from 9:00 = 9:00 + 30 mins |
9:30 |
9:00 |
9:15 |
9:15 is exactly 50% of the timeout period from 9:00 = 9:00 + 30 mins |
9:30 |
9:00 |
9:16 |
9:16 is more than 50% of the timeout period from 9:00 = 9:16 + 30 mins |
9:46 |
9:00 |
9:16, 9:30 |
a) 9:16 is more than 50% of the timeout period
from 9:00 b) 9:30 is less than 50% of the timeout period from 9:16 (a. above) = 9:16 + 30 mins |
9:46 |
9:00 |
9:16, 9:32 |
a) 9:16
is more than 50% of the timeout period from 9:00 b) 9:32 is more than 50% of the timeout period from 9:16 (a. above) = 9:32 + 30 mins |
10.02 |
9:00 |
9:16, 9:32, 9:48 |
a) 9:16 is more than 50% of the timeout period from 9:00 = 9:16 + 30 mins (renewed timeout due at 9:46)
b) 9:32 is more than 50% of the renewed timeout period from 9:16 (a. above) = 9:32 + 30 mins (renewed timeout due at 10:02)
c) 9:48 is more than 50% of the renewed timeout
period from 9:32 (b. above) |
10.18 |
Examples with more than one browser tab open
Timeout is set to 30 minutes.
Starts Time |
Open New Tab |
Next Access Time(s) |
Timeout Calculation |
Timeout Applied |
9:00 in tab A |
9:05 in tab B |
- |
Timeout renewed when tab B is opened |
9:35 |
9:00 in tab A |
9:05 in tab B |
9:20 in tab B |
a) Timeout renewed
when tab B is opened b) 9:20 in tab B is exactly 50% of the timeout
period from 9:05 (a. above) |
9:35 |
9:00 in tab A |
9:05 in tab B |
9:20 return to tab A |
a) Timeout
renewed when tab B is opened b) 9:20 in tab A is exactly 50% of the timeout
period from 9:05 (a. above) |
9:35 |
9:00 in tab A |
9:05 in tab B |
9:26 in tab B |
a) Timeout
renewed when tab B is opened b) 9:26 in tab B is more than 50% of the timeout
period from 9:05 |
9:56 |
9:00 in tab A |
9:05 in tab B |
9:26 return to tab A |
a) Timeout
renewed when tab B is opened b) 9:26 in tab A is more than 50% of the timeout
period from 9:05 |
9:56 |
RME includes audit functionality to capture user activity details for auditing. These settings allow you to select the activities to capture, such as when users create, update or delete a core record or eForm, view a record or eForm, view a report, or perform a workflow action.
Audit data can be useful to determine how your users interact with the system. You can see which reports or widgets are used, when a record is viewed and by whom, or common browsers used or gather peak usage statistics.
The audit function does not capture any activities that are completed in RME Designer itself, such as creating or editing an eForm template or workflow, as this component is installed separately on each user’s PC.
Please be aware that if you enable the audit feature and capture a wide range of activity details for auditing, system performance may be impacted. Also, audit data is stored in the database so its size may grow significantly.
To view activity details captured by the audit functionality, system administrators with access to the database can look at the audit table rma_user_activity_log. Alternatively, you can also create reports using the Users reporting view, RMRV_USER_ACTIVITY_RPT_READ and RMRV_USER_ACTIVITY_LOG tables. Refer to the RME Reporting Views and RME Report Designer documents.
Prerequisite
If enabled, these audit settings will only capture details of tables with Enable Audit? set to Yes in Table Auditing.
Field Label (in layout order) |
Description |
Audit record create/update/delete? |
If Yes, the system will capture audit details for reporting purposes of all tables with Enable Audit? set to Yes in Table Auditing, which is available for pages on which users can create, update or delete Audit Details button In the RME interface, basic audit details are always shown via the Audit Details button on RME core record pages, regardless of this setting or audit settings in Table Auditing. The button displays a popup with the time and user details when a user creates a new record or eForm (Created By and At), and when a user updates a record or deletes a record (Modified By and At). |
Preserve deleted records? |
If Yes, copies of deleted records will be stored separately in the database. For more about deleted records, refer to the separate RME Reporting Views document. |
Audit record read? |
Capture audit details for the following activities for reporting: • View a core record • View a related item • View an eForm Additional information For core records, it captures additional information about how the user navigated to the record (from search results, Previous/Next button, breadcrumb trail, widget, browser navigation, URL, bookmark, refresh or outside source). For eForms, it captures additional information about how the user navigated to the form page (from search results, Previous/Next button, widget, email, bookmark or outside source). |
Audit report viewing? |
Capture audit details when the following types of reports are viewed for reporting: • DevExpress reports created using RME Report Designer • Crystal reports Additional information Report name, description, report page viewed and searches. |
Audit other user activities? |
Capture audit details for the following activities for reporting: • Access a tab on a search page • Perform a search - basic or advanced • Save a search, use a saved search • Access a dashboard • Access a page • Use a toolbar button, such as New, Copy or Export • Create or update a record or related item • Change the column order via the Columns button on the toolbar • Complete a page action, such as a Bulk Update, or Reload Supervisors • Create a new eForm application • Access a different eForm application page • Perform a workflow action for an eForm • Access an online help page • Access an invalid page (for example, invalid URL, server error or insufficient data security access)
Capture administrative actions: • Download a feeder template for a feeder (DOC007) • Update a product key • Update custom content, such as noticeboard widgets, the RME header or footer • Reset a user password • Update a Page View layout • Access pages for System Preferences, eForm Email Templates and Documentation (SYS001, SYS002, SYS003, ADM020M, DOC001) • Update System Preferences
It does not capture any actions in RME Designer. |
Audit data available for reports for each activity may include the following details:
Field Label (in alphabetical order) |
Description |
Activity Timestamp |
Date and time the activity was performed (based on the server timezone, not System Timezone) |
Additional Data |
Extra information or context about the activity |
Browser |
Browser that was used to perform the activity on the user's computer |
Description |
Brief description of the activity that was performed |
Input Type |
How the activity was performed in the user's browser, for example, by touch or keyboard |
IP Address |
IP address of the user's system that is used for the activity |
Operating System |
Operating system on the user's computer that is used for the activity |
Page ID |
ID of the RME page on which the activity was performed |
Page View Key |
Foreign key of the Page View accessed by the user when the activity was performed |
Primary key |
Primary key for the activity |
Record Key |
Foreign key of a record if the activity involves a core record, eForm, report or similar |
RME Version |
Version number of the RME system used |
Session ID |
ID for the RME session when the activity was performed |
URL |
URL of the browser used |
User Key |
Primary key of the person that performed the activity |
User Name |
Name of the person that performed the activity |
Window Size |
Size of the browser window |
These settings support emails in RME.
If
you change these preferences, you will need to restart the RME application,
for example, by IISRESET, to apply changes.
Field Label (in layout order) |
Description |
Email server |
Used to specify your organisation's email server name All emails from the RME application will be routed through this server. The RME application web server must have access permission to the email server.
• Scheduled date - The email will be sent on the date specified in the Date of Action of the Significant Event record. An email scheduling service is used to send the scheduled emails. The email scheduling service needs to be installed on a server and configured properly for the scheduled emails to be sent successfully. For details on how to install and configure the email scheduling service, refer to the RME installation guide. • Send immediately - The system will attempt to send the email right away to all the recipients. |
Email port |
Used to specify the email port The RME Application web server should have access to the email port. |
Use SSL |
Indicates whether Secure Sockets Layer (SSL) is enabled (Yes), to establish an encrypted link between RME and the email server |
Username to Authenticate Email Server |
Username for your organisation's email server, if the mail service requires authentication |
Password to Authenticate Email Server |
Password for your institution's email server, if the mail service requires authentication If you have previously saved a password, this will display as << SAVED >> for security reasons. |
Default sender email |
Email address added by default in the Sender line for system emails, such as external user and reset password emails |
These settings control attachments to emails in RME.
Field Label (in layout order) |
Description |
Maximum total attachments size (MB) |
20 MB by default Defines the maximum total size of all documents that can be attached to an email in MB, for example, emails for Significant Events • Users can add more than one document to an email within this size limit. • The total size is based on actual file sizes, not compressed file sizes. • File chunking is used to process large files over 10MB to avoid time-outs.
|
Attachments file extension allowed |
Defines the file formats that will be accepted as an attachment to an email • This works with the Maximum total attachments size (MB) preference setting. • If more than one, separate each extension with a semi-colon (;) with no spaces between. • File extension validation against this setting is case insensitive. For example, if configured to allow the pdf extension, documents with the extension of PDF, pDf, PdF or PDf, will be considered valid and will be uploaded. |
These settings control the loading and storage of documents in RME.
Field Label (in layout order) |
Description |
|||||||||
Storage type for uploaded documents |
Used to determine the preferred storage type for uploaded documents in all modules Storage options: • Database • File System - the Path for files stored in file system field will be displayed
Maximum character limits
|
|||||||||
Path for files stored in file system |
Displays if the storage type is File System Specify the network path for files to be stored in the file system. This path will be included in the character count for documents added in the system. See 'Maximum character limits' in the field details above.
|
|||||||||
Maximum document size (MB) |
Defines the maximum size of a single document that can be uploaded for a record via a Document related item, or via a document RIC or DDA in an eForm template
|
|||||||||
Allowed file extensions for documents |
Defines the file formats that can be uploaded for a record via a Document related item, or via a document RIC or DDA in an eForm If more than one, separate each extension with a semi-colon ; File extension validation against this setting is case insensitive. For example, if configured to allow the pdf extension, documents with the extension of PDF, pDf, PdF or PDf, will be considered valid and will be uploaded. |
|||||||||
Scan document files before uploading? |
Default: No Indicates if your Windows Defender antivirus scanner is used to scan files uploaded via RME linked document functionality before uploading to either the defined path or the database, depending on the option selected in the Storage type for uploaded documents field above. If the scan does not detect a threat, the document will be uploaded to RME. If a threat is detected, the document will not be uploaded. An error message will alert the user. Note: Windows Defender is the only anti-virus software currently supported. List of document upload elements (click to view) |
|||||||||
Document scan application path |
Location path of your Windows Defender .exe file Example: C:\Program Files\Windows Defender\MpCmdRun.exe
• If the entered path does not include the expected .exe file format, you will not be able to save changes to the System Preferences page. An error message at the top of the page will display "Cannot find or access the document scan application" (you may need to scroll up to view this). • If the path points to another .exe file, the System Preference page will save successfully however the scan will not run. During file upload, all files, including those containing possible threats, will be uploaded without any errors. • If the Windows Defender .exe file is moved, document files cannot be uploaded. A message will display to users: "A problem occurred when scanning the file. The document was not uploaded. Contact your IT department." • Ensure that Windows Defender is enabled for your RME environment. Depending on your internal policies, you may need to liaise with your IT department. If it is not enabled, document files cannot be uploaded. A message will display to users: "A possible threat was detected. The document was not uploaded. Contact your IT department." |
|||||||||
Document scan application options |
Function in Microsoft Defender using the command-line tool mpcmdrun.exe Example: -Scan -DisableRemediation -ScanType 3 -File For information about these options, refer to Windows Defender documentation about using the command-line tool.
As this field cannot be validated by the system, it is strongly recommended that you test document scanning before launching in a production environment for general use, and test at regular intervals or according to your internal security policies. |
|||||||||
Document scan timeout (milliseconds) |
Number of milliseconds by which a scan must be completed or it is cancelled, without uploading the document Example: 10000 (equates to 10 seconds) |
To set a document as mandatory, use the following settings:
• RME core records: Required setting for the Document field in the Page View via either the Page Layout Designer or field properties.
• For eForms: Mandatory flag for the Document field (DOC_FK) in RME Designer, eForm Designer.
This setting controls the behaviour of fields for personnel lookups in RME.
Field Label |
Description |
Create without search first? |
If this setting is No, users are forced to search for at least one existing person before they can create a new record for the person, in an effort to minimise duplicates. |
If this setting is Yes, users will be able to create a new Person record without searching for an existing one. Be aware that this may result in duplicate records for the same person. When the user selects the Create option from the lookup field, a popup displays with fields to complete for the person, such as addresses. The Person record is saved when the user selects OK, and those fields are populated as read-only in the record being created. These will be saved with the remaining details entered when the new record is saved. If Yes, users will be able to create a new Person record from the following pages: • Project > Investigator (PRO004) • Ethics > Investigator (ETH002) • Research Outputs > Contributor (PUB002) • Contract > Personnel (CON003) • HDR > Student (STU001) - will create a Person record with Type as Student • HDR > Student > Supervisor (STU029) • HDR > Student > Examiners (STU043) • Committee > Committee Member (COM003) • Panel > Panel Member (PAN002) There are similar options to allow users to create a new ethics record from the Linked Ethics related item for projects in Project Preferences, and for students in HDR Configuration. |
ORCID is a worldwide alphanumeric code used to uniquely identify researchers. These setting are used to enable RME to automatically retrieve and store ORCID iDs, as well as verify entered ORCID iDs. See RME layout for details and a video.
Field Label (in layout order) |
Description |
Enable ORCID verification |
Yes by default Indicates whether RME should verify that ORCID details entered by users are valid When this option is Yes, RME will automatically check that the ORCID code entered by a user is valid via the orcid.org website. ORCID fields can be in either the Personnel module or a Personnel RIC in an eForm. If the iD is registered successfully in RME, the official button ORCID button will also display. If this is not required, slide this to No which will disable ORCID verification.
|
ORCID URL |
Secure https URL to orcid.org's website to use in verification
|
ORCID API URI |
Secure https URI to call orcid.org's API to use for verification
|
Enable ORCID iD collection |
Yes by default Indicates whether users are able store their ORCID iD in RME |
Client ID |
Your ORCID client ID to access orcid.org's API |
Client Secret |
Your ORCID client secret to access orcid.org's API |
Authorize URL |
Authorisation URL to receive the auth code from orcid.org Refer to the orcid.org's documentation. |
Token URL |
Token URL to receive the registered ORCID iD from orcid.org Refer to the orcid.org's documentation. |
When enabled and configured, this feature is used to validate entered Australian Business Numbers (ABN) with the Australian Business register. In some cases, to also automatically imports organisation details for a given ABN to avoid duplicate or incorrect organisation details.
To configure ABN Lookup web services, the URL and URI must be stored in RME. Complete the following fields then select Save in the toolbar.
Field Label (in layout order) |
Description |
Enable ABN Lookup? |
Enables or disables the ABN Lookup Web Services feature in RME
|
ABN Web Service URI |
URI for ABN Lookup web services
|
ABN GUID |
Authentication GUID (Globally Unique Identifier) which is required to access ABN Lookup web services To obtain a GUID, register via the Australian Business Register website: https://abr.business.gov.au/Documentation/WebServiceRegistration |
What happens now?
When the above details are correctly configured, users can enter an ABN in the Organisations or Address Details pages and click the ABN Lookup button to validate the number with the ABN register.
Organisation details may be retrieved from the ABN register and automatically populated in these fields in Organisation pages if the details are available: Organisation Name, Entity Name, Entity Type, ASIC#, State and Postcode (Physical only, not Postal). These details can be edited if needed.
Note that the full address cannot be retrieved.
Google's reCAPTCHA is a third-party security mechanism designed to establish that a computer user is human, not an automated program or robot. This prevents spam and other security vulnerabilities.
This is mandatory for external user registration and the ability for users to reset their own passwords for both external users and if manual authentication is used, for security reasons. RME uses invisible reCAPTCHA.
To start using invisible reCAPTCHA, you need a Google account, and you must register your site domain. Google will provide an API key pair for your site. The key pair consists of a site key and secret key. For details, go to the Google reCAPTCHA website, for example, https://www.google.com/recaptcha/about/. Unfortunately, it is not possible for ResearchMaster to set up a Google account, register your site domain or obtain keys for you.
Field Label (in layout order) |
Description |
CAPTCHA API URL |
API URL for CAPTCHA functionality |
CAPTCHA site key |
Public or site key for CAPTCHA functionality The site key is used to invoke the reCAPTCHA service on your site. |
CAPTCHA secret key |
Your secret key for CAPTCHA functionality The secret key authorises communication between your application back-end and the reCAPTCHA server to verify the user's response. Keep the secret key safe for security purposes. |
The following messages may display in the System Preferences page for CAPTCHA settings; in both cases, check the details you entered. If you are unsure, contact Google:
• The CAPTCHA API URL configured in RME is not valid.
• The CAPTCHA Secret Key has not been configured in RME correctly.
Field Label (in layout order) |
Description |
System Time Zone |
Time zone used for dates and times across the entire system |
Display Current System Time |
Default: Yes Displays the current system date and time in the bottom left corner of the screen for core pages (not in eForm pages or the Costing and Pricing Tool due to the page layout with panels) See the example in RME general layout - Current system time zone If you don't want to display this, change it to No. |
Tip: When communicating to your users about dates and times, particularly if some may be in a different location and time zone, include information about the system time zone so that they are aware. You may, for example, want to communicate this in a Noticeboard widget on user dashboards.
The eForms to list in 'My (eForms/applications)' tab setting controls the eForms listed in the My eForms/Applications tab in all eForm listing pages for all domains and users.
By default, the eForms displayed in this tab are only those intended for the user (created by or for).
Field Label |
Description |
Show user's eForms only |
(Default) Only lists eForms created by or for the user. |
Show all eForms created by the user, for themselves or others |
RME Administrators and supervisors can sometimes create eForms on behalf of students. This setting lists eForms created by or for the user, which includes eForms they created on behalf of others. When this option is selected, standard users who cannot create eForms on behalf of others will not see any difference. Workflow security permissions are still applied. If a user does not have defined permission for the workflow state of the eForm it will still be listed but they will not be able to open it. In this case, as it is in different state, it is likely that someone else is working on it.
Exception In HDRCM only, for current, approved examiners, the My Applications tab in the HDRCM domain listing page will list all the Examiner Outcome eForms to which they are linked. The Application List widget can be configured to also provide access to linked Examiner Outcome eForms for examiners. See: Dashboard widgets |
FOR and SEO Classification codes consists of three levels:
• Level 2 is
the highest level in the structure, with 2-digit codes
Example FOR code: 01 Mathematical Sciences
• Level 4 is
the second level, with 4-digit codes
Example FOR code: 0101 Pure Mathematics
• Level 6 is
the last, detailed level, with 6-digit codes
Example FOR codes: 010101 Algebra and Number
Theory, 010102 Algebraic and Differential Geometry, and so on
Use this preference to set the FOR and SEO code level/s to display in the Classification grid lookup in a Classification RIC for selection, from the following options:
• All (default, users can enter/select 2, 4 or 6-digit codes, as previously)
• Level 2
• Level 4
• Level 6
More than one level can be selected (except All). This setting does not impact any other type of classification codes, such as custom codes added for your institution.
In an eForm, when one or more specific levels are selected, the Classification grid lookup will only display FOR and SEO codes for the selected level/s. For example, if only Level 6 is ticked in the system preference, only classification codes with 6 digits will be shown in the grid lookup.
For Animal Ethics eForms, Human Ethics eForms, and Biosafety eForms, the following options are available, depending on the applied product keys:
Field Label (in layout order) |
Description |
Set Primary Person as Primary Contact |
When this option is enabled (Yes) and saved, the person marked as Primary on the ethics eForm application will be automatically set as the primary contact for the application as well. |
Default Application Status |
Used to set the default status for the initial stage of the workflow for an ethics eForm For example, you may want a new eForm to have the status of Draft. The default status will be applied to all eForms and associated workflows for the selected template category unless a different status is defined for the workflow when it is configured. The status defaults to N/A in the eForm if a status is not assigned in the workflow. |
Default Ethics Category |
Used to set the default category to display in the Ethics Category dropdown when designers create an ethics eForm template and workflow Designers can change this to suit their purposes if they wish. If the designer wants to force the form user to select a category from the list, they can use the Not specified option. If there is only one category available, this will be automatically populated in the eForm application. Ethics category items are defined in RME > Ethics > Ethics Categories. |
Expert Advisor Group |
Used to select a committee as an Expert Advisor Group for ethics eForms An Expert Advisor Group is a group of people who may be called upon to provide specialist advice on ethics applications. This is optional and only relevant if your institution currently uses expert advisor groups. An Expert Advisor Group is managed in RME as a committee (RME > Setup > Committees). All selected domain committees will be available for selection as an Expert Advisor Group. To ensure that the Expert Advisor Group remains separate to other committees, they cannot be involved in the actual review process. If a committee is selected as an Expert Advisor Group, it cannot be added to any of the workflows in the domain. Similarly, if a committee is added to a workflow in the domain, then that committee cannot be selected as an Expert Advisor Group. |
This grid is used to filter the category items that display in Linked Personnel RIC, Employment Type dropdown in RPR eForms for the Costing and Pricing Tool.
The Employment Type dropdown allows eForm users to select from category items defined for the Employment Type parent category in the RIC. This option allows you to define which items to list in the dropdown as not all items in this group may be relevant for Costing and Pricing Tool processes.
The grid displays all the current records under the Employment Type parent category group (RME > Setup > Categories > Person Related Categories). By default, all current items will be selected. You can search for specific items via search field functionality.
To filter the dropdown list, de-select (un-tick) the checkbox in the column on the left for items you do not want listed, then save your preferences. To de-select all items to start over, click the checkbox at the top of the column. Save your changes.
What happens next?
In an RPR eForm, only the selected category sub-groups will display for selection in the Linked Personnel RIC, Employment Type dropdown. Related employment fields for HEW Level (or similar level) and Step will be populated based on the selection in the Employment Type dropdown. Note that in order to display previously saved data, a saved value from the Personnel record will display in a RIC in an eForm even if the Employment Type was later disabled in system preferences.
See also: Employment Type categories
These settings allow you to define values that affect the Projects module.
Field Label (in layout order) |
Description |
Enable validation between statuses and dates in projects records? |
Yes by default If Yes, each time users enter a status and/or date in Project Details, the system will validate and prompt the user to ask if they want to match it to a corresponding status or date. For example, if a date is entered into the Date Approved field and saved, a prompt asks if the user wants to change the status to Approved. Similarly if the status is changed to Closed Off and saved, a prompt tells the user if a Date Closed Off has not been entered and allows them to return to enter one. If No, validation will not occur after saving, so care must be taken to confirm these details manually. |
Restrict approval if ethics clearance not provided? |
No by default The approval of the project may be restricted depending on whether Ethics application has been issued. Three options are available depending on the nature of your project approval process. Options from the dropdown are: • Yes: Ethics clearance status will be validated • No: Ethics clearance status will not be validated (default) • Warning: A warning will be displayed to the user but entries can be saved once the user acknowledges the warning |
Can create ethics appl. from ethics clearance entry? |
No by default If Yes, users will be able to create a new Ethics record from the Linked Ethics related item for the project (PRO024) via a Create option in the lookup |
Validate Ethics Clearance From date after Date Applied? |
Yes by default This option controls the automatic validation that checks if the Ethics Clearance From Date is after the Project Date Applied. Options from the dropdown are: • Yes: These particular dates will be validated (default) • No: Dates will not be validated • Warning: A warning will be displayed to the user but entries can be saved once the user acknowledges the warning Options for No and Warning can be useful when an Ethics application is used for multiple projects, so the Clearance From Date is not necessarily on or after the Project Date Applied. |
Enable Date Validations |
Yes by default Enables or disables automatic validation of dates in both Project core records and RPR eForms For example, a date entered in the Date Approved field is checked to ensure that it is later than the Date Applied. Similarly, a date entered in the Date Closed Off field is checked to ensure it is later than the Date Approved. If not, a prompt explains the error to the user so they can enter correct dates. • If Yes, dates will be validated. • If No, dates will not be validated. |
Auto-create Project - Organisation records when Project - Fund Scheme records are added |
Yes by default Enables or disables automatic creation of Project - Organisation related item records when a fund scheme is added to the Project - Fund Scheme related item If Yes, the org. unit for any fund scheme (defined in the Setup > Fund Schemes record) added to the Project - Fund Scheme related item will be added to the Project - Organisation related item, if it does not already exist. If No, Organisation related items will not be automatically created. Any organisations related to the project need to be added manually. |
Filter Project - Organisation record, Fund Scheme Link list by Project - Funds Schemes |
Yes by default Enables or disables the dependency between the Project - Fund Scheme related item and the Project - Organisation related item Fund Scheme Link dropdown If Yes, the Fund Scheme Link dropdown in the Project - Organisation related item will only display fund schemes that have been added in the Project - Fund Scheme related item for the project. If No, the Fund Scheme Link dropdown in the Project - Organisation related item will display all fund schemes that the organisation is linked to in Fund Scheme records, Organisation field (in RME > Setup). |
These settings allow you to define values that affect the Contracts core module.
Field Label (in layout order) |
Description |
Enable Date Validations |
Yes by default Enables or disables automatic validation of specific dates in Contract core records For example, a date entered in the End Date field is checked to ensure that it is later than the Start Date.
If Yes, the following validations are enabled: • Start Date cannot be later than the End Date. • Date IP Start cannot be later than Date IP End. • Date Agreement from cannot be later than Date Agreement to. • Date Restriction Started cannot be later than Date Restriction Ended. • Date Renewed cannot be earlier than Start Date. • Date Renewed cannot be later than End Date. • Date Combined cannot be later than Date Withdrawn. • Date Transferred cannot be later than Date Withdrawn. • Date Approved should be before or the same as today's date but is not mandatory. You can continue and save a different date from the prompt. • Date Withdrawn should be before or the same as today's date but is not mandatory. You can continue and save a different date from the prompt. • Date Withdrawn should be after or the same as the Start Date but is not mandatory. You can continue and save a different date from the prompt. • Date Withdrawn should be before or same as the End Date but is not mandatory. You can continue and save a different date from the prompt. |
If No, dates will not be validated. If confirmation is needed for dates it will need to be done manually. |
|
Enable validation between statuses and dates in Contract records? |
Yes by default Enables or disables automatic validation of specific dates and statuses in Contract core records For example, if a date is entered into the Date Approved field and saved, a prompt asks if the user wants to change the status to Approved.
If Yes, the system validates the following conditions when a user enters a status and/or date in a Contract core record, and displays a prompt: • Date Approved is entered but the status is either Withdrawn or Renewed. A prompt displays which allows the user to accept the status change (Yes) or cancel without saving. In this case, the Status must be Approved to save a date in the Date Approved field. • Status is changed to Withdrawn, but Date Withdrawn is not entered. A prompt displays which allows the user to cancel and enter a date, or continue without entering a date. • Status is changed to Renewed, but Date Renewed is not entered. A prompt displays which allows the user to cancel and enter a date, or continue without entering a date. • Status is changed to Approved, but Date Approved is not entered. A prompt displays which allows the user to cancel and enter a date, or continue without entering a date. |
If No, validation will not occur after saving. If confirmation is needed for dates it will need to be done manually. |
|
Filter Fund Scheme Link based on the Organisation |
Yes by default Enables or disables the dependency between the Fund Scheme record and defined organisation/s for Fund Scheme Link in the Contracts record, Organisation related item.
If Yes (default), the Fund Scheme Link lookup only displays current fund schemes linked to the selected organisation. |
If No, the Fund Scheme Link lookup displays all current Fund Scheme records in the system. |
These settings allow you to define values that affect the Research Outputs module.
Option |
Description |
Allow adding new books while entering Research Output data? |
If Yes, users will be able to add a new book as the parent publication when entering a new book output, provided the book is not already in the system |
Allow adding new conferences while entering Research Output data? |
If Yes, users will be able to add a new conference as the parent publication when entering a new conference output, provided the conference is not already in the system |
Allow adding new journals while entering Research Output data? |
If Yes, users will be able to add a new journal as the parent publication when entering a new journal output, provided the journal is not already in the system |
Allow Deletion of Verified Research Output Records? |
Controls the ability for all users to delete verified research output records |
Automatically populate classification record from the 1st internal contributor? |
If Yes, the classification linked to the first added internal contributor will be linked to the research output automatically by the system following the process below:
|
Definition of "Collection Year" |
Defines "collection year" used in the system for research outputs, from the following options: • Year Data Submitted (Year After Publication) • Year Item published |
Linked Contributor to use |
How the contributor name is shown, from available Personnel fields: • Preferred Name • Full Name |
No. of Research Output Verifications Required |
Number of verifications required for a publication to be complete This will render a set of relevant fields for every additional verification required when completing the publication details. |
Role Designated for First Level Verification |
RME role designated to complete the first level research output verification Users with this role will be able to enter the first level verification information online. |
Role Designated for Second Level Verification |
RME role designated to complete the first level research output verification Users with this role will be able to enter the first level verification information online. |
These settings allow you to define values that affect the Ethics module and eForms.
Option |
Description |
Enable Date Validations |
Yes by default Enables or disables automatic validation of dates in Ethics core records and Ethics eForms For example, a date entered in the Date Approved field is checked to ensure that it is later than the Date Applied. Similarly, a date entered in the Date Closed Off field is checked to ensure it is later than the Date Approved. If not, a prompt explains the error to the user so they can enter correct dates. • If Yes, dates will be validated. • If No, dates will not be validated. |
Enable validation between statuses and dates in Ethics records? |
If Yes, each time users enter a status and/or date in Ethics Details in an Ethics core record, the system will validate and prompt the user to ask if they want to match it to a corresponding status or date. For example, if a date is entered into the Date Approved field and saved, a prompt asks if the user wants to change the status to Approved. Similarly if the status is changed to Closed Off and saved, a prompt tells the user if a Date Closed Off has not been entered and allows them to return to enter one. If No, validation will not occur after saving, so care must be taken to confirm these details manually. |
These settings allow you to choose the method for authenticating users.
If
you change these preferences, you will need to restart the RME application,
for example, by IISRESET, to apply changes.
To start, in the Authentication method field, select the method you want to use. Relevant fields for that method display in the page. Complete the fields, using the relevant sections and tables below as a guide.
With this method, each user will be able to log in with a provided username but they will need to set their own password. The password process involves sending an email and verifying the email address. For password and Login screen settings, go to Password Preferences.
Select this option, complete the setting below if required, and save to enable this method.
Field Label |
Explanation |
Enable two-factor authentication |
Indicates whether to send an additional code via email to the user to enter for every log in, as an extra layer of authentication Options: • Off = Disabled (default) • External users only = Will only send emails and codes to users outside RME that are registered as external users, not internal RME users • On - All users = Enabled; will
send emails and codes to all users, both external and internal For details, see: Two-factor authentication below. |
This method can be used for LDAP. Select this option, complete the settings below, and save to enable this method. For Login screen settings, go to Password Preferences.
Prerequisite: You should have an understanding of the Active Directory service.
The system will use the active directory authentication to allow the user to log in with their active directory credentials. You will have to create each user in RME with the same username in the active directory.
Field Label (in layout order) |
Explanation |
Enable two-factor authentication |
Indicates whether to send an additional code via email to the user to enter for every log in, as an extra layer of authentication Options: • Off = Disabled (default) • External users only = Will only send emails and codes to users outside RME that are registered as external users, not internal RME users • On - All users = Enabled; will
send emails and codes to all users, both external and internal For details, see: Two-factor authentication below. |
Machine name of the AD server |
Machine URL of the LDAP (Active Directory) server |
Domain name of the AD server |
Domain name of the LDAP (Active Directory) server |
This method can also be used for LDAP. Select this option, complete the settings below, and save to enable this method. For Login screen settings, go to Password Preferences.
Prerequisite: You should have an understanding of Windows scripting.
The system will use the Windows script authentication to allow the user to log in.
Field Label (in layout order) |
Explanation |
Enable two-factor authentication |
Indicates whether to send an additional code via email to the user to enter for every log in, as an extra layer of authentication Options: • Off = Disabled (default) • External users only = Will only send emails and codes to users outside RME that are registered as external users, not internal RME users • On - All users = Enabled; will
send emails and codes to all users, both external and internal For details, see: Two-factor authentication below. |
Windows script name |
Script name for authentication |
Program ID |
Program ID for the script |
This option allows you to enable or disable single sign-on using Security Assertion Markup Language (SAML). Select this option, complete the settings below, and save to enable this method. For Login screen settings, go to Password Preferences.
Prerequisites: You need to have an understanding of XML and the SAML 2.0 standard for SSO. This help page does not provide the steps to set up an SSO authentication service, nor explain the SAML 2.0 standard. If you have any questions, refer to the official SAML documentation, talk to your ResearchMaster contact or notify the ResearchMaster Helpdesk.
• You can configure SSO with SAML as well as External User Preferences. This will allow external users to access the RME Login screen to select an external user link. In this case, SAML users will not go directly to the SAML provider in the first instance. They will be able to click a button for SAML authentication (configurable) and select the SAML "remember" option so that the next time they log in, they will access the system via the SAML authentication process. You can configure RME Login page labels that are used in this particular process in the Login Options section. If enabling external user registration, also consider the Enable simplified login for SAML setting in External User Preferences.
• RME currently supports one SAML profile: SP-Initiated SSO: Redirect/POST Bindings. For details, refer to: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html
• Single sign-out is supported if the external identity provider supports it.
• We have tested our SSO with Shibboleth IdP and Netscaler IdP. If you use, or want to use, any other IdP provider, please talk to your ResearchMaster contact or ask the ResearchMaster Helpdesk for guidance.
Single Sign On Using SAML: Fields
To configure and enable Single Sign-On using SAML, complete the following fields:
Field Label (in layout order) |
Description |
Enable two-factor authentication |
Only applies to external users Indicates whether to send an additional code via email to external users to enter for every log in, as an extra layer of authentication Two-factor authentication for SAML users is supported by the provider. Options: • Off = Disabled (default) • On - External users only = Will
only send emails and codes to users outside RME that are registered
as external users, not internal RME users For details, see: Two-factor authentication below. |
Local service provider configuration name |
Name of the entity Id as configured in the SAML identity provider |
Local service provider configuration description |
Service provider description |
Local service provider configuration description thumbprint |
Thumbprint of the description from the server local store that has been exchanged (intended) with the identity provider to form a trust You can enter the raw copy from the certificate properties for the thumbprint. You don't need to modify it, such as remove hex characters or spaces. Example: a7 e2 f5 f7 9a b8 8c 86 2c 37 f5 22 1b ea 8c 19 b1 58 99 3c |
Local service provider configuration certificate thumbprint |
Thumbprint of the certificate from the server local certificate store that has been exchanged (intended) with the identity provider to form a trust You can enter the raw copy from the certificate properties for the thumbprint. You don't need to modify it, such as remove hex characters or spaces. |
Button label for SAML users |
If external users are also enabled, this is the name of the button a Login page that SAML users need to select to then gain access via the SAML provider If external users are not enabled, users log in via the SAML provider. For an example, see: Login screen label settings. |
IDP name identifier key |
Indicates the mapping SAML assertion/attribute information equivalent to the application username The default behaviour is "Subject"/"Name Identifier". If the username is other than the subject or name identifier, then this configuration is required to find the username. |
Partner name |
Entity Id as per the metadata received |
Store external login |
Yes by default Indicates whether to store the external login credentials in the AspnetUser external logins This is required if the client application is to allow non-existing user accounts to use the application via external identity providers. If No, users authenticating via an external IdP must exist in the RME database. |
Provider configuration name |
Name of the partner identity provider to use (one among the configured identity providers) |
Provider configuration provider name |
Name of the identity provider |
Provider configuration description |
Description of the identity provider |
Provider configuration single sign on URL |
Single Sign-On (SSO) service URL |
Provider configuration single log out URL |
URL to navigate to when the Logout button is clicked If blank, the system default logout page will be used. |
Provider configuration single sign on binding |
Binding methods |
Provider configuration sign authentication request |
Indicates whether the SAML request is signed Generally, this is Yes so that SAML requests can be verified as coming from the correct source. It is only No for testing/debugging purposes. |
Provider configuration partner certificate |
Public key of the IdP This is used to verify the signature of the SAML response. This should come from the IdP; it is the Base-64 encoded public key of the IdP's certificate. |
This section only displays if Enable external user registration is enabled in External User Preferences as well as SSO/SAML.
You use these fields to customise the labels in a special Login page that is used for both SAML and external users (before either SAML authentication or the RME External Users Login screen). For an example, see: Login screen label settings.
Field Label |
Description |
Header for external user button |
Text above the button that external users need to select to request access to RME in the Login screen for SAML users |
Button label for external users |
Label on the button that external users need to select to request access to RME in the Login screen for SAML users |
Header for SAML user button |
Text above the button that SAML users select to log in The button label is populated with the value in the SAML user button on Login page from the Single Sign On Using SAML settings. |
You can enable two-factor authentication for all authentication methods in the RME System Preferences. By default, this setting is disabled. When enabled, each time a user enters their username and password to log in to a new session of RME, a unique, one-time code will be sent to their primary or most current email address. They need to enter this code to complete the login process. Currently, two-factor authentication only works with email addresses. It is not available for SMS on mobile phones.
To change the default email sent to users, go to System Preferences, Email Template Preferences > Security Code Template.
For SAML, the provider is responsible for providing two-factor authentication, however when using SAML with external users in RME, there are interdependencies for the login process. The two-factor setting for the SAML method is to provide two-factor authentication for external users. The process will use the email address used as the username in this case.
If you make any changes to this setting, you must reset the system, for example, by an IIS reset.
Rules
These settings define the process used to provide access to people that do not exist in the system, such as external researchers, students, supervisors or examiners. You can set preferences for external users, including aspects of the registration process, and configure default roles and AOUs (org. units) for these types of external users: Researcher, Applicant, Supervisor, Examiner, or Other.
You must also set up the CAPTCHA security mechanism to ensure that this
feature works correctly. It is designed to establish that a computer
user is human, not an automated program or robot to prevent spam and other
security vulnerabilities. See: CAPTCHA settings
To change labels or remove fields from the External User Register and External User pages (SYS004, SYS005) customise the Page Views. For example, you may wish to hide the ORCID field if your institution does not use or collect ORCID details for researchers.
If you change these preferences, apart from default roles or AOUs, you will need to restart the RME application, for example, by IISRESET, to apply changes.
• For an overview of the process, see: External Users overview.
• For password settings, go to Password Preferences.
Field Label (in layout order) |
Description |
Enable external user registration |
Default: No Indicates whether the external user function is used (Yes) or not used (No) |
Enable simplified login for SAML |
Default: No Only to be used if the Method in Authentication Preferences is Single Sign On Using SAML and Enable external user registration is Yes Indicates whether to use a simplified Login screen
instead of the standard Login screen for SAML and external users If Yes, the Login screen will offer two buttons for Internal Accounts and External Accounts. Based on the selection, a second Login screen displays to suit, with either: • Internal Accounts > Fields to enter SAML credentials • External
Accounts > Fields to log in, the Register
link to request access, and the Forgot
Password link if they need to reset their password Remember my choice: To avoid the two-step login process after the first log in, the user can select this checkbox. Once they successfully log in, the next time they access the system, only one Login screen matching their choice will display. For an example, see: Login screen label settings. |
Default AOU |
No default Default AOU from a lookup to automatically assign in the Personnel record for approved external users for each user type This only assigns the AOU to the Personnel record automatically, not the User record as that would give external users access to all records for that org. unit. You can choose to assign access to records to suit different external users as needed. |
Default Role |
No default Default role from a lookup to assign automatically to approved external users for each user type If you want successfully registered external users to be able to update their own details, you will need to create custom Page Views in the Personnel module, and then add these Page Views to the default roles you defined in these preferences. |
Default Supervisor Registration eForm |
Select a Supervisor Registration eForm template to be linked in an 'Approved External Supervisor' email for any external user applying as a supervisor in the online registration form |
Email token expiry (minutes) |
Default: 5 Number of minutes an email confirmation token is valid, after which another email needs to be requested |
External password label |
Default: Password Text for the password field on the External User Log In page, when a user first clicks the external user register option label (above) For an example, see: Login screen label settings. |
External user option label |
Default: Click here if you are an external user Text for the link on the RME Login page for external users to select so they can either a) log in if they are already registered,or b) register as a new user via the Register link (above) When this is clicked, the following labels defined in this page for external users will replace the standard labels on the Login page: external username label, external password label, external user register link label and external user reset password label will be displayed. For an example, see: Login screen label settings. |
External user register link label |
Default: Register Text for the link that displays in the Login page when a user first clicks the external user register option label (below), which enables them to register as a new user Note: Existing external users can log in using the log in credential fields. For an example, see: Login screen label settings. |
External user reset password label |
Default: Forgot Password? Text for the link on the RME Login page for external users to select when they forget their password if the authentication method is manual; it will initiate the reset password process For an example, see: Login screen label settings. |
External username label |
Default: Email Text for the username field on the External User Login page, when a user first clicks the external user register option label (above) For an example, see: Login screen label settings. |
Terms and conditions text/link |
Default text: I agree to the institution’s terms and conditions Text for the external user to agree to the institution’s terms and conditions in the Register page (SYS004) when registering a user account You can include a URL to a website with your institution’s applicable terms and conditions. |
For examples, see: Login screen label settings.
The following system email templates are available to support the external user registration process:
• External User Email Confirmation in RME Email Templates
• New External User Request in RME Email Templates
• External User Request Approved in RME Email Templates
• External User Request Rejected in RME Email Templates
• Reset Password in System Preferences, Email Template Preferences
You can modify the content of these templates but you cannot delete them or add others as they work with automated processes.These settings allow you to configure the standard RME Login screen labels, and set password preferences. Password preferences only apply to external users, and to internal users if the Authentication Method is Manual in Authentication Preferences. To reset a user's password, see: Users, Reset a password.
For details about Connection Account users (for system back end tasks) refer to the RME Installation and Upgrade Guide.
Field Label |
Description |
|||||||||||||||
Allow password reuse? |
No by default Indicates whether to allow users to enter a password they have used previously (Yes) If No, users will not be able to use any previous passwords. If Yes, define how many times a user can use a previous password in the Number of past passwords allowed field. |
|||||||||||||||
Enable password expiry |
No by default Used to enable or disable password expiry for external and Connection users, and all users if the system authentication method is Manual Users will be prompted to re-set their password when the number of days set in Password expiry (in days) has elapsed. If changed to Yes, the Password Expiry Enabled? flag and Password Expires On field in a User record for new users will be pre-populated by the system preferences. These can be overwritten per user, for example, for Connection users, where it may be useful to avoid resetting the password frequently if password expiry is enabled. The system will update all existing User records that also have the Password Expiry Enabled? flag in the User record set to Yes. If the Password Expires On field in a User record has been overridden so that it is different to the automatically-calculated date based on number of days defined in the Password expiry (in days) field in System Preferences, the User record value will only be changed if it is more than the system preference setting. How these settings enable password expiry:
|
|||||||||||||||
Number of failed login attempts allowed |
Number of times a user can attempt to log in before the account becomes locked, as a security measure When an account is locked, a message is shown advising the user to contact their RME administrator to have the account reset. Until reset, the user will not be able to log in even if the correct password is provided. • This applies to access to RME and associated tools including RME Designer, RME APIs and all integration services. • This impacts all users, including RME administrators, external (public) users, and connection users (used to connect to APIs, feeders and other integration services), and if Single Sign-on (SSO) is not used, all other users. If SSO is used, other users will not be affected by this. To allow a user to reset their password, go to the User record and select Initiate Reset Password. |
|||||||||||||||
Number of past passwords allowed |
Applied only if the Allow Password Reuse? is Yes Number of times a user can use a password they have set previously |
|||||||||||||||
Password expiry (in days) |
Default: 60 Applied if Enable password expiry is Yes in System Preferences, and Yes in a User record, or just Yes in a User record Number of days a user-set password remains valid before the user is prompted to reset it This is used to automatically calculate the date and time the password will expire in the Password Expires On field in the User record. The expiry activates when the user next logs in after this date, so it may display a past date. Once the user enters a new password, this field is re-calculated. |
|||||||||||||||
Password label |
Preferred label text for the Password field in the Login screen to prompt users to enter a system password For an example, see: Login screen label settings. This is not the same screen as the Simplified Login screen used for SAML and external users. |
|||||||||||||||
Password validation error message |
Default: Password must contain 8-16 characters. Password must contain at least 1 lowercase letter. Password must contain at least 1 uppercase letter. Password must contain at least 1 digit. Password must contain at least 1 special character ! @ # $ % ^ & * Error message to display to a user if they do not enter the correct password based on the regex expression in Password validation regex expression The relevant part of the default message displays based on what the user has entered.
|
|||||||||||||||
Password validation regex expression * |
Mandatory Default: ^(?=.*\d)(?=.*[a-z])(?=.*[A-Z])(?=.*(\!|\@|\#|\$|\%|\^|\&|\*|\(|\))).{8,16}$ (see matching message above) Regex expression used for password strength validation This field is required to ensure that external users, as well as internal users (manual authentication), can reset their own password. See: Change password
|
|||||||||||||||
Username label |
Preferred label text for the User Name field in the RME Login screen to prompt users to enter their RME username For an example, see: Login screen label settings. This is not the same screen as the Simplified Login screen used for SAML and external users. |
For examples of the various Login screen label settings, see: Login screen label settings.
These email templates are used to support user management and authentication processes. You can change the subject text, or edit the body by clicking the edit icon at the top right. An editing toolbar enables you to format the body text.
Email Template |
Description |
Reset Password Template |
This email template is sent when a user needs to reset their password, for example, after reaching the maximum allowed number of attempts to log in. The Password Reset function is only available for external users, or internal users if the authentication method is Manual. The email is sent automatically when a user selects the Forgot password? option in the Login screen (manual or external users), or when an administrator clicks the Initiate Reset Password button on the User record for internal users. |
Security Code Template |
This email template is sent to users as part of two-factor authorisation to provide the code the user must enter to log in. |
Other emails to support different processes are provided, or created and managed in RME Email Templates, as well as in Significant Events in each module.
Product key: Modules > Core
Page ID: SYS001.htm
