After the user fills the registration form, if the profile is appropriate, the administrator user approves it, and the profile goes live; if it is not appropriate, the administrator user will reject it, but the user still has the chance to proceed with changing the picture and content until it is appropriate. The administrator user will then review for the second time to be sure everything is fine, and the profile will go live.

How can I achieve this?

1 Answer 1


Step 1: Create a designated role

Create a role like (say) "Member", and use this role within Drupal's Permission system to disallow access to anything on your website for users who do not (yet) have access to this "Member" role. Make sure that for profiles that did not go live yet, you do not grant access to this role.

Step 2: Activate user accounts after registration

When a new registration request arrives, check if it satisfies some minimal requirements to have the account's status be changed to "active" (you don't want to do so for e.g. spammers).

If the request does satisfy your requirements, the administrator just grants the Member role (and is finished with this registration request review).

But if it doesn't satisfy your requirements yet, then the administrator should NOT (repeat NOT) grant the designated role from Step 1. To allow the admin to indicate "I reject", use the Flag module so that the admin can flag such user. Since flags are entities (fieldable), you could also add a (text?) field to have the admin add some kind of "reject reasons". Such flagging could then result in sending an eMail to the registered (not approved yet) user to ask for appropriate changes by the registered user.

Step 3: Wait for the user to apply account updates

After the user (who does not yet have the "Member" role applied new updates to relevant profile fields, send an appropriate eMail to the administrator to request a new profile review. To do so, use the Rules module with a custom rule that looks similar to this one (in Rules export format):

{ "rules_notify_admin_about_selected_profile_updates" : {
    "LABEL" : "Notify admin about selected profile updates",
    "PLUGIN" : "reaction rule",
    "OWNER" : "rules",
    "REQUIRES" : [ "rules" ],
    "ON" : { "user_update" : [] },
    "IF" : [
      { "entity_is_of_type" : { "entity" : [ "site:current-user" ], "type" : "user" } },
      { "NOT user_has_role" : {
          "account" : [ "site:current-user" ],
          "roles" : { "value" : { "4" : "4" } }
      { "data_is" : { "data" : [ "account:uid" ], "value" : [ "site:current-user:uid" ] } },
      { "NOT data_is" : {
          "data" : [ "account-unchanged:field-to-be-approved" ],
          "value" : [ "account:field-to-be-approved" ]
    "DO" : [
      { "drupal_message" : { "message" : "Thanks for updating your account, the site administrator will soon review your updates." } },
      { "mail" : {
          "to" : [ "site:mail" ],
          "subject" : "Updated profile needs your review",
          "message" : "Please review the updates to the profile of user [account:name], located at [account:url].",
          "language" : [ "" ]

Some more details about the magic in the above rule (use the Rules UI to import it in your own site, after you applied relevant changes like the field name):

  • Rules Event: After updating an account
  • Rules Conditions:
    • An entity of type "user" is updated.
    • The account being updated is from the currently logged in user.
    • The user does NOT have the role with ID=4 (which is assumed to match the Member role, adapt this ID to fit your needs).
    • The actual profile field is "some" field you want to monitor / review / approve. In this case I used a field with machine name field_to_be_approved (adapt to fit your own needs, and add similar conditions if you want to check other fields also).
  • Rules Actions:
    • Show an informational message to the user who performed these updates (though only if all Rules Conditions are satisfied).
    • Send an appropriate eMail to the site admin (adapt the content of it to fit your needs).

Step 4:

You may want to add an extra Rules Action in the previous step to unflag the user again. So that the administrator can fag the user again if after updating the profile the administrator still rejects (by repeating from Step 2). However I recommend to NOT add such extra step, so that the administrator can still see the "reject reason" (from Step 2). And if a 2nd reject is needed, all it takes for the admin is to (a) unflag the user and (b) right away flags the user again, but now possibly with a new reject reason. True, an extra click for the administrator, but the advantage is that the prior reject reason (if used) did not automatically get deleted.

At the point where the updates are OK, just have your admin grant access to this role for any registered user as soon as "the profile goes live". A possible way to further automate this is to create another rule which automagically grants the Member role after the admin "unflags" the user (= removes the flag set in Step 2). If you wonder how to do so, use this link ...


The above approach, with some minor variations, could also be used to catch users who after their account got verified, update their profiles in a way that would not have been allowed when they first registered.

  • Though a good start, this is not a complete answer to the question. How would the user apply for a second check? Jun 29, 2016 at 22:40
  • @Neograph734 : curious to hear to what extend I addressed your prior comment with my updated answer ... Nov 30, 2016 at 10:20
  • Much better, though I think you should also reset the flag in Step 3 (in case the update still is not satisfying). (Which invalidates step 4). Nov 30, 2016 at 10:38
  • @Neograph734 you have a valid point I think. Though personally I recommend not to do so. Refer to my updated step 4 in it. So in the end, let the site owner decide which approach is preferred? Nov 30, 2016 at 14:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.