4 Replies Latest reply on Feb 26, 2015 2:55 PM by TSGal

    Relationship-based record level security behaving erratically, file recovery doesn't detect or solve...

    User19136

      Summary

      Relationship-based record level security behaving erratically, file recovery doesn't detect or solve the problem

      Product

      FileMaker Pro

      Version

      13.0v5

      Operating system version

      Mac OS X 10.10 Yosemite

      Description of the issue

      Experiencing an issue where record level access privileges that are using a relationship are behaving erratically. I'm losing access to records when they get committed, but only for the current session, and only if I create them via a portal. If I create an identical record in a layout based directly on the base table, I do not lose access.

      Running a recovery on the file does not detect this problem, nor does it solve the problem.

      Steps to reproduce the problem

      This is reproducable only in a broken copy of a file I have. The file is apparently damaged, but the recovery process does not detect this problem (there could be other problems that are detected), and doesn't solve this problem.

      The file in question can be found here:
      http://sc.360works.com/SuperContainer/Files/pro/360/broken

      The file has been torn down to only the three tables necessary to demonstrate the issue. All unnecessary tables, layouts, scripts, etc have been removed to eliminate any possibility of developer error.

      the full access login/pass to this file is: 360works/
      the account to reproduce the problem: wobrien@natfas.com/

      From the "System Copy" layout, create a new record in the portal, then click anywhere outside the portal to commit the record. The record will disappear from the portal. If you then navigate to the "security equipment" layout, you'll notice that we don't have access to the record. If you open the Data Viewer, click the lock button and authenticate it, then close it again, you will be granted access to the record. This is the inconsistent behavior I'm talking about. We should be able to see the record but can't, until we either restart the file or simply authenticate the data viewer and close it.

      Here is a version of the file that I created from scratch:
      http://sc.360works.com/SuperContainer/Files/pro/360/working

      the full access login/pass to this file is Admin/
      the lower access login/pass to this file is wobrien@natfas.com/

      This file matches the schema of the first file exactly; however, this file was created from scratch, instead of being torn down from the original. Perform the same steps in this file to see that it is behaving the way one would expect. Consistently.

      Run a recovery on the broken file, then attempt to reproduce again. Same behavior. The recovery process seems to ignore whatever is happening causing this to be inconsistent.

      Expected result

      The expected behavior would be how the "working" file behaves.

      Furthermore, I would expect the recovery process to at least discover this issue, if not correct it.

      Actual result

      Recovery process does not detect nor solve this problem

      Exact text of any error message(s) that appear

      Not Applicable

      Configuration information

      Please see files included in problem reproduction:

      http://sc.360works.com/SuperContainer/Files/pro/360/broken
      full access: 360works/
      low access: wobrien@natfas.com/

      http://sc.360works.com/SuperContainer/Files/pro/360/working
      full access: Admin/
      low access: wobrien@natfas.com/

      Workaround

      None