Form & DBF permissions (security) with runtime

[dchiass]

Not much luck with my first post so will give a scenario.

Our application has about 16 forms & 55 DBF's. Generic groups & users & permissions on forms (and DBF's) are set by us which we believe mite suit most users. 100% of users, run the Alpha runtime v10.5 to v12. Typical / generic usergroups: Manager, Supervisor, Mechanic, Purchaser, Guest, Production Tech. All groups have different combinations of permissions Deny/Allow for the various forms & dbf's.

Names of a couple forms: Employee, Advanced Utilities, Basic Utilities, Query Maintenance, Machines, Parts....etc.

We do not want a user of our application to have the ability to CHANGE forms, dbf structures and other items that could effect our future upgrades we send to them. Thus, the development edition is not an option.

Customer #1 likes the majority of our generic security setups but would like to change a couple of the groups to allow a couple forms to be run which are denied in the generic setup. Almost 100% of our users want to tweak the generic permissions for each group.

"Eons" ago with Alpha's runtime, a customer's IT or manager using the Control Panel could change the permissions for forms, dbf & reports by right clicking the icon in the CP.

It was easy for their IT to see which group had which permissions. Now, it is impossible for them to tell what the actual permission setting is UNLESS they create a external template & hand write the permissions in it. Pretty backward.

With the fairly large number of forms & dbf's, we have been asked MANY times what "happened" to the security setting method in the older runtime. Our only reply, Alpha removed it when they released a newer runtime.

We are almost there with a solution but have been unable to accurately show on a security screen the permissions for each form & DBF. Seems the permission text has a mind of its own, sometimes shows correctly, a diff form is incorrect. We can see this with the development-version that the permissions are correct, just the screen text is wrong.

Do any Alpha Anywhere developers have a solution to our dilemma? Thanks group.

[MoGrace]

Re: Form & DBF permissions (security) with runtime

16 forms is not too many. You could generate a list of the form names using form.enum() and put the list into a table. Add a field to the table for the user level that is allowed to view it. My user levels are simply 0,1,2 or 3. Create a form for that table and allow only an Admin level user to access it to change the form permission level. You could do something similar for your user list. Then in the OnInit event for the form OR on the script that calls it, check the permission level of the user and the form and notify the user if Access is Denied, else just open the form. I have a login script that sets global variables with the user id and level, since I am not using the Alpha security. I also have a main form set as wallpaper that is always open and hides the control panel which cannot be accessed except with my password. Which means you would also have to set the production copy so the debug option to open the app straight to the control panel is turned off.

If you customise the toolbars and menu options, you can prevent layout design on your forms - or set that restriction in each form's properties. You can also password protect each form - but I personally don't care for that option as I forget passwords!

Pretty old school I know, but it works for me!

[dchiass]

Re: Form & DBF permissions (security) with runtime

Thanks for the suggestion, I will punt to our tech. How do you handle DBF's actions like add, change, delete or view?

You mention "prevent layout design " but 100% of our users run Alpha runtime v10.5 to 12 so even their IT are unable to do this in the Control Panel.

In your home-grown security method can a users IT tech view easily what is set in permissions for both forms & dbf's? We want them to have the flexibility to change the generic permissions we set & also to easily view what the present & new settings are.

[MoGrace]

Re: Form & DBF permissions (security) with runtime

Since you mentioned runtime, that does take care of the user's ability to edit layouts and scripts. But if you utilize tables to hold the data you need for setting the permissions you can give the IT guy access to that table and there would be no need to mess with the forms themselves. The scripts that open your forms can check the values set in the table and permit or deny the user access to any form. My guess is you would need to set categories for the forms - perhaps by department, and then set the base user level for a particular form. Eg. if the form level is set to 2, then no one who has only a level of 1 can access that form, whereas anyone who is at 2 or higher may. You could even set separate levels for each department/ category you want. But at log in you will need to set some global variables to capture the user permissions. And this would be specific to each workstation, assuming you don't have users who share pc's...

[dchiass]

Re: Form & DBF permissions (security) with runtime

thanks for the comments. how do you handle the DBF permissions for add, change, view or delete?

[MoGrace]

Re: Form & DBF permissions (security) with runtime

I am using buttons & form properties for these actions. On some forms where I want to control WHEN a feature is available I use either conditional objects that hide or show the buttons, or form events. The conditional object could add the user level in its condition. I would test for the strictest condition first.

I also have a template form where I save common buttons that I use on my forms. These can then be copied and pasted where ever you need them, then edit for the particular form. I think Ira puts all his button scripts into UDF's so if they need editing, he doesn't have to find everywhere the button is used. Then you can have variations of the script or add conditions in the script for user levels.