Privileges in one file don't work correctly for layout in separate file
Operating system version
Mac OS X 10.7.5
Description of the issue
A privilege set in a file called DTData only allows editing of records in a table when a field in that table called EditRecord = 1.
A script in a file called DTAdmin is performed from a layout based on DTData's table that performs a script in DTData set to run with full access privileges that toggles the EditRecord field between 1 and 0. The script in DTAdmin sets a global variable to Get ( RecordAccess ) and at the end of the script clears the global variable from memory.
After performing the script, which set EditRecord to 1, the record isn't immediately editable in DTAdmin and requires the record to be committed in DTAdmin before the record becomes editable.
I've built an example in FileMaker Pro 11 Advanced and the issue doesn't exist in 11, it only occurs in 12.
Steps to reproduce the problem
Perform a script in DTAdmin that performs a script (set to run with full access privileges) in DTData that sets EditRecord to 1 or 0, based on what the field's value already is (if it's already 1, it is set to 0).
The DTAdmin script must set a global variable to Get ( RecordAccess ) and then clear the global variable after setting the EditRecord field.
Try to edit the record in DTAdmin,
If the script in DTData set EditRecord to 0, the record should not be editable. If the script set EditRecord to 1, the record should be editable.
If EditRecord is set to 0, the record remains editable in the separate file. In DTData it is not editable. Committing the record in the separate file by clicking on the layout background and then attempting to edit the record makes the privileges behave as expected and the "Your access privileges do not allow you to perform this action." message appears.
This is a security hole that allows the user to continue editing the record when they should no longer be able to edit it.
Setting the global variable in the script in DTAdmin causes the problem for a reason I don't understand. If I disable the step that sets the variable, the problem doesn't occur. This seems like a rather obscure bug happening in the security of the file.
I have an example file that I can provide to further illustrate the problem.