1 Reply Latest reply on Sep 24, 2015 10:16 AM by jakebutt14

    FM Pro vs. FM Adv - Security Permissions

    jakebutt14

      Hopefully someone else has encountered this problem before...

       

      We have a solution that was designed in FM Advanced and has three security privilege sets: Admin, Data Entry, Read-Only (these are all custom-made security accounts, not the stock accounts). All three of these privilege sets are set up for external authentication. We have no issues logging into any of the sub-accounts for these privilege sets.

       

      The issue that we have encountered has to do with the actual permissions of these sets. The Admin and Data Entry sets are allowed to delete certain records, which works completely fine when using FM Advanced when logged in using either of the privilege sets that allows for record deletion. However, when someone is using standard FM Pro and tries to delete the same record, they get the standard FileMaker error that the user does not have permission to delete the record. To reiterate, the error message that we get is not scripted, but at the FileMaker permissions level.

       

      We have even tried using FM Pro and FM Adv on the same computer, which yields the same results (can't delete with Pro, can with Adv).

       

      Has anyone ever encountered this? We have tried using multiple accounts to create/delete records, and everything works fine in FM Adv, but fails when using FM Pro. Same holds true for scripted deletions. Is this a bug, or am I unaware of something?

        • 1. Re: FM Pro vs. FM Adv - Security Permissions
          jakebutt14

          Already answered my own question.

           

          We use SyncDek for auditing purposes. I realized that a few steps in our startup script, which basically check to see if the required plug-in is installed, has been disabled. This meant that for installs of FM (I'm now assuming Pro or Adv) that were accessing our solution for the first time were not having the plug-in installed, which was nullifying the calculations used by SyncDek in the security settings (because it couldn't find the functions used by SyncDek).

           

          Thankfully, all it required was enabling those script steps in our startup and everything is working fine now.

           

          Clearly, my "newbie" description is accurate.