Summary of Features

1. All users must pass through the LOGON screen before they can gain access to the system. This requires the entry of a USER ID and PASSWORD which are validated on the Menu database.
2. There is an option to request additional authentication on the LOGON screen for validation against a RADIUS or LDAP server.
3. Invalid logon attempts will be recorded in the AUDIT database. The contents can be viewed using the List Logon Errors screen.
4. Users may be prevented from changing their passwords, or be forced to change them after a specified interval or number of logons. Refer to the Menu Controls screen.
5. New Passwords may be forced to conform to a particular pattern. Refer to the Menu Controls screen for details.
6. User passwords may be encrypted before being stored on the database. Refer to the Menu Controls screen for details.
7. The list of options (tasks) which are available can be broken down into any number of menu 'pages', with each page having its own unique identity. Refer to Appendix A for details.
8. The number of menu pages and their content can be altered by using online transactions. Any number of menu levels can be defined. A task can appear on any number of menus. Refer to Appendix A for details.
9. Security specifications are defined for Roles. Each User is assigned to one or more of these Roles, and inherits all the security aspects of those Roles. A user's Roles can be modified with great ease.
10. Module-level security - access to individual modules/tasks is granted to Roles by constructing a separate Task Access Profile for each Role.
11. The same menu structure can be shared by different Roles. Any menu item which is not accessible to any of the user's Roles at run time will not appear in the display.
12. Each Task may have a separate sub-menu (known as the navigation bar) which contains a series of tasks which are related to the current task.
13. The contents of each navigation bar is dynamic and can be can be maintained via the List Navigation Buttons screen.
14. Buttons within a module's navigation bar which are not accessible to the current user's Roles will not be shown.
15. Each Role may have a different start task defined. This may be any menu in the system. This means that after a user within that role as his primary role has logged on they will be taken straight to that menu instead of the default system menu and then forcing them to navigate down to the menu that they can access.
16. Field-level security - the screen for each task contains a number of data items or fields. By default each user has full access to all of these fields, but this can be changed to read only or no access for users of particular roles. Refer to Appendix C for details.
17. The behaviour of certain tasks can be changed by altering a value in the Task Parameters within the menu database. This value is passed to the script when it is activated so that it can take the appropriate action.
18. Each task refers to a single script, and it is possible for a script to be accessed by multiple tasks within the menu database. Each of these tasks can have their own set of Task Parameters so that the script's behaviour can be altered. Refer to Appendix E for details.
19. Access to individual tasks can be temporarily disabled without having to alter the details for individual Roles. Refer to the TASK_DISABLED switch on the TASK record.
20. A User's access to the system can be temporarily disabled without having to delete that User's details. Refer to the USER_DISABLED switch on the USER record.
21. Each screen contains a hyperlink to an online help facility which uses data from the HELP-TEXT table. Refer to Appendix F for details.
22. There is the option to turn on Audit Logging for selected database tables so that changes made to those tables can be logged. The contents of the audit log can be reviewed using standard online tasks.
23. There is the option to use the Workflow Engine if it has been activated.
24. Standard XSL stylesheets are provided in the top level XSL directory. Local variations can be created in the subsystem's own XSL subdirectory.
25. It is possible for a user to create more than one browser window to access the application, and for each window to act independently from the other. Please refer to Client Clones and Server Sessions for more details.
26. A collection of CSS styles are defined in the CSS subdirectory. Styles can be switched using the Update Session data screen. Local variations can be defined in the subsystem's own STYLE_CUSTOM.CSS file.
27. It is possible for screen titles and labels, and even application data to be issued in a variety of foreign languages. Please refer to Appendix O: Internationalisation for details.
28. By default all dynamic XML files are constructed in memory and then dropped after use. If it is necessary to examine the contents to aid in debugging then there is an option to have them written to disk. See Update Session data for details.
29. All SQL queries are created dynamically. If it is necessary to examine any generated query there is an option to have them written to disk. See Update Session data for details.
30. It is possible to have designated pages automatically refresh themselves after a certain time limit. See the SCREEN REFRESH option in the Update Task screen.
31. By default all pages are accessed using the HTTP protocol, but if certain pages need the more secure HTTPS protocol this can be turned on using the USE HTTPS option in the Update Task screen.
32. It is possible to set times on one or more days during which the application is closed for maintenance. No user access will be allowed during this period. It is also possible to issue a warning message before this period starts. Refer to the Menu Controls screen for details.
33. If it is required to print any web page without any of the menu buttons, navigation buttons, action buttons and scrolling or pagination details these can be removed using the PRINT option in the menu bar.
34. All web pages are produced by XSL transformations which by default are processed on the server, but there is the option (provided that your web browser has the capability) to have these processed on the client instead. Refer to Performing client-side XSL transformations for more details.
35. The standard method of sending data to the user is via an HTML page, but patterns are available to generate other formats such as CSV, PDF (List view) and PDF (Detail view).
36. Although the framework does not use any JavaScript it is possible to add JavaScript to selected pages.
37. It is possible to extend the standard validation class by supplying additional custom validation methods.
38. There is the option to prevent simultaneous updates of records on certain database tables by adding in a field called 'rdcversion' with a data type of 'integer'.
39. There is the option to specify initial values for fields within specified tasks when accessed by specified users, or users within specified roles. How these values are used depends on the type of task:
    • If the task adds new records to the database this will provide initial values.
    • If the task is of type LIST this will provide selection criteria before records are retrieved from the database.
40. There is the facility to use a single database table to store data for multiple accounts, but keep each account's data private to users within that account. This is explained in Appendix P.
41. There is the option in drtail screens to copy the data of a record in order to create a new one. Refer to the COPY and PASTE buttons in the action bar.
42. There is the option to restrict update and delete operations to a record's creator. See FAQ95 for details.
43. As well as using a separate search screen to enter selection criteria before retrieving data from the database, there is the option to build a QuickSearch bar into the list screen itself.
44. There is the option to restrict access to the system to specified IP addresses, either for individual users or individual tasks.
45. There is the option to restrict access to the system to specified time periods, either for individual users or users within specified roles.