Skip to end of metadata
Go to start of metadata
Target release3.3
Document statusDRAFT
Document owner

Joe Swanson

DesignerJoe Swanson


  • Provide a web interface to manage tool definition.
  • Ability to add new tools that link to external sites without needing to create configuration files and perform a deployment.

Background and strategic fit

Our goal is to make administration of the application a task available to non-developers and avoid the need for operation staff to deploy or restart the applications or application servers.


  • Management of the home screen is a separate task and is not covered in this effort.
  • All infrastructure will be added within the admin tool of Mobility.
  • This interface, like all administrative ones, is formatted for use with a desktop browser.
  • All labels on the interface will be localized strings.


#User StoryImportanceNotes
1Provide an interface that will allow users to view existing toolsMust Have
  • Tools are defined by the Tool java class within admin-api
  • The Tool class corresponds to the TL_T table in the database.
2Secure the interfaceMust Have
  • Only authenticated users that are members of the configuration group should be able to access the interface.
  • The configuration group may or may not exist depending on the order that tasks are performed in. If it is missing, add it to the database and update the auth.dataload.sql in kme-auth-config with the group info.
3Users should be able to select an existing tool and view its detailsMust Have
  • Details should include the contents of the TL_T table
  • Details should also include all localized strings (LocalizedString class in shared-api, L10N_STRING table in db) for the tool that was selected.
4Users should be able to modify the values of tool parametersMust Have
  • Tool aliases can not be changed.
  • Icon urls can point to resources external to the app.
  • No feature to upload graphics will be supported.
  • Localization should be included as part of the items that can be modified.
  • Localization keys for tool title, subtitle and description should not be alterable and should always follow the existing pattern:
    • toolalias.home.title
    • toolalias.home.subtitle
    • toolalias.home.description
  • Localization should currently be limited to the languages defined by the "supportedLanguages" Spring bean from SpringBeans.xml
  • There must be a confirmation page that summarizes the changes being made, displaying the following:
    • The tool being modified.
    • The attribute name(s) being modified.
    • The old value for each attribute.
    • The new value for each attribute.
  • Unchanged attributes should not be displayed on the confirmation page.
  • The confirmation page should have three options:
    • Confirm the information and save it to the database.
    • Go back to the form to modify the information.
    • Cancel the transaction entirely and navigate to the list of tools page.
5Users should be able to define a new toolMust Have
  • The list of tools from #2 should have a button to create a new tool.
  • The form to collect information for the new tool should look the same as that for modifying a tool, including the localization constraints from #4.
  • The confirmation rules from #4 should apply to submission of a new tool as well.
  • Tool aliases must be unique, so all input for that field must be validated against the database to ensure the value is not already in use.
  • The tool alias should be used as the prefix for localization variables that will be created and inserted for new tools.
    • toolalias.home.title
    • toolalias.home.subtitle
    • toolalias.home.description
6All modifications should be logged for audit purposesMust Have
7Any new or modified tool data should trigger an update within the applicationMust Have
  • Create a spring task created to monitor the audit table for tools and trigger a refresh if an update is detected. The default interval should be 60 seconds.
  • This process is necessary to propagate changes across multiple servers.

User interaction and design


Below is a list of questions to be addressed as a result of this requirements document:


Not Doing


  1. Can we use Membership tool for point 2, that screen allows user to create group and assign users to it, so probably we would not have to update auth.dataload.sql. Actually we may not need any other user than Admin who has rights to membership tool and he can create groups and map users to it.

    1. We absolutely can.  In fact that is the reason I wanted the membership interface done first.  We will have to finish the user interface as well for the admin tool to be fully functional.