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.
Assumptions
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.
Requirements
#
User Story
Importance
Notes
1
Provide an interface that will allow users to view existing tools
Must Have
Tools are defined by the Tool java class within admin-api
The Tool class corresponds to the TL_T table in the database.
2
Secure the interface
Must 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.
3
Users should be able to select an existing tool and view its details
Must 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.
4
Users should be able to modify the values of tool parameters
Must 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.
5
Users should be able to define a new tool
Must 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
6
All modifications should be logged for audit purposes
Must Have
Add audit logging to the tool and localization constants to track changes made via the interface.
Any new or modified tool data should trigger an update within the application
Must 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
Questions
Below is a list of questions to be addressed as a result of this requirements document:
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.
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.
2 Comments
Aniruddha Jani
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.
Joe Swanson
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.