Sage 100

Does anyone know how to interpret the SY_RoleSecurity table? That's where the check boxes used for assigning Role permissions are stored. Specifically, the Role Maintenance program provides the mechanism to assign permissions for Create, Modify, Remove and View check boxes. While the underlying SY_RoleSecurity table has fields for Create, Modify, Remove, Print and Update - there isn't a flag for View. Create, Modify and Remove flags work in concert with the correspondingly named fields. I checked that turning on the View check box does not effect any of the five fields. Where is View? Bonus question: For those roles without Create, Modify, Remove, and View check boxes (e.g. Inquiry type roles) - how is ""access"" to the role indicated?

SY_RoleSecurity and SY_Task. Those two work together. An inquiry task such as Sales Order Inquiry does not share the same task key as Sales Order Entry. When you give a role ""view"" only access to a maintenance task, a record gets created in SY_RoleSecurity for that task (the task key for SO Sales Order Entry for example is 120000001) with CreateFlag, ModifyFlag, RemoveFlag, PrintFlag, and UpdateFlag equal to zero. When you give a role access to an inquiry task, a record gets created in SY_RoleSecurity for that task (the task key for SO Sales Order Inquiry for example is 120000014) with CreateFlag, ModifyFlag, RemoveFlag, PrintFlag, and UpdateFlag equal to one.

Dan if you're asking the question in the context of scripting then easy way is check the integer returned by oBusObj.SecurityAccess (this is exactly what the system does too): Using Customer Maintenance as an example: View --> 0 same as Inquiry screen w/o being on the Inquiry screen Modify (implies View) --> 2 Create (implies Modify + View) --> 3 Create + Modify (implies View) --> 3 Remove (implies View) --> 4 Modify + Remove (implies View) --> 6 Create + Remove (implies Modify + View) --> 7 Create + Modify + Remove (implies View) --> 7 E.g. I had a Post-Read script for Customer Maint for a new record that auto-set a UDF value for a secondary Customer No. Well the script fired off in Customer Inquiry too because it shares same business obj. To prevent that check if oBusObj.SecurityAccess > 0 and <> 2,4,6 (or check if = 3 or 7). From this point it becomes a confusing mess to explain the rest. If you check any box (Create, Modify, Remove, View), it creates a Sy_RoleSecurity record. If a record exists, the value of the flags (CreateFlag, ModifyFlag, RemoveFlag, PrintFlag, UpdateFlag) are simply 0 or 1, effectively a boolean. These On/Off's are used to come up with one of the integers above. But if you did not check any of the boxes Create, Modify, Remove, View, then a Sy_RoleSecurity record never gets created and you never get to the point of even being able to check SecurityAccess (""you are not authorized"" msg) Now let's say you have 0 access for Customer Maint but do have Customer Inquiry checked. Why can you get in? Well that's a different Task ID altogether. In Sy_RoleSecurity there will exist a record containing your RoleKey and TaskKey = 040000002 (Customer Inquiry task from Sy_Task).

With thanks to excellent insights by David and Alnoor, I've about put this task to rest. I am creating a dynamic version of the Role and User reports in Excel (not a BOI thing), but I never anticipated the Role design to be more challenging than the otherwise normal number of Sage ""gotcha's"" for which we've learned to anticipate. Here's my last question: As Task, Security Events and Modules options are unchecked, their records in SY_RoleSecurity are removed; however records remain for the Default role. This is convenient for knowing which records have been removed since the Default role records are always there. A record present for the Default role and not for another role means the task/security event represented by the record is not available. This is true EXCEPT for Security records! There are no default security records; therefore no way to know which records are unselected for a particular security role. There MUST be a master list of Security roles with which I can relate in my query for a ""master"" list of available ones. Idea? Clear as mud?

Have you checked SY_TaskType? I think the SecurityType field might help you with the identification.

Thank you again David. I am familiar with SY_TaskType and use it to determine which flags relate to which tasks/security events. Amazingly, your post caused me to immediately revisit SY_Task such that I saw that I had it linked as a subordinate table instead of the lead (left most). I have the query working perfectly now.