7 Replies Latest reply on Jan 3, 2017 2:39 PM by philmodjunk

    Restricted Record Access Problems (better way?!?)


      I am working on a WebDirect solution and am running into a roadblock restricting access (under Manage Security)


      I am trying to restrict access to records to only the user's own records based on a UUID assigned to the user. I have created a privileges set with limited access using a GLOBAL field  (userStoreID) set at login (by a script that looks up UUID and finds the user's home record, setting the global field in the process). Theoretically, only records with a StoreID matching the UUID (userStoreID) global variable would be visible. See below...



      This does not appear to work consistently.




      It appears that the global assignment works (userStoreID) but does not allow the related records to show, resulting in  <No Access>.


      Is there a better way to accomplish this, or am I missing something basic?





        • 1. Re: Restricted Record Access Problems (better way?!?)

          You've only posted what restrictions you've specified for a single table. You haven't indicated what you set up for the portal's table nor how it is related to the layout's table.


          And why would you expect to see any records in the portal on a record from the parent table that the user is clearly not permitted to view? That seems a very strange design here if that's what you are expecting.

          • 2. Re: Restricted Record Access Problems (better way?!?)

            (one step at a time as it were)


            Because the main record is not showing, I am not concerned with the portal at this time. But, FWIW, the relationship for the portal (restriction wise) is identical to that of the main record.


            Because FM is not showing me the main record, of course it will not show me the portal records (though there are none to be seen at the point).


            The general question still remains: If I want to restrict each user to seeing only their own records, is this a rational way to accomplish this (because so far it doesn't appear to work).


            I have accomplished something similar in the past by creating individual Privilege sets (one for each user). I want to make the privilege set generic, which would allow me to create new users automatically.

            • 3. Re: Restricted Record Access Problems (better way?!?)

              Yet I see no evidence in what you have posted thus far that indicates that it doesn't work. Your screen shots appear to show a correct set up and that it is functioning correctly.


              How exactly is this failing from you?


              Do you have a screen shot where the layout does not show "no access" but which fails to show portal records that should be permitted?

              • 4. Re: Restricted Record Access Problems (better way?!?)

                The user shown viewing their own record. They should see the information currently represented by <No Access>

                • 5. Re: Restricted Record Access Problems (better way?!?)

                  After assigning a value to the global field, make sure that a Commit Records is done. I've seen cases in my own testing where changing a value used in the "lock expression" doesn't change the user's access to allow or deny it until the change is committed back to the file.

                  • 6. Re: Restricted Record Access Problems (better way?!?)

                    Tried the commit. No change with WebDirect.


                    Interestingly, I tried this using a FM Pro client and it does work as advertised...


                    So is there something (a bug or limitation) in WebDirect that prevents me from doing this?

                    • 7. Re: Restricted Record Access Problems (better way?!?)

                      If it works in Pro and not WebDirect, that suggests that you should use Report an Issue to report this as a possible bug. But by all means, check every little detail first. Comparing the values of two text fields like you do here will only produce a "True" result if every single character is the same in both fields. The addition of even a return or space will keep this from happening even though the fields will look like they should match when you inspect them. Not saying that this is what's happening here, but this is something to confirm first just to be sure before making a bug report and waiting to see what the FileMaker Techs have to say about this.