04-18-2013 10:17 AM
I'm kind of stumpped here. I have this simple call to the database to enable a label or not and it works logged in as Admin but when logged in as a user it isn't working
My script looks as follows:
Dim strAcctID strAcctID = Application.BasicFunctions.CurrentAccountID Dim strSQL Dim objR2 Set objRS = objSLXDB.GetNewRecordSet strSQL = "Select ACCOUNTID from PSS_ACCOUNTREF where ACCOUNT ID = '" & strAcctID & "'" objRS.Open strSQL, objSLXDB.connection if objRS.RecordCount > 0 then lblCustInMAS.visible = true lblCustNotInMAS.visible = false else lblCustInMAS.visible = false lblCustNotInMAS.visible = true end if set objRS = nothing
I've put msgboxes to track it, and it is pulling the right account ID, I look in the PSS_ACCOUNTREF table and there is a record for that account ID, but after it opens the connection my record count is 0 when logged on as a user. When logged on as ADMIN though it works fine. The only other thing I knew to check was the SystemLX Database Support script to make sure it was released to EVERYONE and not just developer or admin but it was released to everyone. Could someone please point me in the right direction as to where to check to figure out where it is going wrong? It's such a simple script that I have no clue where else to check. This is version 7.5.4 all of the updates if that part matters.
Solved! Go to Solution.
04-18-2013 10:34 AM
The big difference w/Admin and all other users is simple:
The provider NEVER applies any owner/security checks to Admin.
Run SLXProfiler to see what security is applied when you run as "non-admin".
04-18-2013 10:45 AM
Ok, well that gets me a little further. I looked in the database and I do have a "SeccodeID" which I'm not sure where it came from as I didn't put that table in there. Anyhow, for the account I'm looking at it is just NULL.
When profiler gets to the sql call it is executing:
Select PSS_ACCOUNTREF.ACCOUNTID, PSSS_ACCOUNTREF.SECCODEID SLXSECCODEID2 From PSS_ACCOUNTREF INNER JOIN SECRIGHTS S_AA ON (S_AA.ACCESSID = 'U6UJ9AOOOOOP' AND PSS_ACCOUNTREF.SECCODEID = S_AA.SECCODEID ) Where PSS_ACCOUNTREF.ACCOUNTID = 'A6UJ9A001FMC'
So yea, it's trying to apply the user's profile to the SQL call, is there any way to stop that? I don't need it to check securty profiles as any user should be able to view this.
04-18-2013 12:09 PM
04-18-2013 01:26 PM
I populated the SECCODEID of that table with the SECCODEID for "Everyone"
That currently works but I think I've discovered a deeper rooted problem. For some reason it's using that seccodeID for applying the properties to everything on the ACCOUNT table. If the account is found in the PSS_AccountRef table, then it applies the "Everyone" field security policy to all the other fields. If the account is NOT found in PSS_AccoutnRef table then for some reason it's reverting to a read only type policy. Meaning I can't change anything about the account, the save button is grey'd out and if I try and type in any of the fields such as in the Details tab, I cant select a region, do a phone number, anything like that, it's all read only. Why would it pull across the security for the entire account table when all I want it to do is check if the account exists in the reference table
04-19-2013 01:38 AM
Do you need seccodeid on this table (PSS_AccountRef) ? If not (and I don't think you do) go into Architect and delete this column (then you don't need to populate it and the data is secured by the account but can be queried/populate independently.
Also, I suspect this was a cut/paste error - but you appear to have a blank space in your original code:
strSQL = "Select ACCOUNTID from PSS_ACCOUNTREF where ACCOUNT ID = '" & strAcctID & "'"
04-19-2013 12:08 PM
I don't need security, and I thought I could delete it, not even sure why it was there in the first place. I found out my issue was ina completely different form all together, I was doing a calculation on a NULL value or something. I just re-worked how I did it all together and it's working fine now. Thanks for all of the help!