I am working on implementing the use of a PREFERENCE table in my billing solution. I have create a preference record for each user. Each user is created in SECURITY. When they log in, I want them to only see their record in PREFERENCE. As to other tables, I do not want any restrictions. Every user should be able to see any record. Can someone give me a hint to get started?
Then you just add a field with users Account name and when you go to that layout you do a Find to get to there record. Then you add a Custom Menu that are not allowing search or go to other records in that layout
might be useeful for the calc to be
Get ( AccountName ) = PREFERENCES::account or Get ( AccountPrivilegeSetName ) = "[Full Access]" which will allow an admin to see the records...
Rather than rely on Get ( AccountName ) or Get ( AccountPrivilegeSetName ), set a global field or a global variable to those in your startup script:
Set Field Preferences::AccountName = Get ( AccountName ) //make that field a global.
If you use Get ( AccountName ), that'll get evaluated over and over, whereas the value of a global field or variable will be in memory.
In my startup scripts, I used to go to a table to find the right user and assign values, but I don't do that any more. I use ExecuteSQL to find the user since it can be done without going to any other layouts. If you use Get ( AccountName ) with ExecuteSQL, be aware that Get ( AccountName ) returns exactly what the user entered when logging in...it's case sensitive. I use Lower ( Get ( AccountName ) and make sure that the stored account name is also lower case (using an auto-enter).
I don't think evaluating Get ( AccountName ) takes up more resources than evaluating a global field or variable.
OTOH, if you put the account name in a variable, you run the risk of having the variable modified by a malicious user. Same thing could happen with a global field, if you don't take adequate measures to prevent it.
So: no reason to do this, good reasons not to.
I am not concerned about malicious intent, not in my scenario. Mostly I am using this as a learning tool to expand on my understanding of security. This will mostly be file that is used by my ONE co-worker and myself. The Accounting Manager will have access. The purpose of the solution is to do billing to our catalog customers. The Admin for our accounting software does some billing in a related company, so he might insist access. Currently he does not have FileMaker installed.
I do appreciate all of the assistance. I will "play" with this later this afternoon. I showed the Accounting Manager what I was developing for assistance in the billing. He was very pleased. What I develop are tools to supplement the accounting software.
I have this set up in the Preference table. User is requesting the same info as AccountName I just used jargon for end-user understanding. This is the set up:
But this is what I see. AccountName is blank.
I did manage to tweak the permissions. I created AlmostFull instead of [Full Access]. Took a bit so that I can see scripts and layouts. Initially all were locked out to me as ap versus Admin. This first time a user logs in, they are taken to the Preference table to fill in their information.
But I still cannot get the AccountName to work.
You want to store the account name the preferences are for in the field. You then compare the stored account name with Get(AccountName) in the security settings to allow viewing the preferences.
I am able to come back to this. There are three fields that are needed.
Directory is where the User wants to have working files stored on his machine.
Name is the Full Name that would show in the Email signature block.
Title is the User's Title to show in the Email signature block.
After a person logs in, I need to copy their information to Global Fields.
I am guessing in my opening script, I need to do a finder on USER equal to Get(AccountName). Then use Set Field to set the global fields to the User's preferences.
You can choose to use Global Fields or else Global Variables. I would go for Global Variables
It's a little unclear whether by 'SECURITY' you have a table named that, or you are just referring to FileMaker accounts created in the Manage Security area. I'll assume they're just FileMaker accounts - but this should also work if you actually have a security table, with 1 record per account...
each user account has an account name, which you can evaluate for a logged in user through the function Get ( AccountName ) which we will user in a moment...
On your Preferences record you need something to identify which account each record is for, i'll assume a field named "account" which contains the account name of the user.
1. So, in the file now choose File -> Manage -> Security
2. Go to Privilege sets, add one if not already (otherwise use your existing one).
3. In privilege setup, under "data access and design" choose the records drop-down and choose 'custom privileges'
4. locate 'PREFERENCES' in the table list, highlight it, then at bottom under 'set privileges' area, choose the view drop down and choose 'Limited'. This will open the calc dialog.
5. Your calculation will be something like: "Get ( AccountName ) = PREFERENCES::account" , so in other words the logged in users account must match the account name of the preferences record in order to view it, otherwise they have no view access.
you can repeat that for edit/delete etc as required. For all the other tables in the privilege set just set view/edit/delete/create/field access etc to "All"