8 Replies Latest reply on Apr 14, 2011 3:49 PM by PaulBostwick

    Record level access set but can not preform a find

    laneystewart

      Title

      Record level access set but can not preform a find

      Post

      FM 11 database created on a MAC hosted on a FMS 10 on windows.  I have set record level access to a database that contains lists of students and their employment forms.   Each department can see only the forms from their department.  In the Open script I use the Get (AccountPrivledgeSetName) to match the department # in a table.  I also want the script to find only the records that  person has access to (it fails) and then show them the records in a portal.  When it tried to preform the find in the table that the student records are in, it comes back with a error that no records match this find criteria.  Why is this??? If I cancel the script I have all the records in it and many of them have <no access> but the ones with the correct department can be seen.  I have read many posts that this should work, is this a problem with FM 11???  I have attached my code.  Any help would be greatly appreciated!!!!

      FM_code.jpg

        • 1. Re: Record level access set but can not preform a find
          philmodjunk

          The only possibility that comes to mind is that there is some difference between the value in Div/Dept# and the value of Get ( AccountPrivilegeSetName ). Do you have filemaker advanced? If so, use the debugger and dataviewer to step through this script and check the values of both right at the point you set up your find request.

          Your field name: Div/Dept# makes me cringe a bit as that / could cause problems if you use it in expressions.

          • 2. Re: Record level access set but can not preform a find
            laneystewart

            I checked with Script debugger and the data is correct.  It appears that I can not preform any finds with the record level access restricted.  I tried to find a record using the * in the ID number (everyone has one) and it says that no records match this criteria.  I am going to try to restrict the edit functions but release the view functions in the security to see if this will allow people to view their records.  If anyone else has had this type of problem, let me know how you fixed it.  Thanks!

            • 3. Re: Record level access set but can not preform a find
              laneystewart

              I have changed the record access view privilege back to yes and changed the edit records privileges to limited by the following(and changed the field name):

               ${Div_Dept} = Get ( AccountPrivilegeSetName ) and I can see the records that I need to.  


              I have added a find to the script to find the records for just that department so they only see their own records.  It works in the client but when I go into IWP to sign in the find will not work.  Is there a known problem with IWP and the script step Get (AccountPriviledgeSetName)??  It shows that all script steps are Web Publishing compatable but Is there any type of script debugger for IWP????  I really need this solution to be done so any ideas would be greatly appreciated!!!



              • 4. Re: Record level access set but can not preform a find
                philmodjunk

                In IWP, you might try temporarily adding a script setp that uses Set Field to copy the result of Get ( AccountPrivilegeSetName ) to a text field you've placed on a layout where you can see it immediately after logging in.

                • 5. Re: Record level access set but can not preform a find
                  Wimmachine

                  Not sure if this will help but..  The Get(AccountPrivilegeSetName) function originated in FMP11.  Prior to 11, this function was Get(PrivilegeSetName).  I'm not sure why the function was changed, but since you are hosting the DB using FMS10 this may be the cause of your problem.

                  • 6. Re: Record level access set but can not preform a find
                    PaulBostwick

                    I am seeing another related (pretty sure) problem with

                    get (accountprivilegesetname) vs get (privilegesetname) and FM 11 vs FM 10 (respectively)

                    I'll post it more fully elsewhere but in outline. I edited a script in FM11 on a served database and used the

                    get (accountprivilegesetname) function as an element of an IF in the script.  Worked great. Victory Dance... until my FM 10 users run the script and it ignors the result and they get dodgy outcomes...

                    Boils down to me opening the script under 10 and seeing the <function missing> (or however that is put inside broken calculations) in the script. So the two version of the get function: get (accountprivilegesetname) and get (privilegesetname) do not go backward. but plain 'ol get (privlegesetname) does go forward...

                    So I re wrote the calc with the old version of the function name and 11 and 10 now seem to behave as expected.

                    • 7. Re: Record level access set but can not preform a find
                      philmodjunk

                      This was a new function added in FileMaker 11 to address a specific weakness that must be allowed for when using Get ( Privilegesetname ). If the Run with Full access option is selected for your script, get ( PrivilegeSetName ) returns "[Full Access]" no matter what account was used to open the file where Get ( AccountPrivilegeSetName ) will continue to return the user's privilege set name.

                      PS. Really old thread like this no longer pop up in the Recent list and thus are easily missed. It's better to start a new thread when the date of the first post is more than 3 months old. You can always paste a link to the original thread in your new post if you need the reader to refer back to the original thread.

                      • 8. Re: Record level access set but can not preform a find
                        PaulBostwick

                        Hey Phil.

                        That is a good formulation of why they changed the function. (the ambiguity was not interferring with my use of the old function so I am not enjoying the upside of the change :^)

                        As for posting to the old thread I figured that since the original posters got email pings from it then they'd notice it.

                        I am trying to fomulate a fuller description of how the change impacts a mixed version environment and thought if it has been written up elsewhere I might find it in the meantime or get pointed to it based on my post on this thread.