Overview
As a COI administrator in COI you can configure the the General config settings that affects the overall functionality of the COI module and how disclosure logic behaves.
Accessing General Configuration
Users assigned to Administrator role(s) have access to the General Configuration option in the Configuration menu.
In the General Configuration menu you have option to several general configs that affect the overall COI functionality. Once a change has been made the below two action buttons become available in the top righthand corner. If you make any updates to the notifications or templates you will need to click the 'Save' button for the changes to take effect.
Due Date
The Due Date section allows you to set the disclosure logic related to due dates and when a disclosure will expire.
- How are your institution's due dates set up? - If Static Annual Due Date is selected disclosures will require update on the specified due date annually. If Rolling Annual Due Date is selected the disclosures will require annual update per the last submission date.
- Allow admin to override due date on approval - Allows you to override the due date on approval when enabled. This configuration is recommended for use in non production environments only for testing notifications based around due dates. When the configuration is active, the approve button will bring up the disposition confirmation. Upon clicking update, the user will be given the option to override the due date and confirm. Should always remain unchecked in PRD environment.
- Allow configuring which sponsor hierarchies to expire - Allows you to include a list of Sponsor Hierarchies that will be included in expiration (primarily used with 700u functionality). If no value is present (default) expiration job will run on all disclosures. You can add to the inclusion list by using the bottom sponsor group lookup to search for sponsor hierarchy and add to the above list. If you've added sponsor group(s) to the inclusion list and a disclosure contains only sponsors in those hierarchies the disclosure will expire; if disclosure contains any project with a sponsor not in the list it will not Expire as normal.
Additional notes on Expiration logic: the expiration job will expire any 'Approved' (aka Up To Date) disclosure that has a submitted before either the rolling or static date. Disclosures in other statuses are not updated (i.e. Returned, Submitted, In Progress, etc.). For the Static Due date configuration there is also a 30 day grace period, so any 'Approved' disclosure submitted at least 1 month before the configured static due date will be set to 'Expired'. If the ‘Allow configuring which sponsor hierarchies expire’ option is enabled in configuration the expiration job takes that into account also as described above.
General Configuration Options
In the General Configuration you have a series of different settings to affect the disclosure functionality.
- Automatically assign additional reviewers when disclosure is submitted, based on the reporter's primary unit - If checked, the unit hierarchy from the SP module will be used to pull the associated reporter's primary unit to automatically assign to a protocol if the Lead Unit matches (or if that lead unit rolls up to the lead unit per the hierarchy).
- If reviewer notifications are configured, send that notification in the event of automatic reviewer assignment - If checked, and the reviewer assignment notification is enabled, it will also include these automatic additional reviewers in the review notification.
- Automatically approve annual disclosures that do not have any Financial Entities - If checked, the disclosure will be approved automatically and not require review if there are no Financial Entities. If enabled, be aware no notifications are sent related to disclosures that are auto-approved.
- Do not require researchers with no entities to update their annual disclosure when they have a new project - If checked, it will not require an update to disclosures if new projects are added but the researcher has no Financial Entities.
- Hide Batch Disposition Assignment - If checked, it will remove the option to set all Project Dispositions in one action.
- Always require projects with a sponsor in one of the following sponsor hierarchies to update their disclosure - If sponsor hierarchy(s) are entered in this field it will require updates to a user's disclosure if a new project with a sponsor in that hierarchy.
- Do not require researchers to update their disclosure for new projects if no incomplete fields are added to the disclosure - When enabled if a project is pushed that doesn't populate any editable fields based on progressive disclosure then the disclosure will not go into Update Not Required status instead of Update Required, and no notification will be sent for that project. If "Disclose once at PD/IP stage and have the disclosure carry over to award." is turned on and a project is pushed that updates a project to a new type (PD to IP, IP to Award, etc.) and new fields are required after this update then the disclosure status will change to Update Required and a notification will be sent.
- Declare once on award hierarchy - If checked, award projects that are part of a hierarchy that are pushed from the SP module will only need to disclose once on the award at the parent level. If unchecked, all nodes of the award hierarchy will be brought over to disclose upon.
- Disclose once at PD/IP stage and have the disclosure carry over to award - If checked, allows you to carry forward disclosure information on a Proposal Development and Institutional Proposal to an Award so not all stages have to be disclosed upon separately. Be aware, this is only related to projects being pushed from the Kuali Research Sponsored Projects system (if implemented). This also requires additional configuration on the Sponsored Projects side via the Linked_Project_Push_Enabled parameter and you can more fully utilize the functionality using the 'Project - Linked Projects' form gadget. More information on this configuration can be found in the COI - Templates - Project Gadgets article. Please be aware - when this is enabled it will automatically carry forward disclosure information from Proposal to IP to Award and only the highest project type will display in a user's disclosure.
- Allow reporters to delegate preparation of their disclosure to other users. The reporter will always need to submit the disclosure - If checked, it will enable the delegate functionality in COI which allows a user to assign a delegate(s) with access to then complete their disclosure on their behalf. However, the user will still have to submit. More information on on this functionality can be found in the COI - Delegates article.
- Always require projects with a sponsor in one of the following sponsor hierarchies to fill out a 700-U - allows you to enter sponsor hierarchy names to drive whether a California 700u is required in the disclosure.
- Reset Dispositions on all projects that include sponsors in one of the following sponsor hierarchies - If checked you can enter sponsor hierarchies so that dispositions will only reset on projects from a sponsor in those hierarchies; for example, all federal sponsors.
- Allow Reporters or their Delegates to request a disclosure be returned for Edits - If checked it will allow the reporter (or delegate) to request of an admin that a disclosure submitted be returned so they can edit. You can configure the 'A reporter requests the disclosure to be sent back' and 'A reporter cancelled the request for their disclosure to be sent back' notifications related to this functionality in the Configuration - Customize Notifications tab.
700-U Options
This is where you can enable 700u functionality that is related specifically to the state of California requirements for COI disclosures. More information on 700u can be found in the COI - California 700-U article.
- Enable 700-U: This configuration should remain disabled but if you are a California state school interested in implementing the 700u functionality please reach out to Kuali Research support to start that process.
-
Allow reporter to copy the most recently signed sponsor details into a new 700U: This allows a user to auto-populate a financial entity from the same sponsor on a 700u if a prior signed disclosure exists. When enabled if a user has a new 700u project with incomplete fields on a sponsor previously signed it will present the button option of 'Copy Most Recent Signed "..." 700U' (with the title of the project specified). Once clicked it will auto-populate the entity details in the new entry to ease in data entry.
-
FPPC System Acceptance Number: This value will display in the upper left hand corner of the 700U form.
- Always require projects with a sponsor in one of the following sponsor hierarchies to fill out a 700-U: You will need to specify at least one sponsor hierarchy for the 700u functionality will work. This allows you to specify which group of sponsors will trigger the projects that will require 700u certification in a user's disclosure.
Notification Configuration
The notification configuration options allow you to set whether configured system notifications are Off, set to test mode (with test email address), or Production mode (sends to live users).
The options are desribed below:
- Off - configured system notifications will not send.
- Test - configured system notifications will not send to end users but to the email indicated in the Test Email field. If the Test Email field is blank it will not send notifications.
- Production - configured system notifications will send to end users.
PLEASE NOTE: Production mode will send emails to your users and is only appropriate in your Production Environment. By default this is only set in your Production environments for those customers that are live with COI. All test environments (STG or SBX) are by default set to either Off or Test. However, if you change this to Production in your STG or SBX environments it will send notifications to end users from those environments. Do not change to Production in your lower environments.
Comments
0 comments
Article is closed for comments.