Don't create Contact for unapproved Drupal user

[davej]

Hi,

Sorry if this is a duplicate, couldn't find anything relevant but I'm surprised it hasn't come up.

Scenario: a site allows Drupal user registrations with admin approval. 95% of registrations are spam.

Current behaviour: A Civi contact gets created (if no uf match) upon user registration, including all the spam users that subsequently get deleted.

Desired behaviour: A Civi contact gets created (if no uf match) upon a user becoming active (status = 1), which could be at registration time or upon edit by admin, depending on User Settings.

I wondered if this might disrupt e.g. membership/contribution signups. However IIRC the site must allow unapproved registrations here.

Any thoughts? Is there already a way to achieve this?

Dave J

[Donald Lobo]

a few suggestions for the short term:

1. how about using captcha to reduce spam submissions

2. how about implementing a hook that deletes the contact if the user does not get approved?

lobo

[davej]

Hi Lobo,

Thanks for the suggestions.

1. We'll suggest Captcha if we don't come up with anything better, but our clients generally have to be careful about accessibility.

2. Which hook were you thinking of using? Difficult to trigger an action when something doesn't occur!

Guess a proper fix involves testing $user->status in civicrm_user cases insert & update. Do you see any objections to the behaviour I've described becoming standard? Any need for a configurable option? I can't think of a use case for contacts being created when an unapproved/inactive user is created.

Thanks,

Dave J

[Donald Lobo]

the suggestions were for the short term only

i think drupal creates the user and then deletes it if not approved by admin. So u can trap the hook_user and delete the contact

yes, dealing with the status field and making things configurable is a solution for the long term. On the other hand, we also want to keep the code simple and avoid handling all possible cases (since this can explode with multiple CMS's doing things differently). I think if we can delete the contact via the hook when the admin rejects the submission might be a better solution and keeps the core code simple

lobo

[davej]

Hi Lobo,

As far as I'm aware, unapproved users just stay in the users table with status = 0 ("blocked") until an admin manually edits them (to unblock) or deletes them.

I'm wary of deleting a contact upon user deletion, as there are cases when we've wanted to delete a user but keep the contact intact. I guess the hook could check status & only delete if blocked & never logged in.

I was thinking of changes to function civicrm_user in civicrm.module rather than core Civi (or do you count this as core?). And was thinking that there's no need for configurable behaviour, since I can't think of a use case for contacts being created when an unapproved/inactive user is created.

Thanks,

Dave J

[Donald Lobo]

i dont think this will work if civicrm profiles are being exposed on user registration. that data is only collected during user registration and trying to retrieve the data at a later stage will be a lot more work

implementing it via a hook when those conditions are valid seems to be the better option

lobo

[davej]

Thanks Lobo,

Understood. I'll put forward the Captcha & hook options.

Dave J

[xavier]

Would it be possible to have a status (eg no not contact/disabled/temporary...) on the contacts that have been created until the user is enabled/unblocked ?

In general, is there an easy way to identify the contacts that have been created by the end users during the registration (or through event/mailing registration) ?

X+

[petednz]

so did davej make any head way with the hook?

this is another example of needing to deal fundamentally with the problem of orphaning drupal or civicrm records when the other end of the chain gets deleted.

[xavier]

On a related note, I had the pleasure of having my civicrm contact (associated with my drupal admin account) being deleted.

The dashboard and loads of features don't work, quite logically, with not so clear error messages. Took me a while to find the links to create a new civicrm user and associate it with my drupal user...


Anyway, if would be better if there is an extra warning when deleting the civicrm user "This contact is a civicrm user (with a login and password) and you probably don't want to delete it. "

Actually, it seems that the contact was deleted because of a merge, but as we don't have delete history, not sure.

X+

[petednz]

I think an ideal approach would be something like this (in general not specifically for the 'blocked' user)

When about to delete or merge the records needs to indicate if the record has a CMS account associated with it.

Then the delete/merge option should also ask to confirm if the CMS account should also be deleted.

Ideally the same would be observed at Drupal end - ie Drupal Users would be somehow 'marked' to indicate if they have a civicrm record or not.

Meanwhile the hook approach that davej may have taken could be helpful for others.

[Voices Education Project]

Hi,

I have the exact same problem as described in the original post: the majority of our new user accounts are spam, and a new CiviCRM record is created for each one, even though those user accounts have not been approved yet.

However, all of the suggested solutions in this thread are way over my head. Could someone please post (or point me to) step by step instructions on how to address this issue?

We're a very small outfit and no one really has much Drupal/CiviCRM experience at all, so we're muddling along trying to figure things out.

I will say that I did an experiment: I deleted an unapproved spam account on the Drupal side, hoping CiviCRM would pick up on this and delete its corresponding record. Didn't happen.

Thank you!

[marlutin]

A very simple suggestion for implementing an "admin" solution  to identify spammers for deletion when Drupal account are validated by admin.

Assuming that all the new users should be edited by admin to activate each account, setting-up "spam" roles and groups in both applications will help identify "not activated" users, if the account administrators checks on the "spam" role for each rejected (not activated) users.
It's manual, but in this process the validation requires manual validation anyway....
 
1) in Drupal,  setup a role "spam" with no specific access permissions
2) in Civicrm, create an identical "spam" group
3) in Drupal setup a  "CiviGroup Roles sync" btw the Drupal role and Civicrm Group
4) in Civicrm setup any additional profiles rules and create a "smart group" with adequate search setup containing users of "spam" group to bulk delete.

Very basic but may be useful for users afraid of hooking civicrm.