6 Replies Latest reply on Nov 16, 2014 4:42 AM by wfgclapp

    Viewing vs Accessing records via privelege sets


      I'm a newbie and have what is I'm afraid an easy question to answer. I don't think I"m going to like the answer.


      I want to restrict database records to particular users. I've done this using privelege sets except it's not working exactly like i'd like.


      The records that are supposed to be restricted to a certain user are still visable to that user, except all the fields simply say '<No Access>'.


      I would like for the user not to be able to see there are restricted users.


      To restrict the resords I'm building a Custom privelege set and limiting the 'view' capability of records.


      But like I said, the user still 'sees' that there are 4000 records, instead of the 1400 he SHOULD see.


      Thanks for any help!

        • 1. Re: Viewing vs Accessing records via privelege sets

          Welcome to FileMaker.


          You're really asking two questions: How do I get rid of the user-jarring "<No Access>" indicators if a user does a "Find All" command that reveals records he doesn't have access to? And how do I deal with the record counter in the Status Bar that displays the total number of records in the current table and makes it obvious that the user doesn't have access to everything?


          To the first: You can use a combination of Script Triggers and Custom Menus to restrict the found set when a user moves to a particular layout. The Script Triggers can automatically constrain the found set whenever you see an OnLayoutLoad event. The Custom Menu can trap the Find command so that you omit the records the user can't see.


          To the second: You can hide the Status Bar, lock it, and give the user the necessary controls to navigate through the solution using buttons you provide. This prevents the user from seeing the record counter.


          Optionally, you can use either a Separation Model that gives the users an interface file that allows them (via a relationship) to see only their records. This prevents having to script everything and allows you to use the native controls. However, it does mean you're using a separated solution and there are some constraints involved with that (like keeping the security schema properly updated, etc.).


          You can search the forum for previous discussions on these topics for ideas. To get you started, here are a few previous threads:









          • 2. Re: Viewing vs Accessing records via privelege sets

            Thank you very much Mike. You're my new best friend. That is all very helpful. I was beginning to think I'd have to maintain multiple databases. I'm still surprised that FM can't handle this in a more straightforward manner. But...I'm new to this so maybe there's good reason.


            Thanks again.


            Martin Clapp

            • 3. Re: Viewing vs Accessing records via privelege sets

              What you are asking for is not all that straightforward, but follow Mike's advice and you'll get there. One thing you may wish to do—if you haven't already—is add an autoentered field which captures the name of the user when a record is created, as you may need this to restrict them to seeing only "their" records.

              • 4. Re: Viewing vs Accessing records via privelege sets

                Thank you. I'll add that to my list.


                Is it strange to you (as it is to me) that this ISNT straightforward? It baffles me that this isn't inherent to 'permissions'. Makes me think there's something fundamental about the purpose of FileMaker that I'm not understanding. But at this point I'm just playing around with a proof of concept for my company so I still have a lot to delve into.


                Martin Clapp

                Wood Fruitticher Food Service


                • 5. Re: Viewing vs Accessing records via privelege sets

                  FileMaker does not work in the same way as some other database systems with regard to filtering or finding. There's no such thing as a "query", a temporary or semi-permanent object inside the database that creates a subset of the records resulting from the search.


                  FileMaker's paradigm instead relies on a "found set". This is user-specific and merely puts the records that match the criteria in a temporary "bucket" in the user's memory cache. In fact, each window you open inside FileMaker can have a different found set, even when working with the same table.


                  Therefore, the total number of records in the table never changes (assuming nobody deletes or adds a record). That's why your record counter will always show the same total records, whether the user has access to view them or not.


                  Now, there are those who argue that FileMaker could make this more elegant and fix the "Show All" command so the distracting "" indicators aren't needed - in other words, fix it so it works the same way as the Find command (which automatically weeds out anything the user hasn't access to). That's been a subject of debate for some time. You can search the forum for threads that engage in such friendly conversations, if you're inclined, or you can make a feature request to FileMaker to implement such a change.


                  Every programming environment has a quirk or three that requires a little bit of developer intervention for a smoother user experience. This is one of FileMaker's.

                  • 6. Re: Viewing vs Accessing records via privelege sets

                    Thanks mike. I really appreciate your taking the time to walk me through all that. That's very helpful to my understanding of what I'm getting into. Like you said, every programming env has pros and cons, it's just understanding what they are and to what extent you're willing to work around them. I'm pretty optimistic about FileMaker at this point.