Remember how old IWP had a bad bug in which sometimes, if a user hit the Reload button on the web site, they'd drop back to Record 1 in the found set? I've found something similar in WebDirect.

 

• If you have a table the table has Record-level permissions the permissions are set to a field calculation (for example, RecordVisible = If(Table::UserName == Get(CurrentAccountName) ; 1 ; 0)
• And someone is editing the Schema on a live hosted database
• Then A WebDirect user may get an error dialog "Database schema in use: the operation cannot be performed because another user is currently modifying the database schema.". (which is not unreasonable).
• However, in addition: The WebDirect user will be dropped onto a record in the table, and that record will be completely visible to the user, regardless of the record-level calculations.

 

Note: I'm seeing this in FMS 13.0 v4 but haven't yet upgraded to 13.0 v5.

 

 

Discussion: I agree that editing a live filemaker database is not "best practice" but I also know many of us do it.

 

The main problem here is that WebDirect seems to have logic saying "If for some reason I can't tell if a record is supposed to be viewable, I'll just show it anyway". A much safer default would be "If anything does wrong in record visibility calculations, default to NO".

Further info, I believe I can tell what's happening and trap it:

 

• A script navigates to a layout.
• Tries to create a New Record.
• This fails with a 303 error (Schema in use)
• Which leaves the WebDirect user positioned on an existing record.

 

What should happen:

• The record should not be visible (due to record level security permissions)

 

What actually happens:

• The record is visible, in spite of the record-level security permissions.

 

Fortunately the workaround is fairly easy:

New Record
If Get(LastError) <> 0 then
  exit the layout (or maybe Exit Application to be safe)
end if

 

RecordVisible = If(Table::UserName == Get(CurrentAccountName) ; 1 ; 0)

 

What happens if you just change the RLA calculation to Exact (UserName; Get(AccountName))?

That will evaluate to either 1 or 0 and the RLA calculation will proceed from there?

 

Where did you find the function CurrentAccountName?

 

Steven

What happens if you just change the RLA calculation to Exact (UserName; Get(AccountName))?

That will evaluate to either 1 or 0 and the RLA calculation will proceed from there?

 

Where did you find the function CurrentAccountName?

 

Steven

 

Sorry, I was using Get(AccountName) - just typed it incorrectly from memory.

 

I've done another test, in which I tried something simpler:

 

RecordVisible = 0

 

And yet the record still shows as visible after the 303 error happens.

OK, please report this to FMI.

 

Let me see what further I can determine as well.

 

Steven

First, I'll upgrade to 13v5 since it sounds like there were some WebDirect fixes (though nothing specific about this issue).  

If it's still showing up there, I will see if i can reproduce this in a simple file and pass that on to FMI.

I updated the server to 13v5 and am still seeing the issue.  I haven't yet had time to create a small demo file yet, however.

I've done some more work on this and I can reproduce the problem in a simple test file:

• The file has a record-level permission which sets a record to not visible after 1 minute.
• The file has a script which runs with full access permissions, and creates a new record then navigates to another record.

After a few runs of the script, the record permissions start getting wacky.

Here's a copy of the database for test:

(account = admin password = admin)

Download: http://xochi.com/mike/fm/webdirect/RecordLevelBug/WDTest1.fmp12

And here's a screenshot of it malfunctioning:

You will notice two issues in this screenshot:

• The user can see the value of Record 0001 "SSN" field
• The user can see the entire value of Record 0006, even though the calc cRecordVisible is clearly set to zero.

I don't know, at the moment, what's causing this, but it's probably a combination of:

• using a timestamp calculation in a record-level permission
• using "Run script with full access privileges"
• having the database schema / table editor open while a WebDirect script calls NewRecord

Please post your file here.

 

It’s the same as attaching a screen shot, only it needs to be zipped. The steps how to do this is found here ATTACH A FILE

 

There are several reasons that we want the files posted here, some of them are because, links get broken, links can be spam, the files get removed after the OP gets their solution, etc., Because this is is a learning Forum, often a solution that works for one member can be the answer another member needs. Without the demo file, there is a hole in the process.

 

 

Lee

Hi Lee - the file is available on my website which dates to 1997.  No plan to remove the files, but if I do I'll re-link them.