Hi
I´m in the following situation:
Our users are customers and they must be added by an administrator. Some customers should be enabled to create their own "subcustomers" and of course be able to edit and delete them.
The problem is, that if you want to enable someone to add users, by default, there is only the "administer users" permission. They would have been enabled to edit all other customers as well with that permission. Of course, you could protect your users with the user_protect module or others, but then, the "customer admins" would not be able to edit their own subcustomers any more.
So my question is: Is there any module that makes a connection between user admins and their editable sub users? Like adding the "administer OWN users" permission and considering as "OWN" user someone that YOU have created?
Thanks a lot
Sören
Comments
_
look at organic groups - og.
good luck ...
Hi, errr, really? ´xplain
Hi,
errr, really? ´xplain how?
I ´ve got og installed and use it for exactly this purpose (i.e. the user administrators are the group administrators of the "customer" groups), but don´t you think that a group-level administration permission might bring some problems? The user administrators could put anyone into their group and gain control over him.
I think that the administrators should only be able to edit and delete other users if they are the ones that have CREATED the user.
Thanks
Sören
_
og admin only control the specific og group - not the entire site - so, they can only remove a member from the og not the site.
In any case admin people on any level have to be trusted people and you should know who they are in some form. You need to have rules for the admin and the users so users know what to expect, know their rights and duties and when & how to complain to the admin above.
same for the og admin - they need to have rules and be clear when you or the superadmin can "fire" them.
Be also clear what happens to a group when they lose their og admin either because of misbehaviour or just because s/he got bored and is not maintaining the og any more. You could end up with very unhappy users and loose them quickly.
Good luck ....
Hi, thanks again for your
Hi, thanks again for your answer.
Ok, I´ll try to make myself a bit clearer.
I want to have user admins which are incidently also group admins. These admins are our REAL WORLD CUSTOMERS, they are paying us to be able to manage and control via our website the real world products (street light transformators, to be precise) we´ve sold them.
So these customers should be able to have some kind of "administer users" permission, because they have employees, subcustomers and whatever. They should be able to have full control over THEIR customers and employees, but not over the employees of other customers.
So, I think that our users won´t be "unhappy" or "fired", don´t have duties or whatever. We simply provide a service, and they should be able to do what they want, but ONLY in THEIR part of the site with THEIR users. And the problem seems to be: Who are THEIR users? Not the ones in their group because they can invite them freely. And, if I have defined who THEIR users are, how can I restrict the "administer users" permission to apply only to these users?
It seems as if I have to write my own module: It logs what users an admin has created and provides him with administrational access only with respect to these users.
Cheers
Sören
_
Sören,
my understanding is that OG does just this.
The users become members of the site - they then join the OG group of their supplier / employer. Within your site they may have access to general information, forums, etc. Within the OG group they do what ever rights the og admin gives them. With this the og admin does not have any control over their membership to your site.
Now if you want these users to be only visible, active, etc. in their own OG - then you just do not give them any content & rights on your site.
May be your site only provides information, forums, etc. for the admin of the OGs.
The OG admin will only be able to do things in their OG. They will have no admin rights to your site. They can not even setup an OG if you restrict this.
I hope I understood your concerns correctly?! ....
A diagram for the structure might help you.
As for rules, getting "fired", etc. - I can understand that this is not a worry for you, but you will need rules and process in any case. Feedback is always the key to improve your site and there is legislation you have to comply with.
You will be default collect personal data and thus you need to register in some form with the data protection in one or another country. In the UK it will cost you under 40 GBP for a year unless you are a big player by turnover. UK registration is possible via a UK business - a Ltd is quickly incorporated and very cheap to do. In the US it is similar - though, I have no idea about dta protection and registration fees there, company incorporation there is equally easy. In the US and Europe you also have to comply with anti-spam laws. So, for a serious business you will need rules defining duties and rights for your users, protect there personal data, and give them a complaints procedure. Boring stuff, but essential.
Good luck .....
Hi again, at the moment my
Hi again,
at the moment my concerns are solely about user administration. Content is out of question.
User should NOT be able to register, this is managed by a user admin (let´s say "high level customer" - admin). These admins are to be trusted as long as it comes to their own users. The only thing I don´t want is that they are able to administer the wrong users. It´s quite simple: Delegate the task of user administration, but restrict the permission to a group of users.
I´m sorry if I don´t see your point, but I still don´t understand what Organic Groups has to do with user administration.
I understand that the group members will be (can be) restricted to their groups, which is good. I understand that OG admins won´t be able to do bad things to external groups. But what I really don´t see is how I can give them a restricted user administration permission. They should be able to add users, edit their users and promote them to certain roles. But restricted to the users THEY added.
As for the rules/legislation: As it is a closed system, I don´t think I have to/will pay attention to that too much.
Thanks
Sören
_
OG administrators only adminster their OG, nothing else, so there should not be a problem.
Give it a try - set up a test site and populate it with some users OGs and OG admins. User 3 plus browsers for 3 users (admin=user1 / a normal user and an OG admin) and if you run more browsers - different once - not just different Windows (Chrome, Safari, Firefox, IE, etc.) you can have a few more users and different OGs. Same is possible with a more than one computer on a local or hosted server installation.
As for the thought of a closed system - once you start collecting personal data there are no closed systems. When you run a database with personal data entries online or off-line you have to comply with the law. There is no difference whether you collect data from employees or users on the net. Names and email addresses are personal, so the legal entry level is low. Users cannot even opt out of this. Just be aware of this and remember - the most important aspect of people using and subscribing to a website is whether they trust the site - something to keep in mind - along with the fact that a large percentage of people will look for compliance with the data protection - even if they do not read the "small print".
And finally, you also need to protect yourself - your business / company / organisation / client. If you have no rules and no ToU with proper copyright and transfer of copyright rules to you / the site / the owner of the site, you will not own the copyright of any content the users add and could end up in quite a bit of trouble - the worst once would be compensation / damage claims on copyright infringements. Boring stuff - until you come across real cases - and they are out there making good pickings for lawyers.
Sorry, I know you don't wont to hear this - but just stick in a few simple terms and get on with the real fun stuff.
ARRRRRRGGGGHHH. One of us is
ARRRRRRGGGGHHH. One of us is quite stubborn ;) No offence meant.
So I´m gonna ask a few questions that may sound a bit harsh, but make clear WHAT I´M LOOKING FOR:
Does OG give me the possibility to create users as a subadmin? (I guess the answer is NO.)
So if it doesn´t and I have to give my subadmins the "administer users" permission to let them be able to create users, will OG do anything to restrict my subadmins to do harm to other users? (I guess again: The answer is NO.)
SO OG DOESN´T HELP ME in my situation (nor does it do any harm, but I never doubted that). As I said: It is installed and I use it, but it just doesn´t do what I was initially asking for. For me THIS is the end of the OG discussion.
If you, tryitonce, consider replying to this post, do me a favour and reply only if my answers to the above questions are wrong, or if you have other ideas than OG. Everything else will be a waste of time.
I hope I didn´t sound too unfriendly, honestly, I just wanted to make clear, that obviously, we are not talking about the same problems.
Anyway, thanks for your time and effort,
Cheers
Sören
_
No worries Sören,
good luck with your project and hopefully there will be a solution out there for you and your project.
In case you get a solution that includes OG, do post a quick note here or a link to where folks can see how you did it.
I would bet that OG will be in there.
I can see the point of your group administrators not being able to manage the users as you first thought - though the way around that would be to give the sub-admins = OG admins the option to invite users to join the site and then to limit it to their OG. If they exclude a user from the OG the user would still be floating on your site as the sub-admin would not be able to remove them directly. But this could be done with Rules - if a sub-admin removes a user from the group a Rule could block or remove a users account.
Though, other sites with a similar structure might be happy to retain users after they have left one sub-group - of course not in your case.
Anyway - don't spend any more time on this - just be kind enough to come back if your solution includes OG.
Your response is quite harsh - but that might mellow with life experience and some may be down to cultural background - and a look at people's track record reveals if they are here to share ..... - good luck ....
Hey, thanks again. Really, I
Hey, thanks again.
Really, I just wanted to make my intentions clear. At the moment, the problem is not so urgent, but I think when the time comes, I´m going to write my own module: "administer own users" I´m quite sure it makes sense, but I´d really like to hear a second opinion about that.
Cheers and good luck to you, too, whatever you´re doing.
Sören
Try the subuser module. I
Try the subuser module. I found this thread in looking for the same solution myself, and in a separate thread I found a reference to subuser (http://drupal.org/project/subuser). It appears to do exactly what you (& I) need, though I am finding one conflict with a query that comes from the standard modules/user/user.admin.inc. I'd love to see more people (who are more capable than I) help support subuser.
I have this same exact
I have this same exact scenario.
After reading this thread, I feel Sören's pain. The problem with Organic Groups (OG) is that it is designed for collaboration and sharing of information. I am developing a healthcare portal that complies with HIPAA compliance, which is nearly the exact opposite of freely sharing information, nodes, etc.
I have everything locked down perfectly, using subuser & nodeaccess. It's just that subuser only pulls in the full profile (i.e. the custom profile fields) if the current user has "administer users" permission. So that allows the custom fields to become editable for the semi-admin but it also means that they can manage other users outside of their company/jurisdiction. That is unacceptable due to security, so I need a way to pull in the profile fields through subuser and/or something like an "administer own users" permission.
I do not believe that OG is able to lock down properly and am not loving the idea of redesigning access to base on a "sharing-focused" module with limited access rule capability. Specifically, the ability for a "role" to be able manage groups is not sufficient, because each group is a "customer" of ours. So customers should not be allowed to manage each others' accounts. They should also not be able to create multiple groups.
I will post a request in subuser and see if they can assist.
I discovered that there is already an issue open:
689578 Can't edit profiles of subusers from parent account
--
_
You might have to write your own module to get exactly what you want and if you need to comply with certain standards.
However, reading your note I get the impression you haven't figured out completly what you can do with roles and permissions. It is not as easy and simple as it looks.
It might help you to put your explanation into a matrix of roles and permissions. You can then control what an og admin can do and cannot do.
You can set permissions for users to create fields that the og admin cannot change (no permission to edit any ...)- for this of course you need a CCK access limiting module.
You can have fields that the og admin cannot even see - only the user and may be some mangers higher up that have no admin rights, but viewing rights.
A key starting point is to look at the use of view nodes / content - if your system has no anonymous users - you can control all view / access / editing / deletion more easily.
And finally - one problem you will have in setting up the system is that if you do it all alone - you need to create several users for testing with all those different roles. You will then need several browsers or computers (would be better as you could label each one with the user (role) type to test.
All this would be easier if you had a test team going through all the user levels (roles) and then you control everything and tweak it as user 1.
As user 1 will be able to see and do everything - so, there is always someone who can see, do and read everything. ----- Scary, when you think about the wider picture.
And remember, one permission set to far might remove several other restrictions you have structured in and set up correctly. This is what makes it so difficult and complex.
Thanks for the feedback. I'm
Thanks for the feedback. I'm actually quite strong with roles/permissions.
I decided to switch to Drupal 7, even though the security is very lacking (only taxonomy is currently working), but I did manage to get it HIPAA compliant. It took 2 days, because I tested all of the other modules (content access, nodeaccess, node access, menu per role, etc) to try to get all of what I needed. None of those are production-ready for D7 yet. In the end, taxonomy (last resort) did work, thank goodness. :)
Subuser, though, had a worse issue of allowing any "subusers" to view the subusers belonging to the parent (due to the nature of the relationship). After many hours, I managed to track down a way to block that and now I'm back to where I started. Everything works except that the parent cannot edit/delete the child (no access unless "administer users" permission is granted). So I guess I will keep looking. It doesn't look like OG would offer any benefit and would introduce significant security concerns.
I do have many different test users at all levels (multiples at some levels to ensure they cannot cross access by role) and I do my testing thoroughly. So I think I'm good there.
Cheers,
Brandon