Content Profile Create User

Looks good, but please rename admin.inc to content_profile_create_user.admin.inc

nice job

This looks good. Can I subscribe to this in support of project-ifying it?

you have to wait till someone with enough permissions will approve this

    'title' => t('Content Profile: Create User'),

In hook_menu() (for bizarre reasons) you don't put title or description in t().

    'title' => 'Creating Users',
...
    drupal_set_messge('Could not create user, no email found for ' . $node->title, 'error');

However, most other places you do - these are missing it.

I like how you clearly separated out private and api functions.

function content_profile_create_user_mail($key, &$mesasge, $params) {
    $language = $message['language'];

The misspelling of $message in the parameter means that this function can't even work, as far as I can tell. Has this module been tested?

You'll probably want to use http://drupal.org/project/reroute_email for this kind of testing.

subscribing, i have a very similar use case.

hope this becomes a full project soon :)

one of my developers is trialling it at the moment. Preliminary reports is that he struggled to find the per-user functionality, but found the bulk stuff ok.

Our use case specifically revolves around taking individual existing records and turning them into users with that record as a content profile, from the node view; bulk operations aren't useful to us.

To give you some additional context, we're setting this up for a school, and while we collect data for every potential student, only those that are successfully enrolled are turned into a full user.

We still are trialling the project on a dev server for our dev server :P

once we have something that works for us, we'll try to roll it into a patch and send it back your way. Hopefully you find some of it useful :)

I am working on a project that this would come in very handy. How would I go about getting a dev copy of the module to test out?

Thanks!

i'm not sure how useful this patch is, we ended up hacking it up a lot, and it definitely doesn't follow Drupal's formatting standards any more, but i said i'd post it so here it is :)

thanks a lot for the base that we could work on!

we had to drop the form into its own tab, so it needed to work in a block, not just on the node edit form.

also, we needed the functionality of creating a single user from a content profile node to work on a node that was created by a priviledged user, not just an anonymous user, which was an issue because Content Profile assigns a profile to a user based only on the authoring info, so we ended up creating a rule (using the Rules module) that set the "authored by" info on any node saved by users of a particular role to anonymous.

the obvious caveat to doing this with a simple rule like that is that users with this new role can never have a profile, but that's fine for our use case.

Patches like #20 are a lot more useful in the module's issue queue.

what would you call the issue? we changed the wording of notifications, the way the form was displayed, some of the logic for creation of users.

would i just say "general changes" and put the patch there?

Normally one would split the changes into logical chunks and file and issue for each one with a good title and a good description. Then the maintainer can work with you on what to do.

If you filed an issue in one of my queues entitled "general changes" I would just mark it "won't fix" and ignore it unless there were a great explanation.

ah, i c. i actually didn't realize that the sandbox pages had their own issue queue too, i thought it was just for full projects.

unfortunately i probably won't get the chance to reroll that patch into smaller ones, so it will probably disappear into the abyss :(

but i'll take your suggestions on board for the future, thanks!

we put the form in a block because we wanted to display it on it's own tab on the node page, but suspected that those requirements might change so wanted to keep the form "mobile" in case we had to move it again :P

not something i would expect you to include in the contrib module.

the use case you might be interested in for this project is that we have 2 roles, "student" and "student admin".

students all apply to the organization offline, and the student admin record their contact details/history as nodes and then some % of those students are successfully enrolled.

we use your module to provide newly enrolled students with a login into the system at the same time as attaching their admin record as a content profile to their account.

the first problem we addressed was allowing users other than uid 1 to use the module.

the second problem that we encountered was that when a student admin creates a content profile node, the content profile module assumed that the student admin was making a profile for themselves, not somebody else, so we used Rules to set the authoring information on the "student profile" content type to anonymous upon saving if the author had the student admin role.

lastly, we changed the wording of some of the warning messages to make them more descriptive for our use case.

yeah man, we use features a lot in-house, if you haven't used it much, i highly recommend that you get stuck into it! (and look into Aegir, or at least Drush Make to really help leverage it).

i guess the developer who was actually tweaking this module for me didn't realize that what you'd set up was available to modify in an admin screen and exposed to features, or he just figured it would be easier to modify the strings while he was already editing other things in the PHP files.

the Rules thing was a "quick fix" as it is more of a work-around than an intended new "feature" (lower case :P) of the module itself.

if you were going to set Rules as an "optional dependency" it might be better to release a Feature (capitalized) alongside this project that demonstrates the work around as a "recipe".

also:

* we only need 1 content profile node per created user, we have a second type of profile node for info we collect after the student has been enrolled. Pretty sure an error is thrown if you try to create a user that already exists from a new proto-profile node.
* our solution means that the user role that is creating users can't really have a profile of that type set to their own account. This is fine for our specific "admin/student" use case, as admins will never need a student record but this system probably won't be flexible enough for many other use cases (which is why this might be better bundled as a Feature)

still pretty new to making patches actually, there's definitely a chance that i did it wrong.

i hope this gets turned into a full project sometime soon!

* info file has wrong line endings('\r'), should be '\n' unis line endings
* content_profile_create_user_block() has no correct doc block
* "@param $nids The nids of the nodes for which to create users" the description of the parameter needs to be on a new line, see http://drupal.org/node/1354#functions . Also at other places.
* module file, line 286: why is there a ';' ?
* _default_subject(): all functions of your module need to be properly prefixed with the module name to avoid name clashes with other modules

Great, some minor things:
* README.txt is missing
* create a release branch, e.g. 6.x-1.x and work from there, see http://drupal.org/node/1015226

Now before I mark your application as RTBC, would you be so kind and do a review of one of the other project applications as well? We have currently quite a backlog and need every help we can get. Just pick one from this list and notify me here if you have done so: http://drupal.org/project/issues/projectapplications?status=8

Thank you

Thanks for your contribution, ianwremmel! Welcome to the community of project contributors on drupal.org.

I've granted you the git vetted user role which will let you promote this to a full project and also create new projects as either sandbox or "full" projects depending on which you feel is best.

Thanks, also, for your patience with the review process. Anyone is welcome to participate in the review process. Please consider continuing to review other projects that are pending review. I encourage you to learn more about that process and join the group of reviewers.