Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Major Bug in Record-Level Access Privileges?!


This topic is 7389 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I think I found something kind of bad in FM7 regarding record level access privileges....

If a user is allowed to create records but not to edit them, any records created by that user do not obey editing privileges for any user for the life of the record. However, if a user is given create privileges, but severely limited in their edit privileges (put a 0 in the calc dialog, effectively the same as no edit privileges) then the record behaves as one would expect.

When I discovered this in the solution I've been working on for the past few months, I was quite upset as I thought this could indicate file corruption, and I wouldn't know how far back to revert to correct it. But I created a new file with only one table and a couple of accounts.

Guess what... the problem still occurs in files I've created on two different macs. I'm posting a file here with 4 accounts

root: Full Access

emp: can edit and delete if the billed field is 0

user: can create but can't edit since the boolean calc is set to 0

user_broken: can create but isn't supposed to be able to edit

The password for each account is the same as the username.

Can someone please see if the same problem exists on the windows version? Also, if someone could recreate the file from scratch on a windows box to make sure it's not a platform-specific issue, that would be much appreciated.

Thanks,

Dana

PS. Does anyone know how to go about filing a bug report with FMI in a manner that will actually get something done about it?

test.fp7.zip

Posted

I don't think its quite as big a bug as it seems. I think in FM6 also, if you have create permission but no edit permission, you are allowed to edit the record until the file closes.

In FM7 also, it appears you can edit only until you close the file - but the "re-login" is not simulating "closing the file", so you can continue to edit after re-logging in as root, then re-logging in as user_broken again. Thats the bug in my estimation.

Posted

Doh... forgot about closing the file.... I remember that behavior from v6 now. I expected that the user_broken account would be able to edit until the file was closed, but the part that seems inconsistent is that any other account can also edit the record with no restrictions whatsoever. (At least in the same session)

The reason that this affects me is that I'm using FMServer to host a file that has had kiosk mode enabled. The client FMPro workstations are connected to instruments, and access to the instrument software is controlled by the kiosk. When users "log out" they are just logging into an account that has no privileges to do anything except view a layout that has a relogin script. This is where my problem lies.

I guess the way I should do it would be to have another kiosk "opener" file on each workstation and actually close the file between sessions. I guess my reasons for avoiding that are gone since FM7 doesn't flash the annoying "opening file from host" messages for each file (now table)

I guess another way I could set up the kiosk accounts is not to allow even create access, and then only allow editing through scripts that run with full access. Then I could leave the file open all the time. Or use the method of allowing limited edits and putting 0 in the dialog. Then editing privileges are gone as soon as the record is committed.

Oh well, at least I have options....

Thanks for the heads up on closing the file.

Dana

This topic is 7389 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.