CiviCRM Community Forums (archive)

this is, admittedly, a challenge for determining workflow.

yes -- it blocks access if your membership is expired, which means the user can't login and renew their membership. of course, blocking the user is sort of the whole point of the plugin.

in v1.1 we added a feature so you could redirect the user to a contribution page. the way that feature works is it determines if your credentials authenticated, but blocks you from actually logging in. since at that point it knows who you are as a civi contact, it redirects you to the selected contribution page and uses a checksum value to populate the form with your data. i think this was a pretty effective solution for a somewhat complex problem.

if that functionality is not working, please describe what you're seeing. if you're using v2 of this extension with Civi 4/J1.6+, please indicate such. i've not tested that particular functionality with the new version of the plugin.

so here's the thing --
the whole point of that plugin is to block access if the user doesn't have a current membership. all the other settings are subservient to that first criteria. if you don't have a current membership -- we don't really need to worry about other ACL group settings.

so if a user tries to login, doesn't have a current membership and thus is rejected, what do we do?
we have to block them so that they can't gain access. but after doing that, we provide two options -- redirect to a normal menu item, where you do whatever, or redirect to a contrib page with the special behavior to increase the likelihood of a smooth renewal.

i guess one additional potential feature would be to alter their group level and proceed with the login. i suppose you could use that to give them low level access and then redirect to a desired page. in your use case, you'd still need to control redirection to the respective contrib page. I'm not sure you'd gain much over the current contrib page redirection behavior.

bottom line is that you want to block/control access, but also steer in the desired direction.
personally, i would create a new contrib page that is stripped down and contains all the renewal options. maybe not ideal, but i think it's the easiest way to facilitate renewal in this scenario.

it is a bug, unfortunately.
it's been patched here: http://issues.civicrm.org/jira/browse/CRM-8634

and will be in the next revision release of 4.x

basically the entire createJoomlaUser function was rewritten (i did more than just fix the activation issue -- i updated/improved how we handle the user creation).

so you can just copy the function (or entire file) to your version of the file:
https://fisheye2.atlassian.com/browse/~raw,r=35671/CiviCRM/branches/v4.0/CRM/Core/BAO/CMSUser.php#r35671

the second patch is more trivial. it improves how we construct the name value in the j user.

i'm not actually on the official team. 

just part of the development community -- the unofficial team.
you'll find the civicrm community has a lot of community-developers contributing back to help improve the software.