Thanks.
You're right, that would be much better for handling users and their
priveleges.
The bigger focus was storing global variables in the database, rather than
hard coding them in the template, in order for them to be changed through a
web interface. Any potential problems there?
Thanks again,
Brad
-----Original Message-----
From: John Quarto-vonTivadar [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 22, 2000 10:34 AM
To: [EMAIL PROTECTED]
Subject: Re: store global variables in db?
> My table has three fields: VariableName, VariableValue, and UserLevel.
> UserLevel is used in the admin part of the site to allow only certain
people
> to change certain variables.
>
> Anyone see any problems, have any comments, or different ideas?
I would nuke the UserLevel and separate that functionality from the global
variables. If you think about it for a moment it isnt the user variables
that have permissions, it is the Users who have permissions. Therefore that
field, UserLevel, has nothing to do with a table about Global Variables.
Instead it would appear in two other forms: the first, as a field in the
User (or related table) which I bet you've already done anyway, defining
what level of permission that user has, and then second, within the CFM
template itself wherein you would check for ones UserLevel before grating
access to the template or portion thereof. If you need to create a table
where only certain users can change certain variables then (a) use a
intermediate table (which maps UserID to VariableID) or (b) better yet,
assign a Group structure and assign users to Groups, so you only have to
create a few mappings of GroupID to VariableID and you also have no code to
write when a person is assigned or de-assigned to a group. on top of all
that you'd also be able to give the groups a hierarchy if that is required
later on.
This will also separate the business logic (the user levels) from the
program logic (setting a global variable) and since once the app is complete
the busines logic is more likely to change than the program logic you will
be able to make modifications easier. You may find, over time, that you DO
follow a pattern wherein you want these permissions on a UserLevel basis but
it shoudl still be done in a intermediate table.
Is there anything lost in your app if you model the security on the
Users/Groups/Privileges idea and keep the global variables separate, except
for chekcing privileges when those global variables are set?
Even though it of course works, I cannot see much upside to doing it the way
you originally suggest, but quite a bit of downside later on if you need to
change the model.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
