Pre-auth role permissions are wrong with another module calls user_access before logintoboggan_init runs

I ran into a similar problem with the 6.x branch, this one was with comment permissions. We didn't want pre-auth userss to post comments, but they were allowed to. I moved the LoginToboggan weight to -2 and it was fixed.

Here are some patches... the 6.x patch should work on both 6.x-1.x and 6.x-2.x

the problem is, the current hook ordering system is poorly equipped to handle dependencies like this. unless there are two modules that are *always* installed and run together, it seems like a cat chasing it's tail to try and fix this via 'official' module weighting.

in this case, i think it's better to just make site admins aware that they may need to adjust module weights for their install. not ideal, i know, but really the best approach given the current limitations.

i'd be more in favor of a patch that adds some documentation to the README or INSTALL files letting site admins know of this possible situation.

I think adjusting the weight in the module is a good idea. I found this effect of LT very surprising, and in it can certainly create a security problem; imagine if on my site, a spammer had realized he could send spam from an unconfirmed account, and had blasted out thousands of mails before I realized what was going on.

A note in the README is very easy to miss, especially if at the time LT is installed this problem isn't an issue, but installing a module later triggers this problem. If the solution is a documentation change, I would recommend it be placed in the UI near the option to enable an unconfirmed user, since the consequences of missing it are so dire.

A module weight of -2 seems likely to solve the problem for basically all users. Yes, module weights are a bit of a hack in Drupal, but that's not a good reason to ignore them altogether when an easy fix presents itself.

@jrglasgow: i don't see how you can be running into the exact same issue as scottgifford if you're running the latest 6.x release. if you examine _logintoboggan_user_roles_alter(), which is called in logintoboggan_init(), you'll see that the permissions cache is reset by LT.

@scottgifford: which means that your problem could be solved by upgrading to 6.x :)

let's cover the issue with 5.x, since user_access() doesn't allow the hack we use in 6.x...

A module weight of -2 seems likely to solve the problem for basically all users. Yes, module weights are a bit of a hack in Drupal, but that's not a good reason to ignore them altogether when an easy fix presents itself.

yes, it's an easy fix for the problem you describe when considered with the other contrib module you're using. however, that's only one piece of the weighting mess. there's also:

1. other contribs using a hook init that would set their module weight less than (or possibly equal to) -2. there are already > 4000 contribs around -- a quick grep shows ~635 modules that implement hook_init(). i have no idea which of those might fall into that category. anybody interested in reviewing the hook_init() implementations of 635 modules, please speak up now... ;) otherwise, we're simply guessing that a weight of -2 is the best fix. and, while we're on the subject of another modules hook_init() messing up LT's functionality, there's also the reverse problem: if a module runs hook_init() *after* LT, and it reloads the global user object, we're right back in the same mess. this means that moving LT's weight lower would make that problem worse.
2. the fact that *every* hook now runs with the new weighting, not just hook_init(). LT of course uses other hooks, and the global reweight could very well bust other things. i don't really think it's a good idea to introduce that kind of possible instability into stable branches of the module. there would need to be extensive testing in order to ensure this problem didn't bite us. any volunteers here?

considering the above problems, and the workload involved, and the fact the 5.x won't live all that much longer, and the fact that there's a workaround for those few people that actually experience this issue, i'm not very convinced we should do reweighting.

given my reasoning in #5, and the fact that i haven't heard anything in awhile, i've decided that this issue isn't worth addressing in 5.x.

@hunmonk, yes, I planned to post straightforward solutions to the problems you mentioned above, but as I dug around in the code no obvious solutions presented themselves. I will live with my workaround for now. Thanks!