Rook183 Posted June 7, 2016 Posted June 7, 2016 I am sure this is one of those simple ones… that has me bamboozled for nearly 2 days now. I need to limit access of my users viewing only a limited set of "Company" records after they log in. The companies that they are allowed to see are listed in each respective user's profile. My opening script goes to the user's profile and creates a global variable for each company that they are allowed to view. When I go to the "Manage Security > Edit Privilege Sets > Records > Custom Privileges > Limited > Script", and use any of those variables (e.g. $$Company01"), the records table returns no records at all (i.e. as if there were no matches). When I test the script and use text for any one (or several) of those companies by name (e.g. "ACME PTY LTD"), the access rules work perfectly. To be clear: The global variables themselves are correct. I know this this because they work in other scripts absolutely perfectly, so the variables DO match the names in the field. The script looks like this: $$Company = Table Manufacturer or $$Company01 = Table Manufacturer or $$Company02 = Table Manufacturer or $$Company03 = Table Manufacturer or $$Company04 = Table Manufacturer or $$Company05 = Table Manufacturer In every respect, the variable matches the actual text, but I can only imaging that there is a problem with my syntax? Please advise. Many thanks
comment Posted June 7, 2016 Posted June 7, 2016 This is confusing, because (a) you call a calculation "script" and (b) you don't show us the (real) script that creates those variables. Also, you say that "the records table returns no records" - but if this fails, you should see records with <no access> over them. My guess would be that the values do not match exactly, perhaps because of trailing white-space characters in one of them. I am also puzzled why you use multiple numbered variables, instead of one return-separated list. --Unrelated to your question, but important: you should not use global variables as part of your security schema, because they can be modified by the users. If necessary, use a global field - and make sure users have no privileges to modify it.
Rook183 Posted June 7, 2016 Author Posted June 7, 2016 Thanks for your input. Since I am self-taught I often mix up scripts and calculations – and I apologise for that. However… The table does return no records (rather than entries with "NO ACCESS"). This might be because I also have a script which triggers when the layout loads which searches (by the same global variables) for records that user is allowed to see. This actually works fine (though it is probably clumsy in pure scripting terms). In other words, without even using access privileges, the user can alway only see what I want them to see – except when they invoke quickfind at which point its "open season". I do think however that issue of using a global field is related to my query, since this would be preferable. However, I have numerous variables. For example: One user might be able to see one company, another 2 or 3 or more and these might overlap one user to another. Could you explain a process in which this might be overcome (perhaps start with a "find", then put the user name into a global field?) Many thanks
Rook183 Posted June 7, 2016 Author Posted June 7, 2016 Perhaps you could just point me in the direction of a sensible tutorial on access security as my queries are really beginner queries and should be easily answered by a basic tutorial Cheers
comment Posted June 7, 2016 Posted June 7, 2016 5 hours ago, Rook183 said: I do think however that issue of using a global field is related to my query, since this would be preferable. However, I have numerous variables. For example: One user might be able to see one company, another 2 or 3 or more and these might overlap one user to another. Could you explain a process in which this might be overcome (perhaps start with a "find", then put the user name into a global field?) See if the attached demo helps: UserRecordsByList.fp7
Recommended Posts
This topic is 3356 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now