Conditional field access

[capsprojectos]

Hello,

I’m trying to create a way for non-developers users manage the record privilege set.

Picture: a database with multiple users and all of them with different access level. The director of human resources can give privilege to a particular user or a group of users to be able to VIEW, EDIT, CREATE or DELETE some records in a table.

And in this database the only person with full access will be the developer, so the director of human resources must be capable to change the record privilege set at frontend.

I have done 80%, how:

1. Just one privilege set for all users;

2. For view mode I did a script to prevent layout access. I think this is better than the other way (throw security), because don’t waste so many resources and made my database fast. The same procedure to creation and delete records.

3. For edit mode, I found a difficult. There will be users with edit rights and other without, we can limited the edit with a formula, but if the fields have modify privilege all users (with and without edit privilege) can change it fields.

3.1 This is true? The fields access can’t be at modify level to prevent edit mode, so it isn’t possible to prevent edit mode for both users.

3.2 The user with edit privilege are adept to modify that fields, so that fields must be at modifiable mode, and there isn’t any conditional field access formula, to limited this fields.

3.3 It isn’t possible to change the privilege throw script, so I can’t have two privileges, one for edit right and other without edit privileges.

3.4 The only way to do this, is to duplicate all layouts (nightmare) and have a layout for edit and other without edit (block field entry throw browse mode).

Dear specialists there are other way to solve this, how to prevent user without edit rights to rewrite fields with modifiable privileges?

Thanks for the help, best regards

[Vaughan]

You might be able to do something with extended privileges, but you're building a rod to beat yourself with.

Privilege sets should be created for defined user ROLES.

[capsprojectos]

Vaughan thanks for your comment,

In other to explain why developers should have a way to let regular users (non-developers) to manage privilege, I need to make clear some aspects:

1. I work with small business, companies with 8 PCs (TOP), there isn’t any IT developer or good IT skills, just normal workers.

2. Second, they don’t care, they don’t want to know if the backend software is Filemaker or other software. They want to use it, without having to learn too much, my application should be user-friend enough.

To get this, I must think a way to give power to human director, in other, to allow him to authorize users to edit some layouts and the records in that layouts.

With extended privilege I have the same problem, one extended privilege for each layout. And I don’t thinks this solve the big issue, if the user haven’t edit privilege at security level, but field privilege is set to modifiable, he can change it.

1. There is any technique to make a UNDO, to reverse all fields at layout level (with portals in that layout), because this could be a partial solution, if the user didn’t have the edit privilege the layout (records of course), a script will cancel out everychange.

2. As you must detected, I’m not English / American "speaker", neither are my clients. There is a way to change the warning message (edit them to other language)?

Thanks for the support,

[Vaughan]

Controlling access on a layout-by-layout basis is not useful in anything except a very simple solution. One table might need 5 or more layouts as part of its interface to display the data (separate form and list layouts for browse and find, plus a print/preview layout).

One privilege set for all users is not the way to go. Instead determine user rolls and build interfaces to support those rolls. Then create privilege sets to enforce the necessary security. Privilege sets are cheap to build and implement and work well. Typically users only have one roll, or can be made to work with one roll.

At its most simple:

Make a "User" privilege set that allows read/write access to all records and tables.

Make an "Admin" privilege set that allows user + edit selected layouts.

You could make user and admin privilege sets for different departments if required. So there might be "Sales User" and "Sales Admin" privilege sets that allow write access to the data that the Sales people need. They might not need to see all the data that the Support people use so they can be given read-only access to those tables (or denied view access altogether).

In my experience, the higher-up a person is in management the LESS privileges they need in a database. The director will quickly tire of the need to authorise users to do things.

If you persist with your original pans then extended privileges is the most secure and appropriate method for assigning the ability for users to perform actions. You will then need to include a conditional in the navigation scripts and privilege set that looks for each extended privilege code in the current user's extended privileges.

Note that the Get( AccountExtendedPrivileges ) and Get( CurrentExtendedPrivileges ) function returns a paragraph-delimited list of all the extended privileges the user has granted to them. When checking for a particular extended privilege use patterncount or filtervalues to check for the privilege, not an equality.To look for an extended privilege called Sales:

not IsEmpty( FilterValues( Get( AccountExtendedPrivileges ) ; "Sales" ) )

Patterncount( "¶" & Get( AccountExtendedPrivileges ) & "¶" ; "¶" & "Sales" & "¶" ) > 0

Position( "¶" & Get( AccountExtendedPrivileges ) & "¶" ; "¶" & "Sales" & "¶" ; 1 ; 1 ) > 0

Just using Get( AccountExtendedPrivileges ) = "Sales"; will fail because Get( AccountExtendedPrivileges ) is likely to return:

[fmpapp]¶[fmrestorelogin]¶Sales

Making a user-editable security system is extremely complex, a huge amount of work, and usually very insecure.

[capsprojectos]

Thanks Vaughan for your post.

I will try to counterargue your arguments, it will be like David (me) and Golias, but I will try to explain my point of view.

Let’s use your example, but with a large scale (1000 layouts, print scripts, …) for micro enterprises (5 workers).

1. Your first argument:

One privilege set for all users is not the way to go

.

1.1 OK, I agreed with you. So, you have a junior salesman with view privilege (can see the record, but can’t edit). One privilege for this group (juniors). After two weeks, you see potential in this guy, and you promote to salesman (now he can edit records), second privilege sets – salesman.

How to do this, without losing or store the password?

1.2 And how to solve the update issue? If you need to update your UI, how to do this without losing the accounts and passwords (with no use of RefreshFM or other heavy solution), you can’t do this, because when you replace the old file, you will lose the account because the new don’t have those.

The solutions is to do a separation model, but is a pain to create all privilege sets. And I think in this model, the best way is to create the same log in account for each file (UI + DATA) and make a relogin for datafile where accounts are saved.

1.3 It’s hard to manage all extend privilege in a big solution, because each layout can have special specifications. And they must have a good name rules, because we must remember each time you update a script the name of that extend privilege in other to make the wheel spinning again.

There is a solution for manage privilege from Matt Petrowsky, but for a complex solution like mine where can be group of access, special users and with special privilege is hard to do this with extend privilege.

My way was to create a global field, with read privilege and in that field you have a list with values for each layout: YYYN¶ YNYN¶ YNYN.

This signify for the first layout id, this user or group have view access (Y), edit access (Y), create (Y), but can’t delete that record (N).

Vaughan:

Making a user-editable security system is extremely complex, a huge amount of work, and usually very insecure.

Where is security hole, in this global field? You can only change throw script, it isn’t possible to modified this field without full access privilege.

And if you want to tie more the security, it’s possible to limited access at record security with some pattern, if, case and GetValue ( global ; Get ( LayoutNumber )).

The only problem if you do this, FM becomes very slow. In my tests, with this formula in the edit limited access, FM first reads all records like find then shows them. Doesn’t search in view mode, but in all records. So makes very slow all the process, the best way (I think) is to do this at script level.

1. So, in my process with script level where is the security fall?

2. And the solutions for my first question, how to prevent user without edit rights to rewrite fields with modifiable privileges? If they haven’t edit rights, why does matter if the field have modifiable or view only.

[comment]

Vaughan's suggestion to use extended privileges will not work in your case, because extended privileges are assigned to privilege sets, not to individual accounts - and besides, you need a full-access account to do that.

The best solution, IMHO, would be to have a finite number of privilege sets with pre-defined levels of access. Promoting (or demoting) a user is done by deleting their existing account, creating a new account with the new privilege set, and assigning a temp password which the user must change at the first login. All of this can scripted and executed by a user without full-access privileges.

Any other method, IMHO, would require giving everyone zero privileges to start with, then checking what they can do every time they try to do something - IOW, slow and cumbersome.

[capsprojectos]

Comment, thanks for your comment.

First solution: It's a good developer idea, but have a disadvantage for the user, it's hard to explain why he must change his password. What will he think about it, there was a break in my account? There isn't any IT department to explain this, and each time the director of Human Resources change the user privilege access, the user needs to change the password.

Why not my solution, a global field with view security privilege for that field. And to solve the condition field access duplicate all layouts (errrr) and remove the browse entry.

At this moment filemaker developers and users are wishing for new features. So I will pray for condition field access in the new FM 12, because i don't see a solution for this case.

[comment]

I don't really understand your solution, so I cannot comment on it. In general, it's difficult to write your own security schema AND make it truly secure.

it's hard to explain why he must change his password.

For the same reason he needs to return his key to the junior executives bathroom and sign for a card to the senior executives lounge...

[capsprojectos]

Comment thanks for your post,

I will give you just one example, if you want more cases I reveal an endless situations.

The salesman wants to print a layout and he don’t have permission to do that, so he should ask his director to authorize this. His director have a fat ass and like his chair a lot, so he will give a temporary approval to his salesman to print this task.

(Can be multiple cases: view, edit, delete, export, create)

REAL SITUATION, REAL PEOPLE.

Developer view: I must transfer this account to another privilege with print authorization, in other to do this, I delete and create a new account for that user. I don’t know if this is possible with that user online, but I will say OK (not a big issue), after 1 minute or the print task I need to delete and create another account for that salesman. So in a minute the salesman lost his password, one or two times! And i also don't know if he needs to relogin each time, It will be great for him.

If he must return the key of the bathroom each time, like you said, he doesn’t go so many times, it’s a good productivity rule, by the way. I must reember this!!

But In this example what do you say to the salesman, if his boss doesn't want to go to your computer ? Take a photo.

Real life isn't back or white, an if calculation doesn’t work for real cases. Because you can have privilege to print your schedule (extend privilege) but not for the clients records. Now image, you want do this in a big solution with 200 layouts.

[comment]

I don't know of a good way to enable your fat-ass director to give a one-time authorization for the salesman to do something he (the salesman) is not ordinary allowed to do. Unless you want to do what I called "slow and cumbersome" earlier.

Or maybe you could find some middle ground, i.e. allow for a limited number of actions to be authorized by changing the data in the user's account - and prepare scripts for these actions. IMHO, extending this to layout/field access would be sheer madness.

[capsprojectos]

Thanks comment,

I’m doing the “slow and cumbersome" method, but I’m facing a big obstacle an way to make modify field non editable.