Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

User Classes for GP Security Access List

Status
Not open for further replies.

bustercoder

Programmer
Mar 13, 2007
96
Hello,

Using a security trace tool and the GP resource (Window display and technical names), I have a main GP Window Description table with the Series, Product, window_display_name, window_technical_name, RESID and USRCLASS. I use this with an outer left join on the RESID to the DYNAMICS.dbo.SY40300 (Class Restrictions) table to get the user classes (USRCLASS) that is restricted. What I am trying to do now is compare the USRCLASS list against the USRCLASS in the DYNAMICS.dbo.SY40400 (Class Master) to see which USRCLASS doesn't exist in the SY40400 at which point I can use those as the ACCESS list. Basically, the end result is I need to have a User Access List. Is this possible? I thought by grabbing a group of userclasses for a partcular RESID and then comparing that list against the SY40400 to see which of those are in the SY40400 but NOT in the SY40300 would product my access list, but it isn't working that way. Do I need to do a union join or perhaps a temp table? I'm using a view for my GP Window Description table and SY40300 which is getting me a restriction list, but actually I need the opposite of this, the user classes that have access. Hope this makes sense.

Thanks,
Buster
 
Hi Buster,

In version 9 and prior, a user's access is actually controlled by the SY02000.
A user may inherit the settings from the SY40300 table when created, or when the user class is modified and it is choosen to roll down those changes.
However a user may have individual settings changed and hence would not match the user class identically.

Regardless of SY40300 or SY02000, there are four cases.
1. Absence of the record ==> user has access to the original window/ report
2. Presence of the record, when the ALTDICID is 0 and ALIAS is 0 ==> denied access
3. Presence of the record, when ALIAS is non zero --> use the modified version of the window
4. Presence of the record, when DICTID = 0 and ALTDICID is non zero --> use the alternate version of the window. ALTDICID indicates which 3rd party product.
5. Presences of the record, when DICTID = 0, ALTDICID is non zero, AND ALIAS is non zero --> use the modified version of the alternate window from the 3rd party product.

If you have records in the SY40300 but there is no matching USRCLASS key field value in the SY40400, would imply that the GP window for maintaining User Classes was not used when the record from SY40400 was deleted, or did not complete correctly.

------
Robert
 
Thanks Robert.
Now, please excuse me while my head explodes.
Buster
 
Sorry Robert, don't kill me for all the posts. I found out that all that's needed is the User Class level, so what I need to do is programatically in SQL, be able to display the user classes from the SY40400 that aren't a match to the user classes in the SY40300 for a particular resid or resids? So bascally through omission we know who has access. As far as when these are updated in GP, we know this is a moving target and are not going to worry about it for now.
Buster
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top