" Is this true?"
And it will work across all layouts. Any find performed by the user or the script will automatically omit records the user is not permitted to view.
But some actions like Show All Records can still put these records in the current found set but covered by "no access" screens. Thus, you'll still need to put in some interface design to keep that from happening.
I recommend creating a small test file where you test such issues before trying it out on your main solution. Such a file can have scripts that use re-login to easily change privilege sets.
This sounds like the right way to go for sure. I will take your advice and test behavior on a sample file. Thanks also for the tip about re-login script step. I'd forgotten about that one.
Interesting choice by FMI to display "no access" screens instead of simply omitting upon a Show All Records step. Maybe I'll understand their rationale after playing with this a bit.
"Show all is just one example of how a script or user can change the found set without performing a find And thus you can get records covered with the security screen.
But you can prevent this with custom menues thst either do not have these menu options or that replace the option with a script that keeps "no access" records out of the found set.
Thank you I am having the same problem but I am not as savvy as Dean. I would be grateful if you could explain the mechanics of how to do this. I just want the particular user to see only the records that have been created by him.
Which part of the issue?
Setting up custom access privileges?
Designing the user interface to steer users away from seeing "no access"?
We do this with users internationally, but via desktop FM Pro rather than WebDirect.
We use custom privileges and scripting to allow users to log in and be returned their own set of records.
I've not done anything with WebDirect so don't know whether it is different, but the problem we have is that all records in a table have to be downloaded to the user before it is then filtered by the privileges and scripts, and with thousands of records this can be very slow on logging in. Sometimes 10+ minutes.
I'm yet to find a solution for this - what Filemaker needs is a way to filter what comes down from the server before it reaches the user.
There can be performance issues with Record Level Accesss.
One thought that comes to mind for this specific issues is to not rely solely on record level access to keep unauthorized records from view. Use it as your "insurance policy" that if users somehow find a way past your interface design, they still can't see data that they should not be allowed to see.
So you might include find criteria that also limits the records returned by the same criteria specified in the record level access expression.
Probably I will stick with my original plan of having a separate file for every user and have an admin file that collects the information from all the user files. Any comments on this?
That's a terrible idea. Negates the whole point of using a dbms.
Actually, it sounds like a commonly used method when the individual users are collecting data on mobile devices and "synching" the data back to a server.
There are tools by third party developers that can help you set this up. But there are draw backs as well so look before you leap.
Thank you, I think probably it will be better to restrict view to records they have created rather than separate files, although the database contains highly confidential medical records and I wouldn't like to have problems with security.
Going back to my original question: How do I set the privileges to show only the records for only a particular user and what scripts do I need?
I understand it might be a long explanation. Is there somewhere I can find this detailed information?
1 of 1 people found this helpful
Take a look at this screen shot. It's an example of how to do it. I tried to show all the cascading dialogs that FileMaker unfortunately requires you to navigate through in order to do what you want.
In this case, the records will only be visible for the user when that user's account name matches the value in the "customer" field. Other records will still show up but with "NO ACCESS" or something like that instead of actual data. If you want to filter out those unsightly "NO ACCESS" records, you'll have to use other techniques that Phil alluded to above.
Thank you Dean. It works very well, the only problem is the annoying "No Access" screens and I cannot see Phil's method to suppress them.
Any find performed by either the user or a script will automatically omit "no access" records from the found set.