Scenarios

Rebuild User Is Not Working

The vast majority of security issues will probably come down to the need to "Rebuild Security." If this tool has been launched from either the Manage Users or Manage Security Roles screens but does not seem to be taking effect, the next step is to check the Job Manager to see if the tool is stuck waiting to be processed by Workflow. If that is the case, making sure Workflow is running and that the "REBUILD_SECURITY" model is active is a good first step. Once the model is functioning again the security can be rebuilt. Alternatively, the Rebuild Security screen can be used to rebuild security directly, getting around any Workflow usage or issues.

User Lacks Expected Menu Access

Using the Role Simulator, it is possible to recreate the menu access of a particular role combination. This is a good way to not only test the user's current security but to also test the impact of other roles on their menu access. If the role simulator shows their menu access to be what should be expected but they are still unable to view the information in BusinessPlus, most likely the fault lies with one of the areas where the security output is stored.

• In the Application Server components of the software, the menu access is read in from the Role Output table. If this is incorrect then the Role Output should be rebuilt using the "Rebuild Security" tool from the Manage Users screen.
• In BusinessPlus the Menu is actually read from the User's XML. This is stored in the IFAS_DATA table and also cached locally within the BusinessPlus worker threads. If the security looks correct on some servers but not all then most likely the IFAS_DATA information is correct, and the incorrect servers simply need to be flushed. This can be done from the "Monitor Servers" screen in the Administrative Console. Otherwise, once again using the "Rebuild Security" tool should help to reset the IFAS_DATA XML representations.

User Lacks Expected Data Access

The Role Simulator is the best way to test a user's access to a particular table. The simulator not only factors in the access to a particular table but access to the Common Security items involved as well. Once the user has used the simulator to return a Where clause based on role assignments and the desired access (Read, Write, Update, Delete, Execute), that Where clause can then be used in an SQL query against that table to see just how many rows would be returned.

For the most part, a user's Data Access security is all read from the US_ROLE_OUTPUT table. This table not only stores whether or not they have access to a particular table but what the filter will be on that table. If this data does not match the user's actual access, then a "Rebuild Security" is required to get the table rebuilt correctly.

Some examples of Data Access usage: