It appears to me that you want to use some form of grouping. Normally group based permissions are most easily handled in a database by building a permissions table which is actually a join table. With the appropriate fields, you can give each user different accesses based upon what site/login they are using.

Something like this can be emulated with lookup hashes.

# Untested

my %permissions_for = ('adam' => {'alpha' => 1, 'beta' => 1, },
                       'bart' => {'alpha' => 1, 'beta' => 0, },
                       'cece' => {'alpha' => 0, 'beta' => 1, ),
                      ); 

{
  my $account = 'adam';
  my $access  = 'beta';

  if ($permissions_for{$account}{$access}) {
    showcontent(1);
    showcontent(2);
  }
}
[download]

In other words, you have a session so you have a user and can store some form of user state. Where you maintain that state lookup table (separate .pl code, database row, current code block) is up to you. You can also add flags for each condition so that you have full control over exactly what is shown each account.

Because this can get complex very fast, some sort of account management software should be created for the admin. You will also want tools to modify account accesses based upon session state. Say, the user wishes to turn on certain alerts, or turn them off.

Initially, you can do this by hand, but at some point you will want more options and a simple way to manage them.

Well you totally understand what I am trying to accomplish, I don't know sql that well, I can barely spell it, so I am not sure how to go about adding what I need. I have some programming experience and inherited this website which I now need to expand on it was designed for 1 product which is being used in a number of accounts, now the entire structure of the company has changed and I am scrambling to adapt it to meet our changing infrastructure. There are now something like 7 products and I need additional layers to control my alerts as one global is not enough abstraction, what happens if I need an alert for a group of accounts getting an upgrade for instance, I am trying to make it easier to manage, not easy to do when adding more complexity as the change in number of products supported and the fact that some accounts have multiple products, make it even tougher. so I am thinking to add the following.. usrFamily (divisions within company) Products (list of possible products) Version (check to see if version specific alert applies etc) Account (usrAccount) Sitecode(not same as usrAccount as some sitecodes contain multiple accounts) Does this sound overly complicated or is it not complicated enough?

If you don't want to use database storage (it is something very good to learn and use), you can also just create an account table. Something you can create with a spreadsheet, written as a CSV file, and then read it in as a logic table. Then, using any structure you can follow, you can test your conditionals for viewing options.

Doing it this way is simple, but not very robust. Even so,with the proper strategy, you can add and modify accounts from that same spreadsheet. Obviously, this will get very cumbersome if your logic table gets very large, and you will have to eventually add management tools to ease this work. Also, adding accounts by hand is not very automatic.

Adding a logic tree is reasonable too. By filtering by division, you might avoid a bunch of other tests. How you lay out the data will be impacted by this additional complexity. Having your data field contain sub-fields is not very CVS friendly, but it can be done with careful mapping. Again, this type of granularity is something that databases provide.