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

Issue report by Will Slaughter

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/<no password>
the account to reproduce the problem: wobrien@natfas.com/<no password>

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/<no password>
the lower access login/pass to this file is wobrien@natfas.com/<no password>

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/<no password>
low access: wobrien@natfas.com/<no password>

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

Workaround

None