I'm interested in offering basic level User Management security for the aMember software. More or less, adding 2 user attributes (Chapter, Department) that will allow an admin, say Chap1Admin, Dept1Admin, to ONLY manage users that were in a specific Chapter or Department. This doesn't even need to be integrated in the front end, a manual update of the tables would suffice. My thoughts were adding a Chapter field and a Department field to both the amembers_admins and amembers_members tables. These fields can be manually updated by inserting the corresponding Chapter number or Department number within these fields. (Name lookup is not necessary) Then setup a query that would only return the users that matched each field within the admin when user account info was called. For example if there was a user that was in Chapter 1, the Chap1Admin would login to the admin console and when they clicked on browse users or they did a search for users, it would only return the users that had a '1' in their Chapter field. Same example if the user was in Chapter 1 and Department 2, the Chap1Admin and Dept2Admin could both view that user. It would be a logical limiting setup. Is any of this possible, can anyone tell me where I would need to go in the PHP to update this data and add the SQL statement, is there already something out there, does anyone have a better idea, does anyone know where I could get help or get it done if you guys don't know? Thanks so much for you help.
unfortunately, it is not easy to implement in aMember, so I would not risk to give any suggestions. Most SQL queries are inside encoded file amember/plugins/db/mysql/mysql.inc.php and if you contact support we will give you unencoded version of this file.
Thanks... Within that file, would you be able to adjust the queries based on additional attributes added to the tables for calling profiles under the user management links? Because I'm sure that a lot of aMember users would benefit from having mid level administrators to be able to manage their own users. For example if there were different subscription types or department types. Jack
As I said, it is not easy to do. If I would see quick and short way to implement this feature and make it working for all users, it would be already implemented. Of course, it is sometimes possible to find a solution for particular situation, but only your programmers can determine this.