My goal is to set up multiple group directories with a different admin for each.
Each directory would have a unique set of records.
Each admin would be allowed to Add/Delete/Modify/View only records in their group.
Users would be allowed to Add, Delete, and Modify only their own records, and view only records within their group.
And I would like to set this up using only one database.

Is something like this possible?

Many thanks,
Rick

Why? And how could such a thing be possible? You can't divide one database between multiple directories, since a database is a file.

Or maybe you're thinking of a different definition of the word "database."


JPD
----------------------------------------------------
JPDeni's DBMan-ual
How to ask questions the smart way.

Let me apologize. When I used the word "directories", I wasn't referring to file folders; I was referring to something like a phone book directory. I'm sorry for causing confusion.

What I am trying to do is provide local phone directories (or maybe I should say "phone listings"). Each list would have its own admin, and the numbers on each list would be viewable only to the local people on the list. But instead of each list being a seperate database, I'd like these local lists to be drawn from one overall database.

Is something like this possible?

Thanks again,
Rick

What is the advantage to having them all in one database?

Off the top of my head, the only way this would work would be to use the "add permission" mod, but instead of the new permission being just an on/off, it would be a number which would then correspond to different parts of the database -- your directories. (Which I understand now. :) This would be a pretty major modification.


JPD
----------------------------------------------------
JPDeni's DBMan-ual
How to ask questions the smart way.

I anticipate eventually having hundreds of different phone lists. The advantage of having them all in one database is that I would not have to set up hundreds of separate databases.

A typical phone list would include people who are locally connected; for instance, the parents of a 6th grade class, or the members of a church.

Each record would have a "group code" field; so, a unique phone list would display after a user entered the unique group code as a search term. This "group code" would be made known to the local group by a local administrator; for instance, the 6th grade teacher, or the minister of the church. The group code would be created by the initiator of the local phone list.

So far, so good. I would not need to do any modifications at all. A problem arises, however, if some nefarious person who should not be on a certain list somehow gets on the list. I, then, would want a way for the local administrator to be able to delete the record. The tricky part is how to set it up so that the local administrator would have Delete/Modify permissions for only the records containing his/her group code. That's where I'm stuck, and where I need your expert advice (for which, again, I am most grateful!)

- Rick

I'm afraid I don't have any more ideas than you do, though. Sorry.

Maybe someone smarter than me will come by with an idea.


JPD
----------------------------------------------------
JPDeni's DBMan-ual
How to ask questions the smart way.

Thanks for taking a look.

- Rick

A couple of things... if you are going to have hundreds of records you'll want to start with dbman flat file and then upgrade to dbman SQL once your db file reaches 1 mb or so.

Would the admin's assign the users?

I've done something similar (and so have some others) by using a relational db. (One db is for groups/account reps and the other is for the actual records/users/clients).

1. In the relational db you have your group with admin's contact details etc:
------------------------------
Group Name/ID
Group Description/Purpose/Schedule/Whatever
Admin Name
Admin Contact Info

2. In the main db you have the user/phone details:
------------------------------
Group Name/ID
Individual Name/ID
Phone #/Whatever

As "super admin" you have access to the db #1 to add/modify admins. You set up the admin in the group db and assign that person a Group ID/log in/rights. Then you login to the the main db and add the admin again.

You'll have to do a combination of $rec{'GroupID'} (pulls group id from record) for modifying searching and $in{'GroupID'} (pulls group id from input string/url) which may or may not be stored in the password file.

Then your "sub admins" will login to the "main" db and add individual users - you use the GroupID as a "hidden" field (or append it during the db write process) to tag that user to that Group.

You may be able to do it without the relational mod and just put the GroupID in the password file (see additional permissions mod) - so that basically you can put something like:
if (($per_admin) && ($in{'username'} eq "superadmin")) {print pull down or box to assign sub admins to groups} else {print groupid as a hidden field}

The long answer is that there are many ways to accomplish what you want, my suggestion is to get a Perl book and start hacking away at dbman. Try a couple of simple things first: such as getting the groups assigned - but visisble to all and then work on trying to exclude the various things you want hidden/secret/unmodifiable.

Ok. The more I think about it... you don't need the relational mod.

1. Install a copy of dbman and then add the "additional permissions mod" or whatever it is called. Go to http://www.redundantcartridge.com/dbman (dbman faq maintained by LoisC) and look at password, admin, permissions, etc.

2. Add a field to the password file for the GroupID

3. Set permissions so users can view all, but mod/delete own records

4. Under admin screen/section you'll need a pull down (for the GroupID) and using the logic I mentioned in the above post you'll want something like (if admin and "me" print pull down so I can assign a groupid to sub admins else print the groupid as a hidden field that is populated out of the password file). You may also want to "hide" the admin checkbox so subadmins can't make a user into an admin as well.

5. Now when your admins assign users they'll be assigned to the admins groupid as well.

6. Then pass along the groupid as a hidden field when adding a record (it'll come in the same way as the username/userid does when someone *adds* a record - ie $in{'GroupID'} and from the db when they modify/delete a record $rec{'GroupID'}).

7. Next you'll want to use the GroupID to limit records upon searching/displaying to that group (ie, make it a hidden part of your search criteria).

Now this can easily be circumvented, by someone figuring out that &GroupID=1 is part of the URL so I'd make my GroupID's obscure (ie, "90210" would be "Teen Group" and "A567YT" would be "deacons board").

You can really get some ideas from the unofficial faq - look for one that talks about passing items along in the url and username passed along etc. You'll have to dissect dbman and the way it operates but you'll learn a lot. The dbman FAQ is your friend.