CRM-1468 attempting to delete a contact results in a non-recoverable error

Can u give exact steps to reproduce the error. i tried deleting a few contacts from the sample database and it worked fine. i also deleted all contacts in the test and that worked also

no response from the user for my previous comment

dude,

it's been what, three days, including a widely celebrated holiday?

i appreciate your efforts, etc., but do you really think that three days is sufficient time to wait for a reply before closing a bug?

let's see what i'd have to do to reply:

• take the whole site down to make sure i'm playing with a fresh deck.
• set everything up. wait 3 hours for my 16000 record contact list to get ingested (yes, 3 hours. that's going to be my next bug report).
• try again.
• if it doesn't work, try a smaller list. maybe switch to another version of PHP. maybe down grade my apache to see if that's a problem.

that is, actually try to debug it.

i'm willing to spend a considerable amount of time getting this to work (as I've already demonstrated with other bug reports I've filed), but not if it's on this sort of schedule.

closing a bug after this short of time is way too harsh.

apologies for closing it, but we've had people file reports and disappear.

Sorry about the lame first error report – not too much content there.

I'm running Debian Etch, php5, apache 2.2.3, drupal 4.7.4

I've applied one patch to drupal (the "session_2.patch" see http://drupal.org/node/93945#comment-155161)

mysql -V reports:
mysql Ver 14.12 Distrib 5.0.30, for pc-linux-gnu (i486) using readline 5.2

I'm using civicrm-1.6.8022-drupal-php5.tar.gz.

I've performed a fresh install of drupal, then civicrm. I installed the
test data from civicrm_generated.mysql.

After enabling the CiviCRM module and its blocks, I performed the following steps

1. Click the "Find Contacts" item in the CiviCRM menu block
2. Click on "Search" to request the entire list
3. Select the first item "Adams, Brz?czys?aw"
4. Choose "Delete Contacts" from the selector above the contact list
5. Click on "Go"
6. Click on "Delete Contacts" when the warning page comes up

and the error message pops up.

I'll be in sporadic web contact over the next week.

More info. The error is coming from CRM_Type_validate(). Here's a backtrace:

========================
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Utils/Type.php, backtrace, 225
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/DAO.php, validate, 633
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/DAO.php, composeQuery, 597
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Member/BAO/Membership.php, executeQuery, 282
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Contact/BAO/Contact.php, deleteContact, 1259
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Contact/Form/Task/Delete.php, deleteContact, 114
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/QuickForm/Action/Done.php, postProcess, 80
/var/www/drupal-4.7.4-test/modules/civicrm/packages/HTML/QuickForm/Controller.php, perform, 195
/var/www/drupal-4.7.4-test/modules/civicrm/packages/HTML/QuickForm/Page.php, handle, 95
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/Controller.php, handle, 173
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/Invoke.php, run, 406
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/Invoke.php, search, 326
/var/www/drupal-4.7.4-test/modules/civicrm/CRM/Core/Invoke.php, contact, 80
/var/www/drupal-4.7.4-test/modules/civicrm/drupal/civicrm.module, invoke, 284
, civicrm_invoke,
/var/www/drupal-4.7.4-test/includes/menu.inc, call_user_func_array, 418
/var/www/drupal-4.7.4-test/index.php, menu_execute_active_handler, 15
========================

The problem is that in CRM_Member_BAO_Membership::deleteContact userID is not defined
when CRM_Core_DAO::executeQuery is called. I'm not sure
where userID is supposed to come from – obviously it's not in the session, or the
$session->get( 'userID' ) would work.

I'm running this as the admin account. Might that be the problem?

just tried this with a new, non-admin account. I still get the same error.

diab:

what happens when

1. you click on my account? is there a civicrm contact for that drupal user

2. can u see the contents of civicrm_uf_match and see if there are any entries for various drupal id's

3. what email adresses are u using for your various drupal users. are they valid internet email addresses

#3 was the problem. fido@localhost is valid in the sense that mail is deliverable, but it doesn't match the regex. fido@localhost.localdomain made things work. I'm using this on a LAN isolated from the internet (for security reaons) with only local email, so specifying the full domain name (which doesn't actually exist) is not a natural form for the email addresses.

I strongly suggest that such validation errors be caught at an earlier stage where enough information is available so that a useful error message is presented to the operator. Mysterious errors such as this one lead to frustration and an impression that the product is a buggy mess that's not robust enough to pass on to technically unsophisticated users (like most volunteers) Now that things are working, I see that many of the other problems that I've been seeing and which have really been frustrating to understand are caused by invalid contact information.

This raises the question of why an administrative user needs to be in the contact list. They may be not be a constituent per se (there's at least one person that I'm working with who fits that bill). I'd like them to be drupal users, but not in the contact list. Is there some way around this requirement, or I'm I missing something?

Thanks,
Diab

the root cause is primarily integration between two systems always makes things like error reporting a bit more challenging in some parts. We do agree that the above is not ideal. CiviCRM uses the PEAR email reporting rule which is more strict than the drupal one.

The underlying model is all CMS (drupal) users are contacts. This is a super important assumption and rule since all tracking, access control is done on contact id.

Reopening closed issues to make them editable.

Changing the issue to resolved and unverified for 1.8.

Make the issue unverified for 1.8.

Assigning to Rupam for 1.8 verification.