in reply to Hide Data based on account

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.

Replies are listed 'Best First'.
Re^2: Hide Data based on account
by grashoper (Monk) on Sep 18, 2007 at 21:22 UTC
    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?
[reply]

      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.

[reply]
        I am using sql, not sure how to add what I need to it though I am thinking at this point just a products lookup table (list) and adding a product id to exisiting alerts table will give me flexibility enough to move forward, can you recommend any good resources on sql, seems like most sites about sql are either too basic or too advanced can't find a nice middle of the road introductory site.
[reply]
        Actually it is already using sql server and populating user information for authentication from there. The grouping by permissions is also there but needs to be expanded upon. For the time being my task is to change the content displayed based upon the referrer, which is already being captured, for the new product my pass through preauthentication script is not currently working, my guess is that they are not using md5 authentication which the other division of the company is using, however I could be wrong about that it could just be located elsewhere in the other products userinformation - database, as a short term workaround I have it response->redirecting to a static page, which is context sensitive based upon a topic being returned by the query string all that currently displays is the relevant portion of the help file. Users can also login to the site with their user information and that does work but doesn't map to my static page, its a generated page, using xml and xslt to display the content dependent on what xml files are present for that specific site, there are 55 or so old sites that work just fine this way, I need to change the content so some of the "generic" content for the old 55 sites don't come through in the "new" sites. I hope that made sense. I am thinking perhaps a Switch structure would work well here but I am not certain where I should put this switch, it needs to make the decision before it starts creating the page, problem is the original author was using many includes..so does it go in all the include files...and branch off to other subs instead of the originals?
[reply]

In Section Seekers of Perl Wisdom