Does [Read-Only Access] really mean that?

[brian rich]

In the process of reviewing the privilege sets of the users of our FMP11 databases, I came across a bizarre problem with the [Read-Only Access] default privilege set.

 

Users who are in the [Read-Only Access] privilege set can edit the values of global fields.  If you duplicate this privilege set into a new one, then move the users into the new set, they can no longer edit the values of global fields.  (In case you were wondering, the [Read-Only Access] default set allows the user to change their password, a privilege i wanted to remove)

 

So why is does [Read-Only Access] allow changes to global fields, and why doesn't duplicating the set give the same ability in the duplicated set.

 

Confused I am

 

Brian

[Steven H. Blackwell]

This is a known issue.  I recommend never using either of the two default subordinate Privilege Sets.  Always create your own and set privileges according to your business needs.  There are issues with the default Read-Only beyond the one you discovered.

 

Steven

[brian rich]

OUCH!!  Is this documented in Fielmaker's Knowledge base - I couldn't find it.

 

Sorry, this leads to two further questions

• does [Data Entry Only] duplicate correctly or is this also something to be avoided?

• is there a simple way to set up an privilege set which acts like a copy of [Read-Only Access] - allows users to edit globals - which doesn't involve going through all the global fields in the tables in the database to allow user editing just on those?

Thanks

 

Brian

[JerrySalem]

Global fields belong to the user and are reset on each login.  So it sort of makes sense that they can be edited.

 

This behavior can be useful in many situations.  Imagine a database where you have [ReadOnly] access.

In this database you have a filtered portal that shows (for example) invoices.  You can have a global field on the layout to change the view so the user can see paid, unpaid or all invoices by changing the value of a global.

 

Another example would be an interface that controls how a user finds data by presenting a dialog box with globals to fill in.  The the script does the find based on the globals.

 

Both of these scenarios wouldn't work in a true ReadOnly situation.  Not to say that there may be other issues with the built in privilege sets, just pointing out the use fullness of how Read Only is set up.

[rob]

I just stumbled upon this thread and I am sure glad since I set everyone up on the existing data-entry set originally.

 

In related question on duplicating privilege sets, why can't I duplicate Full Access and modify it like I can the others?  I have a situation that I want to stop everyone including full access so they can't create a record in a specific table which should have no records.

 

If I have to re-create the full access privilege set, I suppose I need to use the data-entry one and then make changes.  Is there somewhere that the specific differences in the default settings for a privilege set is listed?  There are so many settings and sub-settings ... If I am going to switch to using only a new 'full access' account then I had better make sure it has all the same privileges as the original.

 

Thank you.

By the way, has anyone checked the following http://fmforums.com/forum/topic/89266-solutions-custom-user-login-template/

 

I am too new to know if this is safe or not but the idea seems cool.

[Wim Decorte]

When you start with a new blank privilege set you start with pretty much everything locked down, which is the way it should be because then you explicitly choose what you want that group of users to be authorized to do.

From a security point of view you do not want to start with a privilege set that allows everything by default and relies on you to lock down what is not required.

 

By the way, has anyone checked the following http://fmforums.com/forum/topic/89266-solutions-custom-user-login-template/

 

 

Haven't looked at that one, but almost to a fault all custom login schemes are less secure by default because they rely on the user already being authenticated and authorized to the database *before* the custom scheme kicks in.

[Steven H. Blackwell]

Please see my comment at:

 

http://fmforums.com/forum/topic/89266-solutions-custom-user-login-template/

 

I echo what Wim said about these ersatz systems.

 

Steven

[rob]

Thank you both very much.

 

So if you wanted to stop an action even for full access, would you suggest giving the developers a privilege set also and setting it so they can do everything but that single action?  Reasoning:  To insist that only one record be entered in a globals table, I can use validation unique but to stop all records for a null table, privileges seems only way and it works but not for full access.  Maybe I worry too much.

[Wim Decorte]

what would break if there were two records in the that "global" table?

[comment]

 if you wanted to stop an action even for full access

 

Full access means full access. There is nothing a user with full access cannot do - including override any validation rules you may have set up. I don't think any user should have full access privileges as standard. If there are users that need to modify the schema occasionally, it would be best to have them re-login for that purpose.

 

That said, I see no reason why you couldn't use field validation to prevent the accidental creation of records in a table, even for full access users.

 

 

EDIT

I see now that this is not only hijacking this thread, but also duplicating another one:

http://fmforums.com/forum/topic/89798-no-records-allowed/

Edited October 6, 2013 by comment

[rob]

I am sorry if I posted incorrectly, Comment, and I honestly did not mean to hijack.  LaRetta answered my question perfectly and it worked great for all users but I couldn't duplicate Full Access privilege set to apply it to developers so I began searching on full access privileges and landed here.  Thiis thread on duplicating privilege set seemed to fit what I wanted so I thought I should ask on this thread instead of starting a new one.  I try to follow the rules, honestly.

 

Wim, I do not know if it would be a problem if there were a few globals.  I am doing what I read to do which is 'null table with no relationships, no fields, no records' so that is what I do, assuming they wouldn't say it if it wasn't important but I don't know its real purpose.  And 'they' are Jeremy Bante and Matt Petrowsky and maybe others I read about, maybe even Todd Geist, more and more using a null table.  

 

This isn't to let any user get into field definitions.  It is to stop even the developer if they 1) accidentally create a record in Null not reading the CLEAR documentation that says it should remain empty or 2) script breaks while developer is running script even just for testing and lands on null and creates the record there in error and they do not notice it.  I read somewhere that it happens with single-record global tables so I thought it might happen here also.

 

LaRetta my apology if you think I was blowing you off; on contrary.  I thought I was properly moving forward with your advice which I respect a great deal.  Someone is free to move my junk to separate thread if I messed up; I do not mind at all.

Oh, I know purpose of null is to open the file on that layout which is safer in some ways but I haven't pinned that down yet.