Ability to override registration requirements
| Project: | Membership types and registration modification |
| Version: | 5.x-1.1 |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Jump to:
Perhaps this is by design, but I find that there's no way to "override" the need to select a membership type and fill out the required forms, once the module is enabled and registration types are set up. i.e., go to /admin/user/user/create as an admin, and it still takes you through the membership type select/pageroute process.
In my case, the membership types people register for are just one part of my userbase--I also want to be able to manually add/edit users as an administrator, and still be able to create "normal" users that aren't subject to registration requirements (but for obvious reasons, I don't want "normal user" to be a choice on the membership types menu). Also, this is how I create my various levels of admin users, and obviously I wouldn't want those "membership types" to be visible to other users.
So, here's what I did as a workaround, and possibly you want to include this in your code (or maybe you don't):
1) Added a new permission in hook_perm called "bypass registration requirements". Granted this perm to a role who I want to be able to manually administer the users, namely add users without going through the whole process.
2) In hook_form_alter, where the user is normally redirected to the "select membership type" form, did a check to see if that user has the perm I created above:
<?php
if (!$_SESSION['mem_choice'] && (!user_access("bypass registration requirements"))) {
drupal_goto('user/membership_select', drupal_get_destination());
?>3) Now I can manually create a user in /admin/user/user/create and don't need to specify a membership type or go through the associated pageroute. Only problem is I was getting a foreach() when the user logs in, because nf_registration_mod is trying to do stuff with the $user->mem_choice (which is not set). So here's what I did:
In hook_user, where normally it would "break" for uid==1 (the administrator), added a check to see if mem_choice is actually set or not. If not, it breaks and doesn't go through the whole "required pageroutes for login" thing.
case 'login':
global $user;
if (($user->uid == 1) || ($user->mem_choice == '')) {
break;
Anyway, this works for me. nf_registration_mod is great for certain things, but it was taking over my system, to the point where I couldn't even add or manage "normal" users through the normal drupal interface anymore. rconstantine, you will probably say that's how it was intended, but I'm sure I'm not the only one who's having this problem. Perhaps you will include this in your next release, otherwise if a real patch is desired here I will post one.
Oh and thanks again for the great module!
#1
Actually, you pose a good use-case for the bypass - one that I will face next year but didn't think far enough ahead about. So although I may or may not use your method, that is a problem I would like to solve.
I'm going to mark this as postponed just so I can mark it that lovely purple, but I may get to it sooner than I think.
One change I can think of, is rather than check if mem_choice is set or not, to either set it to a normally invalid number like -1, or require that you immediately assign the new user a role with an additional permission - something like 'registration pageroute not needed' (or something snappier).
If I recall, if the admin creates an account for a user, the way it works now is that the admin has to fill in all of the pageroute stuff - wait, you just said that. Um, so, what if an admin could setup an account, select the membership type, but not have to fill in the pageroute, leaving that to the user. This would be in addition to the solution you thought of for admin-style regular users.
It's late so I'm not making sense.
There are two cases:
The first, you want to create an account for someone that should have a membership type, but either don't know their info, or don't want to fill it out. So I should allow that case.
The second case is as you state where a user doesn't need a nodeprofile via pageroutes and should be exempt altogether from filling them out.
Anyway, it's nearly 2am and I need to get up at 630am. Time for sleep.
#2
Forgot to mark it purple.
#3
Sounds like we're on the same page--mine was rather a band-aid solution and you're thinking more of the big picture. I'm confident that when it "comes to you" you'll do a great job implementing it! I'll check back in once you have a chance to work on it.
#4
Hey Scott, I don't recall fielding any support issues from you. Were you able to setup this module on your own with just the READMEs and such? And is everything working as you expect it should?
#5
Actually, as you recommended in the README, I carefully read all the instructions and planned ahead for my installation and it went pretty smoothly. I do agree that this is definitely a higher-level module and without a working knowledge of the related modules (and some common sense!) it would be pretty impossible for a "newbie" to set up properly. I have about 3 years of drupal experience and 10+ coding PHP which definitely helps. I was reading the thread about the teacher guy who was trying to set it up and you patiently helped him through what were all the common pitfalls which you did outline pretty verbosely in your README...
That said, I can't really offer any suggestions to make the process more "user friendly" to avoid this kind of confusion. It is a complex module that does complex things and thus a complex approach seems to be required..
There were two main issues I did have, maybe you've already fixed them, if not I'll post it as a separate bug report:
1) Renaming / deleting membership types doesn't always work; mainly if a membership type was deleted it still showed up on the list
2) As you specified in the README, it seems to work best if your site's set up to grant instant access upon registration, and not so well if it's set up to require email verification. It would be nice if you could capture all the required information BEFORE the user is email verified, rather than on their first login. This would be especially relevant if you had it set up where the admin had to approve user account requests. Then the admin would be able to review the "required" forms the user submitted in order to decide whether to approve the user.
I realize that #2 above may be limited by Drupal's user hooks and maybe that's why you did it the way you did.
I can also forsee a possible situation where a user has registered for a certain membership type and down the road may want to switch types, or even better, "add on" a new membership type to their account. If Drupal allowed multiple registrations from the same email address, this wouldn't be a problem, we'd just require the user to register an account for each membership he wanted. But it doesn't...
FYI, I am using your module in conjunction with pageroute and the eCommerce module and a couple custom modules I wrote, in order to allow users to register for an event, fill out the appropriate registration forms, then based on their membership type, have the "product" they are registering for auto-added to their shopping cart, then taken through a couple pages of "users who registered for this event also purchased these items", then finally to the checkout screen where they complete their order. All considered, it does work pretty darn well...
Thanks
#6
Thanks so much for the feedback and validation of my methods. So often, people are quick to complain but not to help out!
As for the bugs you mention, I am not aware of #1, but perhaps it has been posted elsewhere - I haven't had much time lately to fix things. I'll be slower through the second week of October than I have in the past at getting out bug fixes. So if it is a new bug, by all means, post it.
As for #2, I wanted to do it that way in the first place but couldn't figure out how. The problem lies in using nodes for profile data storage and the nodeprofile module to that effect. Since nodeprofile nodes must only be created one-per-user, that means the user and user ID must exist prior to node creation. I tired to come up with a way to allow the anonymous user to create the nodes, then reassign them to the new user, but if two users are signing up at the same time, one or both of them will get screwed up.
The only way to collect all data first would be for my module to somehow duplicate the cck fields as a separate form parallel to what the nodes would be, temporarily store the collected data with a reference to the user ID, then when the user is authenticated and approved by the admin, create the actual nodeprofile nodes programmatically using the temporarily stored data, and finally delete that temporary data.
You may be interested to know that at some point (next year) I will need to add the ability to sign up to subsections of my site (with separate terms and conditions, etc.). So I will be creating something that will allow that. I don't know whether that will work for your application or not. However, I will probably enhance the current module, or create a submodule, where you can specify either additional pages, or an entirely additional pageroute that would be added to the previous membership. I will also allow the auto-assignment of an additional role based on the additional/upgraded membership type and probably enhance the accounttypes module to work with this as well.
I will also be creating a module for sub-accounts which you might also be able to use, though they will work quite differently and will need a separate email address. I will be creating it so that kids can sign up under their parents and the parents will have certain admin rights over their kids. The kids' accounts will be regular Drupal accounts. I haven't yet worked out whether the parent will create the account or the child. If the child does, I'll have a mechanism whereby they can't do anything until the parent is notified and the child is given permission.
Thanks for letting me ramble.
I just had a thought about your #2 - what if I allowed users that haven't been turned on by the admin to at least fill out their nodeprofile pages? Would they even be able to log in? Or are logins rejected before that point? Perhaps I could hijack the rejection if I can verify the login and the nodeprofile pages aren't filled in yet. Hmm.