Autoassignrole and drupal 6.10 does not work as it should

I am having the same problem.

I added to autoassignrole.module:

unset($roles[DRUPAL_AUTHENTICATED_RID]); // wnb - fix to remove authenticated user

Right at line 78
$roles = user_roles(TRUE);
unset($roles[DRUPAL_AUTHENTICATED_RID]); // wnb - fix to remove authenticated user

+1

Hello,

That fix isn't enough. If you have roles that you don't want to be made available the problem persists.

I've attached a patch that fixes the real problem.

introfini

???
what this patch fixes?

it adds a true to the function in_array

+   if (!in_array($k, $user_roles, true)) {

It's for the dev version I

introfini

Hi, billnbell. You hide only "authenticated user" from user select, but don't resolve described issue and don't restrict the list of user roles in user role assignment. Unfortunately...

With this bug I have to say that the module results unemployable at all

My patch (#4) fixes the problem.

introfini

Introfini, were i can find patch (#4)... sorry.

http://drupal.org/files/issues/autoassignrole.module_3.patch

Thank You. Just apply and work fine!

I my case the administer role also shows up as a choice for everyone, even though it's box has been left unchecked. Would this patch work for fixing additional roles that you might have created but prefer not to have show up during user registration? these roles would be manually assigned from the administrator. Such roles would be used for user promotions etc not an initial user registration process.

Thanks
Eric

I don't know how use patch :-(
some one knows when the working module will be released?

I second that. I too need this functionality before I can go forward with the Drupal 6 site I am trying to build. With out this basic functionality for user management of multiple type roles anything more than a very bland basic admin controlled site is not very easily obtainable. Patching a live site is not a good option. If someone has used a patch then they have tested that patch and then should submit the module as an upload to be tested further by the people in charge of the module and then that group should release the new module. This may indeed be the process that is going on or should be going on, so that it becomes more readily available to all who need the improved module. I think part of the problem is that not everyone knows when or if the process is actually in progress or not and it appears to be in limbo with what appears to be no forward progress. The responsibility of the person in charge of the module should also be responsible for a community feedback process that gives the project a heartbeat. Lots of people could be waiting in anticipation for a particular module development and not even know that the guy in charge went on vacation somewhere. To make open source work better, it should be an ongoing hand off process. Not a process that says oh well be happy for what you get since it's free. There is a larger picture here that involves a community / industry challenge. If my site is a success because of the work others have contributed then the whole Drupal community wins in a bigger scheme. The main developers behind Drupal should also take a more proactive look at all contributed modules and try to clean up the riff raff process and fragmentations that are the direct result of loosely developed patches. put time lines on all modules that keep the thriving community aspect of Drupal moving in a forward direction, even if these modules are not related to core. All modules represent Drupal as a whole and could also be a broken chain in the link in the big competitive view of Drupal as a whole. I apologize for being so wordy but I am getting tired of jumping through these patch hoops, just to get what I believe should be basic core functionality. Could someone please explain to me why auto assign role is not a basic core function of Drupal?

Eric

To facilitate the testing I’ve uploaded a working module with the patch already applied.

introfini

thanks introfini :-)

Since my site isn't quite live yet, this being the first real setup module my site needs by design before going forward with other modules. I too will test this module on a semi live site. I will let you know how it goes. Thanks for the upload introfini.

Eric

It is a sad situation when beta3 version of a module has such bad bugs..

Hi restyler, could you elaborate a little as to what the bugs you encountered were. I am testing this out right now on my site and I will keep an eye out for problems I encounter. I am not a coder but I will test this module on my site which has very many modules running on it. It is a semi live site that I am building into replacement site for my Drupal 5 site. I can't wait around for just one module to be perfect but I can test it on the fly in a semi live process. This will give a good idea of overall problems I may experience. I will list later all of the modules I have on my site as well as the versions of other associated things such as PHP etc. So far I loaded up the above mentioned zip file and it seem to show the right things on the sign up process. I haven't yet created another user with it because I am setting up some other needed things on my site first. I will report back later what I find. I do agree with the overall beta thing you are implying, it is what happens when not enough people show concern and feedback with each other. Not to take anything away from the creator of this module, however I do believe that this is a feature that core developers need to help with and view as a critical sub module possibly. These are the kind of modules that really make the over Drupal System shine as a winner in CMS. Another area that should be more UI centric and viewed as a critical sub module are Advanced Profile creation tools, Mail attachment features and Multimedia aspects such as a built in Dash player etc. Probably Drupal 7 will be light years ahead of Drupal 6 though on these attributes. Customization is one thing and a good thing but addressing key elements to the core and sub core areas are key. In other words there needs to be an assignment of team based projects that focus on a group of module developers to team up together to advance the development of the so called sub core features of Drupal to expidite these processes. When you have a beta version sitting out here for months that is buggy but represents a crucial feature for most site types, Drupal Loses in this respect. This is the same reason why so many versions of Linux are available. It is the same process that open source allows to happen. On one hand it is good and on another it is self defeative. There will never be one that shines just many that spawn. A perpetual mess so to speak, good for a few but not for the masses. Done with my droning rant, kinda resembles my music haha.

Eric

I also have a problem I can't seem to fix. I keep getting the following error with the DEV version:

user warning: Table 'database.autoassignrole_page' doesn't exist query: SELECT rid, path, display, title, weight FROM autoassignrole_page in /home/iccareca/public_html/sites/all/modules/autoassignrole/autoassignrole.module on line 31.

I tried the patch above but no fix. However the zip file above does work for me but it doesn't seem to be the DEV version because its missing the "register from URL" option that I need.

Any ideas about this error? thanks :)

Hi hugafish, I mean the checkboxes bug that was already fixed by introfini.
I got no any other problems for now.

When does this going to the DEV? I have an urgent need for this. So I will test the zip from #16

+1

Tested patch in comment #4 and was effective.

You are right. I solved the issue by using a triggered rule to assign the right role when someone registers.

Is this fix going in - what version?

Applied the patch in #4 http://drupal.org/cvs?commit=191712

That worked for me too :-)

I just wonder why the patch wasn't applied to the latest donwload (I only download it this morning) ???

Thanks

Yes - Thanks introfini. It would be great to see this patch in an official release sooner rather than later...

I USED the patch by To facilitate the testing I’ve uploaded a working module with the patch already applied.

introfini

autoassignrole.zip 5.43 KB

THIS PATCH WORKED STARIGHT AWAY. PLEASE AVAIL THIS PATCH TO THE MAIN DOWNLOAD SECTION BECAUSE I DOWNLOADED THE WRONG ONE BEFORE I DOWNLOADED THIS CORRECT ONE. thanks again GREAT module and fantacstic patch.
sam

Patch works great -- thank you.

Side note: we have one site in production using the pre-patched version; we'd upgraded the site to 6.10 and it's still working...weird, eh?

We'll probably update it in the next day or so to be sure it won't suddenly go wonky, but any idea why it would keep working on an upgraded site?

Can someone confirm that Dries has put this into the Druapl 6.10 head?

@billnbell This module is not core so it is not possible that Dries has commited it to Drupal 6.10 ... I did find another instance of in_array() not using strict checking and committed it to http://drupal.org/cvs?commit=203748 ... dev release available tomorrow should have the changes.

@GreyHawk /shrug ... I was never able to replicate this issue in my environments so am also at a loss. I appreciate your continued testing.

@samkat I would like to get a few more of the major issues resolved before rolling another beta.

Well it's been a while since I visited this module post. The patch in the zip file in post #16 above seems to be doing well so far without any errors of any kind. I am on Drupal 6.13 and have too many modules to list here. One thing I noticed though is that this module patch I am using does not show up in the available updates module listing. This could be a good thing maybe for now. All of the auto assign settings are within the Admin area to make changes and work as should. Does the latest version of auto assign module contain this same patch as well for me to update and have this module listed within the available updates module? Also I was wondering, I have three roles a user can select just one of upon sign up. One of these roles I would like to have administrative approval on but not the other two. How could I achieve this ? Would this be a feature request ?

Eric