User access

How do I write a script to allow each user to only view their own record. For example, i want john to view only the records with employee ID = john.
treynathanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

D0NCommented:
I would set up a relationship which displayed only the records created by Status(CurrentUserName).
0
Mariano_PetersonCommented:
You have to be much more specific about what you are trying to accomplish.  Without more details, it is extremely difficult to guess what the appropriate solution is.

Do you mean the user will be searching and browsing records, and the results of all finds should be limited to only show records where employee ID = john?
How about after performing "go to related records"?  Should the resulting set be limited also to only show john?
How about when performing a find all?  Should the resulting set be limited also to only show john?
How about scripted reports that perform automated finds for reporting data?  Should those reports be filtered to only show john?
How do you determine the user's name?  Do you have a login system, or are you relying on the application preferences (status (currentUserName)?

The best bet (and easiest method) will probably be to set up a password that only allows the use to browse a limited set of records.  Then, in the definition for the limited set, you can configure it so the user can only view records assigned to themselves.

--
On a seperate note, key fields (such as employee ID) should never be based on significant data like the user's name.  Rather, keys should _always_ be given insignificant values such as serial numbers.  If you use the user's name as a value for a key field, you'll have to be very careful about when and how people change the user's name.  Also, significant data is frequently subject to change - which puts the referential integrity of your data at high risk.  On the other hand, insignificant data will never change, so the referential integrity of your data is much more secure.

It really sounds more and more like you are just beginning to learn about databases (which is a good thing =) ).  However, if you build a database before you have any understanding at all of database design principles, you will likely paint yourself into a corner where the database is not flexible enough to meet your business needs, and more importantly, you are likely to build a database that will loose and/or corrupt data because of design errors (like using the username as a key).

I highly recommend you read a book about database design before you proceed.  Just read the first chapter or two of any SQL book.  There are books on plain old SQL, or you can get a book on SQL Server or Oracle or other.  No matter the book, the first few chapters are almost always the same.

Good luck,
Mariano
0
treynathanAuthor Commented:
I want to go for the best bet. I just want John to see only the record relating to him ( i mean the record with his his ID) when he logs in using a password. Since you said using insignificant values such as serial number is better. then maybe i'll using keys like employee ID. And so now, how do we go from here?
0
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

Mariano_PetersonCommented:
How are you currently identifying the current user?  Is it just by status(currentusername)?  Status( currentusername) is derived from the data in the user preferences (Edit > Preferences > Application).  The problem with that is that anybody can just change the user name to that of somebody else.  Then, they'd have access to the other person's record.  So, status(currentusername) is not secure.

What you need to securely identify the user is a secure login module.  Chris Moyer and Bob Bower's book, "Advanced FileMaker Pro 5.5 Techniques for Developers", has a chapter or two devoted to this topic, and the CD has a sample login system included.  The login system on the demo CD uses about 8 files and is rather complex; however, it is a robust model.  I recommend reading about it, then implementing a simpler and scaled down version if that is all you need.

The topic of building a login system is too long to write about here.  However, the main idea is to get the user to enter a name and password which you check against user data stored in the database.

For now I'm going to assume you've logged the user in and have captured that employee's ID in a global key field, keyg_employeeID.  I'm also going to assume that in your file you have a key field named keyf_employeeID, which marks that record as belonging to a particular employee.

Given that, you can set a password privilege that only allows the user to browse his/her own record.  You can set the password privileges by going to "File > Access Privileges > Passwords...".  

Under "Browse records:" choose "Limited".  In the calculation, enter "keyg_employeeID = keyf_employeeID".  Make the same entry under "Delete records:".  This now prevents the user from browsing or deleting any records that don't have their ID in the keyf_employeeID field.  If the user performs a find, the results will be filtered to only show those records that the logged in user has access to view.  You'll have to repeat for every table (file) in your solution.

There are other ways to do this, perhaps more elegantly; but this is the easiest, fastest, and most secure way to implement it.  An alternative method would be to script every action in the user interface (omit, delete, find, etc.) so that the scripts always check and filter the record set.  This can have advantages, but is a massive undertaking.

-Mariano
0
D0NCommented:
If you've got a relatively low number of users, for a much simpler approach, you may want to explore the possibility of giving each each his/her own database.  This mechanism absolutely keeps the data separate and secure.  Of course, the manager would have access to them all and could combine them all for analysis/reports etc.
0
lesouefCommented:
My way:
When the database is opened, I ask a login/passwd to user.
The users's name is stored in a global field.
Then you disable manual menu edition in the passwd parameters.
Do a script for new records and insert the users's name automatically.
Do a script for 'find' and 'find all' which automatically appends the users's name to the find conditions before executing the find operation.
0
Mariano_PetersonCommented:
D0N has a good idea, but it brings up certain important drawbacks.  

Distributing seperate files to each user will significantly reduce the scalability of your solution - that is, it won't grow as your user base grows.
You'll have to worry about synchronization issues.  If each user has his/her own set of files, they won't be able to see the data on another user's database (they'll be on an isolated on a data island).
You'll also have to address file confusion issues.  If there are multiple copies of the a file with the same name on a network, FileMaker can get confused under certain specific circumstances and actually open and use one of the other files.  The best bet around this would be to rename the files specific to each user.  However, renaming files also opens up another can of worms.  If you're working with FileMaker Developer renaming files is a simple matter.  If you're using standard FileMaker Pro, you should not rename your files if you can at all avoid it.

-Mariano
0
Mariano_PetersonCommented:
There is no script you can write that will limit the user to only view their own records.  

What you desire reaches much beyond a single script and is better described as a methodology, something to be considered during the architectural design stage of your application.  This must be implemented through a series of scripts, layouts, fields, tables, and passwords.

Again, Chris Moyer and Bob Bower's book, "Advanced FileMaker Pro 5.5 Techniques for Developers", has a chapter or two devoted to database security.  I highly recommend you read so that you have a better ideas as to what is involved.

-Mariano
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
treynathanAuthor Commented:
thanks.. let me try all and shall get back to you guys very soon. mariono's suggestion sounds more familiar. Ron's can be tried too as i have relatively low number of users ( 9 users )
0
treynathanAuthor Commented:
I used mariono's method.. it worked fine.. but now i have multiuser access problem.. i created a stand alone database (deploy) using filemaker developer tool and shared it over the network. It can be accessed from the user's own desktop via shortcut created from the database workstation. Only one user can access to the database at a time.. i've already set the file sharing to multiuser but a message keep showing up telling me that it is a single user file. However, the fp5 files can be accessed by multiuser over the network. help!
0
lesouefCommented:
This a one of the limits of FM runtimes, single user at a time, and cannot open files shared by a FM server, can only import files.
So, I am afraid you need you need FM server.
However, you could use another engine so store data, and use ODBC for instance to access data from a runtime. Not very handy. If you use an external plug-in for SQL operations, you must check if it is compatible with the runtime solution, some don't. I guess you do not want to get involved in this now, so I think the FM server would be the best. No dev is required. Your existing files can be used "as is" by a FM server. And you can test it, they have a 30 days trial version fully operationnal.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
FileMaker Pro

From novice to tech pro — start learning today.