Denying Access to Layouts

[fbugeja]

I am a teacher developing a database for staff use at the school I teach at (Sydney, Australia). Given that sensitive info about students may be stored, I want to limit access to certain layouts.

When a teacher clicks a button that would normally take him to another layout but is denied access (via Accounts & Privileges), I would like a dialog box to pop up and say "Access to XXX denied" and to stay on the current layout (and not to a greyed-out screen which shows No Access and leaves techno-shy teachers wondering what to do next).

Also, is it possible to modify the above so that a password is called for. If they type in the wrong password, I would like a dialog box to pop up and say "Access to XXX denied" and to stay on the current layout.

Thanks for any help

Frank Bugeja

[transpower]

A better design would be to give each category of user its own main menu. Depending on their access privilege, upon login, they are transferred to the menu from which they can access only what they're supposed to access.

[fbugeja]

Thanks for your reply Transpower but you are an "Old Hand" and I am a newbie so how would you give each user their own menu so that upon login, they are transferred to the menu from which they can access only what they're supposed to access?

I am at a learning stage with FM7 at the moment!

Frank

[LaRetta]

Hi Frank,

I think you are on the right track. I too, attempt to protect my Users from sudden, often rude, unnerving FM messages that say little, confuse a great deal and leave a User staring at nothingness.

Although I have established extensive Privilege Sets, they are used only as directives to my scripts via Get ( PrivilegeSetName ) = "whatever" , Get ( AccountName ) etc. FM7 allows tremendous flexibility with Accounts. You have other concerns (in addition to navigation and record-viewing) which a different menu for each teacher group wouldn't address either: perform finds, record deletion, etc. and if you wish to protect your Users from FM messages, rude grey screens and "No Access" messages, you must address them as well.

I use Access Privileges as a set of grouped rules. Nothing more. I do not let FM handle things.

I would not create another layout for each person or even mess with menus based upon Privilege set - unless the button options differ. Let your scripts (fed by Access Privileges) do it for you. Set Available Menu Commands to minimum and control it all. Use tests in your scripts to allow accessibility only when authorized. Pay particular attention to that little checkbox "Run Script with Full Access Privileges" and thoroughly understand when it should (and should not) be used; use Custom Dialog messages (or I prefer small window layouts) to convey nice messages for your Users. You can actually provide messages that make sense to THEM; while offering options and explanations.

Every script-write should ask the following question: How will each privilege set (of Teachers) need to be handled? Then use Set Error Capture [ On ] to stop FM and write your scripts accordingly - redirecting each group to their proper task ... nicely, with a smile (and their name) if possible.

Does it show that you've touched my passion? I won't apologize.

LaRetta

[Fenton]

One thing about "record-level access restrictions" is that they really are absolute. You cannot even set a global field, or evaluate a calculation, such as a Get(AccountName) function. So, to make your life easier, as transpower was hinting at, start their navigation from somewhere else.

It doesn't matter so much where, as Get(AccountName) is the same on any table; but it has to be a table where there are No record-level access restrictions; even if you have to create a dummy table just for this.

Back in version 6 we would make sure each user had their own record in such a file, because of record-locking problems, globals and portals. Version 7 records are much less likely to be locked, so you may be fine with just one record (you need at least 1 for calculations to evaluate; though you could have none and use a script and a global field).

Accounts:

Fenton Jones

Admin

User

None have a password. I'm the developer account, 'cause it's my file :-)

[i just realized that you're not really asking about "record-level access," so my example is kind of off on a tangent. I just wanted to see if a no-record table and a global field would suffice for navigation in that case; and it did. Save it for later -]

AccountNoRecords.zip

[LaRetta]

Oh Frank, how rude of me!

I provided no specific assistance or answers to your question. Please allow me to explain how you might accomplish exactly what you wish:

"When a teacher clicks a button that would normally take him to another layout but is denied access (via Accounts & Privileges), I would like a dialog box to pop up and say "Access to XXX denied" and to stay on the current layout..."

Scenario: Button to take a teacher (but only those with Privilege Set of "Main" to another layout. I will use Custom Dialog as an example. You can attach the layout name as your script parameter:

Set Error Capture [ On]

If [ not Get ( PrivilegeSetName ) = "Main" ]

Show Custom Dialog [ OK; "Hi " & Get(AccountName) & "

[fbugeja]

Thanks all (Transpower, Fenton & LaRetta) for your help!

With the annual School/Christmas holidays (of 6 weeks) coming up in a week's time, I'll have time to play around with your suggestions - especially when the temperature outside is over 100F/38C!

Avagoodwegend!

Frank

[H.P.]

Hi Laretta,

I have used almost the same approach as yours to check privilege for the layout before. However, when the program is big and there're multiple paths to the restricted layout or if there are too many layouts, it's very difficult to manage & hard to maintain when you need make certain changes.

I would recommend transpower's approach more than using the script to check privilege. Personally, I add a menu button called Admin to go to the layout that shows all the access-restricted layouts (only 1 privilege check script). It's easier to maintain & you don't have to put privilege check script into every button.

H.P