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.
Provide an interface that will allow users to view existing tools
Tools are defined by the Tool java class within admin-api
The Tool class corresponds to the TL_T table in the database.
Secure the interface
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.
Users should be able to select an existing tool and view its details
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.
Users should be able to modify the values of tool parameters
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:
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.
Users should be able to define a new tool
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.
All modifications should be logged for audit purposes
Add audit logging to the tool and localization constants to track changes made via the interface.