5 Replies Latest reply on May 8, 2012 2:33 PM by nvandenburgh

    IWP and custom privilege sets


      I'm using FM12 and FM12 Advanced server and IWP. I have a solution that works fine with the FM12 client, but buggy in IWP. In my file I have a custom privilege set that won't allow users to edit a record unless they were the creator and that a lock field is empty: Get ( AccountName )= record creator and IsEmpty ( RecordLock ). If this statement is true users can edit a record and if it fails they can not edit the record. This works perfectly in FM11 and 12.


      Using IWP on FM12 Server advanved the following happens:

      Once the record lock script runs and enables the lock field users can still edit the record even after it is committed until they log out and back in and then they are unable to edit the record.


      This has me stumped. Any ideas?

        • 1. Re: IWP and custom privilege sets
          Stephen Huston

          I suspect that IWP is caching the permissions test result the first time it is tested via the browser.


          This is similar to the need to log out and then log back in in FMPro if the user's privileges are edited while they are already in the file. FMP captures the privileges for the session as well, but it runs the test each time it is needed. However if the Test itself changes while they are logged in (not the data results, but some actually edited the permissions), only a relogin will assure the new privileges are in force.


          In IWP publishing, cached permission info may be more persistent during a session that in FMPro, including the results of the specific test, not just the test itself.


          That is my suspicion based on what you describe. If this is so, the solution would require refreshing the browser cache, which IWP does with new sessions, but is otherwise invoked by the user if they do a browser refresh. I do not believe any FM script routine will accomplish this.

          • 2. Re: IWP and custom privilege sets

            Makes sense to me, but I can't believe there's not a work around on this.  The only thing I can think of is having 2 sets of recrods, one they can edit and then a script that will post final results to a set they can't edit.  Then delete the one they can edit.

            • 3. Re: IWP and custom privilege sets
              Stephen Huston

              I just checked the compatibility of various script steps for IWP, and though the simple Flush Cache to Disk step is not IWP-compat, the script editor and the help file both claim that the Refresh Window with flush caches is IWP-compatible. I had not expected that, so it might be worth a try. Maybe a "Save" button to get the user to manually run it after they edit the record?


              Seems worth a try, although I have doubts of whether this script step is as compatible with IWP as it claims, and whether the browser cache will be affected by it.

              • 4. Re: IWP and custom privilege sets

                I have tried adding this step to the lock script and it does not work. ;-(

                • 5. Re: IWP and custom privilege sets

                  Fixed the issue by adding a create new record script instead of using the standard new record option.  The only difference is I'm using a global to transfer related data from one field to another and there is a script pause before the record lock script runs.  Still seems buggy to me, but it solved my issue.  Thanks to all that read and replied.