KIT Topics

1

KIM Services

User, Group, Role, Permission, Authentication, and Authorization infrastructure in Rice. Shared tables and a shared set of service to retrieve from and update context specific and shared information from those tables.

KIT

KRice

Blocker

07/01/08

In Progress

Y

Y

Y

Y

Y

Y

Y

Y

2

KIM UI

User interfaces to front end KIM services

KRice

KRice

In Progress

N

Y

N

Y

3

KOM Services

Organization infrastructure in Rice. This solution would provide the ability to use a single hierarchical structure or context specific hierarchy structures unique to each application, but with overlapping organizational branches. This solution would achieve technical re-use across projects. A centrally maintained hierarchy is extremely important in controlling, for example,data role up for reports, establishing ownership of data,and accommodating workflow. It is further recommended that the consistent titling of this data should be "Organization" (from KFS), thus doing away with the KRA/COEUS "Unit". Shared tables and a shared set of service to retrieve from and update context specific and shared information those tables

KIT

KRice

Critical

Functional

Y

Y

Y

Y

Y

Y

Y

Y

4

KOM UI

User interfaces to front end KOM tables

KRice

KRice

Functional

N

Y

N

Y

5

KEM Service

Entity (Vendor, Sponsor, Agency, Customer, etc.) infrastructure in Rice. Shared tables and a shared set of services to retrieve from and update context specific and shared information from those tables.

KIT

KRice

Functional

Y

Y

Y

Y

Y

Y

6

KEM UI

User interfaces to front end KEM services

?

KRice

Functional

7

Object Codes

An object code table would exist in KFS that would be accessed by KRA. Object Codes are data elements for which the authoritative source is the financial function, and therefore the data are best located and maintained in the financial system. This table needs to accommodate any additional attributes needed by KRA.

KIT

Functional

Y

Y

N

Y

Y

N

8

Proposals

Proposal data are necessary for both systems but should be maintained in KRA, as the research administration function is the authoritative source. Certain proposal data are necessary for financial post award administration that is managed out of the financial system. This table will need to accommodate any additional attributes needed by KFS.

KIT

Functional

Y

Y

N

Y

Y

N

9

Sponsors

Sponsor data are necessary for both system but the authoritative system should be KRA. Certain sponsor data maintained in KRA are necessary for financial post award administration that is managed out of the financial system. This table will need to accommodate any additional attributes needed by KFS. Further review of external entities should occur to see if that central table (referred to in Item 2 above) can accommodate Sponsor. NOTE: This analysis was done during the10/23 meeting, and we agreed that Sponsor should be accommodated. Same as KEM?

KIT

Functional

Y

Y

N

Y

Y

N

10

Budgets (Categories/Levels)

Research Administration may require a separate mapping process for object codes for proposal budgets. KRA calls these budget categories and KFS calls them levels. The Integration Team recommends that KRA and KFS budget sub-committee review the best process for accommodating separate mapping while maintaining the integrity of financial data for financial reporting purposes.

KIT

Functional

Y

Y

N

Y

Y

N

11

Rice Modularization

Should implementers be able to choose a subset of the Rice modules to use, e.g. just workflow and identity management? If so, does that mean they shouldn't even have to create the tablels associated with the other modules? Separate libraries, URLs, upgrade scripts, etc. cause significant complexity from a client application configuration management perspective. So, if the breakdown is there, we want to make sure there's a reason for it and we understand how we should be using it.

KFS

KRice

Blocker

09/15/08

Functional

Y

Y

Y

Y

Y

Y

12

True SOA

need functional explanation

KRA

KRice

Y

Y

Y

13

Rice consuming Rice services

need functional explanation

KRA

KRice

Y

Y

Y

14

Versionable Documents

We need the ability to create and store different versions of a document. For instance, Coeus allows the user to create multiple versions of a budget document. The user can copy, edit, and save all of the versions. One version must be designated as "final" before the document is submitted into KEW routing, and all of the versions ("final" and not) are stored with the completely routed Proposal/Budget document.

KRA

KRice

N

Y

N

Y

Y

15

Accessibility

Collaboration between KFS and KRA in progress

KFS

All

Critical

Functional

Y

Y

Y

Y

Y

Y

16

Active Indicator

KFFC decided early on that deletion was bad from an auditing perspective. Instead, Rice contains functionality to support an active indicator attribute on records. This functionality is currently being enhancement by KFS to facilitate "trickle-down inactivation" (e.g. when this object code is inactivated, all related sub-object codes should be inactivated also) and "inactivation prevention" (e.g. this account type cannot be inactivated, because there are open accoounts that refer to it).

KFS

KFS

Blocker

08/01/08

In Progress

Y

Y

Y

Y

17

Common Modularization Strategy

KFS has been discussing strategy with KTI, and will be discussing in detail with KRA

KFS

KFS

Blocker

08/01/08

Technical

Y

Y

Y

Y

N

18

Usability

Ongoing task, but KFS Usability group is prioritizing blocker issues for release 3 now. Same types of things will probably come in from KRA testers and other Rice clients.

KFS

KRice

Blocker

08/01/08

Functional

Y

Y

Y

Y

19

Data Dictionary User Interface

At least document type authorization, labeling, and active indicator must be maintainable by functional users

KFS

KRice

Blocker

08/01/08

Pending

Y

Y

Y

Y

20

Dates & Timestamps: Format Configurability & Consistent Use

We need to allow implementers to be able to customize the date entry and display formats. Also, at a technical level, date and timestamp data types have been used very inconsistently.

KFS

KFS

Blocker

08/01/08

Technical

Y

Y

Y

Y

Y

21

Error Handling & User Messages

Numerous functional issues reported regarding wording of messages, location of errors with respect to the field that has the invalid value, hard coding of values in error messages that should be able to be customized via system parameters, etc. See KFSMI-53

KFS

KFS

Blocker

08/01/08

Pending

Y

Y

Y

Y

22

Exception Handling & Incident Reporting

Display a more user-friendly page and message when applications encounter an unrecoverable error. Allow the user to enter additional information about what they were doing when the problem occurred on this page. When the user submits the page, call a service to generate an incident (default implementation will just send email). Provide a very simple want for implementers to override the initial handling of the problem (messaging, page that is displayed, etc.) and/or the incident reporting behavior.

KFS

KRice

Blocker

08/01/08

In Progress

Y

Y

Y

Y

Y

Y

23

Extraction Issues

When Rice was born, some thing were wrongly taken from KFS that do not pertain to everyone (e.g. parts of accounting infrastructure), and some things were not taken that do pertain to everyone (e.g. portal and batch framework).

KFS

KRice

Blocker

08/01/08

In Progress

Y

Y

Y

Y

Y

Y

24

Fix Document Type Definition Duplication

There are technical and functional components of document type definition. There should only be 1 technical and 1 functional component when this issue is resolved. The Document Type Maintenance Document that now exists in Rice should control the functional information associated with the workflow document type, too. And, the technical document type definition in the data dictionary should include workflow configuration.

KFS

KRice

Blocker

08/01/08

Technical

Y

Y

Y

Y

25

Navigation Improvements

Provide a way for users to get back to where they came from, e.g. breadcrumbs. When returning to lookups, the search criteria and result set should be preserved.

KFS

KRice

Critical

08/01/08

Technical

Y

Y

Y

Y

26

Performance Issues: Maintenance Document XML

Only persist the information that is editable on the maintenance document to reduce CPU usage and speed of save / retrieval.

KFS

KFS

Blocker

08/01/08

Technical

Y

Y

Y

Y

27

Performance Issues: Workflow XML

Much work was done on this as part of the performance improvements KFS made in Rice for the 2.2 release. However, there may be further improvements that can be made once the workflow document type configuration is done in the data dictionary.

KFS

KRice

Blocker

08/01/08

Technical

Y

Y

Y

Y

28

Portal Extraction & Improvements

KRA would like to use the same portal infrastructure as KFS, so this shouldn't be extracted from KFS into Rice. In addition, the infrastructure should take authorization for a particular function and the document type active indicator into account when determimning whether to display links to the user.

KFS

KRice

Blocker

09/15/08

Technical

Y

Y

Y

Y

Y

29

Web Layer Infrastructure Cleanup

The display layer infrastructure in Rice is over-complicated and brittle, and is therefore difficult to maintain. We will need to address this at some point.

KFS

Major

Technical

Y

Y

Y

Y

30

Workflow Using the Nervous System (Consistent Look/Feel with KFS/KRA)

Workflow should use the Rice Nervous System so that the look and feel for users is the same as it is in KFS and KRA.

KFS

KRice

Blocker

08/01/08

Technical

Y

Y

Y

Y

Y

31

Workflow Simple Delegation

Provide the ability to delegate by person and document type across all types of action requests including adhoc.

KFS

KRice

Blocker

09/15/08

Pending

Y

Y

Y

Y

32

Interface of Financial Awards Data from KRA to KFS

Allow for the Sharing of Financial Award Data between KRA and KFS

KRA

KRA

Blocker

09/15/08

Pending

Y

Y

Y

Y