Is it possible to assign a role to a 'default' user that registers on the 'default' path?

I'll start to create a patch for this but tell me if something like that is already implemented. or any tips on creating that patch are helpful to since I'm not very experienced in creating patches.

Comments

grasmash’s picture

This feature is not built into PRP, but you can use Auto Assign Role to assign a role to all users on sign up.

The best approach for adding this feature to the current module would be to create an admin settings page (which has been started on the master branch) for PRP. The page could contain fieldsets for each registration path, including the default one. The fieldsets would contain a list of all user roles, which would be applied in the hook_user_presave function.

This actually brings up a good question... I started building this page with each registration path as a role in a draggable table... but now I wonder what the best approach would be for both easy weighing of paths and setting of roles. All help welcome.

scuba_fly’s picture

StatusFileSize
new103.43 KB

Thanks for your reply.
Using Auto Assign Role is an option but it would be great to just select a default profile to assign to users that register as 'default' user ( and not assign the role if another profile ( path ) is selected ( used ) )
The problem with AAR is that it assigns a role to everyone that registers.

To make things clear, what I am trying to achieve is something like the included attachment.
Where '' can be a keyword that makes it posible to register the default path or simply left our ( but i guess that gives complications in the field validation )

maybe it is even possible to alter the default registration path in drupal so you can simply fill in the altered path for the default profiles.

I'm not sure where you mean that draggable table is located. ( admin/structure/profiles ? )
Or do you mean master branch an older or other version?

scuba_fly’s picture

Assigned: Unassigned » scuba_fly

I've build a quick and dirty sollution for testing if my idea works

changed the get_profile_type_by_path() function to return the 'default' $profile_type if $path == NULL:

function get_profile_type_by_path() {
  $profile_type = NULL;
  $path = arg(2);
  
  if($path == NULL) {
      // return default profile
      $path = 'default';
  }
  $profile_type = db_query("SELECT pt.type FROM {profile_type} pt LEFT JOIN {profile2_regpath} pr ON pt.id = pr.profile_id WHERE pr.path = :path AND pr.status = 1", array(':path' => $path))->fetchField();
  return $profile_type;
}

then added the URL path 'default' to a profile so if the default registration (user/register) is used the path (user/register/default) is faked.

this is the eased solution I can think off.

now only thing left is to change the URL path description to tell users that 'default' is a preserved keyword that can be used for de default registration profile ( with no real path ( argument 2 ) set.

I'll try and create a patch just in case someone else want to use this, for myself as learning purpose and a rollback option for future upgrades.
Will post the patch in my next post

scuba_fly’s picture

Status: Active » Needs review
StatusFileSize
new1.37 KB

Created a patch

let me know what you think.

cheers,

Scuba_fly

grasmash’s picture

Thanks for the patch Scuba_fly.

Have you tested this?

I've just made some changes to the module in the dev version that may make this approach more appropriate. Registration paths are now formed in this pattern:

/[regpath]/register

So, I may allow admins to simply enter 'user' for [regpath], and attach the necessary form fields if necessary.

grasmash’s picture

Status: Needs review » Closed (fixed)

This feature has been added. You can now use 'user/register' as the registration path for Profile2 profiles. Doing this will allow you to selectively attach profile fields and roles to the default registration path.

Changes committed to dev.

scuba_fly’s picture

Thanks for the update. I'll use the dev version then so it will be updatable.

scottsawyer’s picture

I posted an issue related to this problem in http://drupal.org/node/1568296 though my issue is related to 7.x.2.x-dev. Any chance of getting this patch to work on that branch?