(Draft in progress below ... not completed)


This is a technical architecture refinement to achieve the following functional objective.  Note that the term "message" here and in the Rich Messages requirement, equates to all UI text elements.

This has multiple potential benefits, including:

This requirement ideally includes all UI text elements..  The work for each element will be prioritized and the 'delta' to the work, sized, assessed and planned for.   Its conceivable that a particular milestone (or the entire 2.2 R1) could include just the centralized error messages, for example, with the other UI elements to follow (in later milestones or releases).   Below is the list of UI text elements --  the "other" are not in prioritized order.  This is a work in progress - tbd is reviewing this list to ensure comprehensiveness and best terminology, and then we'll prioritize the items:

Note that there are related requirements:

Detailed Description

The data structure and messaging APIs will be determined, but it is assumed that messages will be in a database, or structured message table, or structured resource file, or some other structured repository/format so that:

  1. Application code can pass the appropriate message ID to the Rice 'message service' and be returned the appropriate message content to display through the user interface to the end user.
  2. Message content can be reviewed, edited, and updated during development through one central message repository (in addition to being viewed in context when using the software).

As we work on this structure, we will also need to keep in mind a model that will support the following:

This requirement does not include building the capability that will implement aspects 3, 4, or 5 but does include building the message structure and API(s) that will enable these aspects to be implemented.  And other requirements will follow in future releases (separating out other UI elements, through a similar centralized data structure).

Usage Scenarios

Usage scenario One:

A user of a Kuali application encounters an error, but the software can't access the error message repository to pull in and display the richer message content (the error message repository is on the server and the application can't get to it, temporarily).  Rather than hang, instead the user receives the default cryptic error message that includes the message ID (the message ID is embedded in the logic/codebase, and is the variable sent to the repository to pull down the matched content).  The default cryptic error message includes a link to the public web, with the message ID.  Or the user can link to his/her preferred web search engine and search on the message ID.  The public search results finds the appropriate content (does not require getting to the error message repository), so the user can see the message content.  In addition to the message content, the user can also see more details on how to fix this condition.  The user also finds there are social aspects, community additions with comments on how they fixed this problem.

For examples, see

Usage scenario Two:


Mocks and Diagrams

Include any mocks (for UI enhancements) or diagrams that might be helpful in understanding the issue:


If applicable, list expectations for performance (optimal and worst cases would be fine, give time in seconds):


Enabling for internationalization includes two major aspects:

Other references:

Related JIRAs:

Requirements Listing

List all requirements (individual verifiable statements) that indicate whether the work for this item has been complete. If there are requirements that are not absolutely essential to the functionality as a bare minimum but are desired / would be nice to have if time allows, enter those under 'Secondary':

  1. item
  2. item
  1. item
  2. item


List any functional or technical work that must be completed before work on this item can begin:

  1. item


List any issues that need to be resolved before work on this item can begin:

  1. item
  2. item
  1. If we could get the API for the KS Message service and the message table structure that would be helpful for design purposes
  2. Instead of moving all the current text out of the dictionary and into the external message repo, we could leave them in there as defaults. Then if any message exists in the repo that would override the default in the dictionary. This would be nice since there would always be a value for a property, and easier to develop. Essentially the message service could just be an override mechanism but you could override everything.

QA or Regression Testing Plan

List steps needed to test the basic functionality of this update, enhancement, bug fix

  1. test/steps
  2. test/steps


Functional Lead:  Candace Soderston, csoders@uw.edu

Functional Analysis Complete? No

Needs Review by KAI? Yes

Technical Analysis Complete? No

Needs Review by KTI? Yes

Estimate: 30 hours

Technical Design: External Messages Repository

Jira: KULRICE-6676

Final Documentation: Link Here