× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



As to item "B" that proposal violates one of the basic rules of 
database 
design: Storing sets of data in one record. If I were designing this 
security application I'd have a file keyed by UserID, MenuName, and 
Option# 
and have one record for each option. If the record doesn't exist then 
the 
user wouldn't be authorized to the application. As an added feature, if 
the 
record exists you could check an authorization code to see what they're 
allowed to do in the program (change or just display).

We do something like the above suggestion, but in our case the key is 
'option identifier', group profile, user id.  The group is checked first, 
then the user name if a group doesn't match.  This is nice because it is 
easy to allow all tech support staff access to (almost) every option for 
troubleshooting.  For each record there are a bunch of flags that can be 
used to refine access as suggested (add, delete, display only, etc).  Most 
of the time the 'option id' is a combination of the menu program name and 
the menu option number - but may be a program name if that program has 
specific internal security requirements like the add/delete/display type 
of thing.

The only thing I've found is that it can get a bit frustrating to hunt 
down the 'option id' if a manager calls a says 'Can you give Adam access 
to option 15?'.  We have built some tools to show all of a user's 
authorities, add a new user by copying an existing profile and that sort 
of thing which helps somewhat.  It is also somewhat of a challenge to keep 
up with changing authorities when job functions change - I think this 
might be alleviated with better use of group profiles.

HTH,
Adam

#####################################################################################
Attention:
The above message and/or attachment(s) is private and confidential and is 
intended 
only for the people for which it is addressed. If you are not named in the 
address 
fields, ignore the contents and delete all the material. Thank you. Have a nice 
day.

For more information on email virus scanning, security and content
management, please contact administrator@xxxxxxxxxxxx
#####################################################################################

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.