ID |
Topic |
Description / Notes |
Reporter |
Assignee |
Priority |
Due Date |
Status |
KFS Wants |
KRA Wants |
KRice Wants |
KS Wants |
Impacts KFS |
Impacts KRA |
Impacts KRice |
Impacts KS |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
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 |
|
|