0

I have a custom user-management module in my Drupal 6 site. We are a corporate subscription service and needed a way for a subscribing company's primary user to delete other users from their company. When this happens, we need to not only delete the Drupal user record for that person, but also make some changes to a record in another mySQL database that's connected to one of our internal non-Drupal systems. There's a lot of jquery stuff involved, but the main thing is that a user clicks a delete link next to a name in a list of users. The link looks like this:

http://mysite.com/account/manage/disappear/1/182741

The final three params are what we use - disappear is the action (there are also promote and demote, which allow the primary user to change the type of account other users have), 1 is the Drupal ID of the primary user (in this case, I'm logged in as user 1), and the final param is the ID from our non-Drupal database. From that ID's record, we can find the Drupal account ID we need to delete (as well as other info we need for this function that are not specifically Drupal-related.)

Most of it works correctly - the user is deleted and the email is sent, but the query that's supposed to update our other database doesn't seem to be running. Can anyone help me out? Is there a way to debug queries? I know I'm dealing with the correct records; the error_log line right inside the disappear case returns the correct values.

Here's the function (I've stripped out the promote and drop actions since they work. Also, Viola is our intranet app where the non-Drupal database lives)

function user_manage_function($action, $uid, $viola, $email_prefix = '', $email_domain = '') {

    // action = delete, promote or drop?
    // uid = the UID of the primary user, as a security measure
    // viola = the Viola people ID of the person we want to promote, delete or drop
    // email fields = if the PU adds an email address, we need to verify it

    global $user;

    if ($user->uid == $uid) { # just a sanity check to make sure we know the current primary user

        // see what their UID is ... set $vuid = the drupal uid of the promoted/dropped/deleted user
        $people_row = db_fetch_object(db_query("SELECT institute_uid, email FROM {ismi.new_people} WHERE id = %d", $viola));
        $vuid = $people_row->institute_uid;
        $viola_email = $people_row->email;
        $data = 'pending';

        if ($vuid) {

            switch ($action) {

            case "disappear":
                error_log("inside main disappear - vuid=$vuid and viola=$viola");
                  $quer = db_query("UPDATE {ismi.new_people} SET active = 0, insitute_uid = 0 WHERE id = %d", $viola);
                    user_delete(array(), $vuid);
                    $message = array(
                        'to'                =>  'test@test.com',
                        'subject'       =>  t('User deleted by primary user'),
                        'body'          =>  t($user->name . ' (' .$user->mail.') just deleted the Institute website account for '. $viola_email),
                        'headers'       =>  array('From'=>'test@test.com'),
                    );
                    drupal_mail_send($message);
                    break;
            }

            $data = 'success';
    }
  }
} 
  • Try debug $quer – Codium Jul 26 '11 at 17:14
  • Friendly tip: Try to condense your questions about your actual problem, instead of writing a long explaining about your entire site that's not really needed. Writing background info can be good, but writing too much background info is just puts people out from answering you question as they don't want to read that much to understand a (possible simple) question. If all the info is needed, try to sum up the question first and then provide the long explanation that can be read if the person providing an answer thinks it's needed. – googletorp Jul 26 '11 at 17:17
  • @googletorp - I didn't realize four sentences about exactly what I'm trying to do with this particular function could be considered "a long explaining about your entire site". On SO, if I had not provided that explanation, I would have gotten yelled at for not providing background. – EmmyS Jul 26 '11 at 18:05
  • @drupality - the only reference I can find to debug is at api.drupal.org/api/drupal/includes--common.inc/function/debug/7, which indicates that it's only available in 7 and 8. As stated in my OP, we're on 6. Is there documentation somewhere of that being usable in 6? – EmmyS Jul 26 '11 at 18:06
  • 1
    It's not about adding text or code, but adding unneeded info like you use jQuery, the url a person is redirected to etc etc. I have found that you have a tendency to over explain you problems with background info that's make it harder to find out what info is relevant to the problem at hand. Being precise will improve your questions and the chance to get them answered. Like I said, this is a tip, not something you have to do, but something worth considering. – googletorp Jul 26 '11 at 18:31
3

You write that

but also make some changes to a record in another mySQL database that's connected to one of our internal non-Drupal systems

so I figure that you need to query a different MySQL database, but in your don't change the active database using db_set_active. This is most likely the root to your problem.

If the SELECT query works, then the code you have provided should work just fine.

A simple way to test your problem, would be run db_query on a known record and see if you can alter it. Devel also offers query logging, which would allow you to log the actual UPDATE and alternatively try to run the raw query through a MySQL interface.

Another explanation could be that you have the ismi.new_people table in the Drupal db, so you in fact are updating the wrong table/database.

Another possible problem is database permissions. Do your DB user have read only access?

  • If that's the case, why does the SELECT from ismi.new_people query that sets the $people_row variable work? Is db_set_active only required if you're trying to change records? – EmmyS Jul 26 '11 at 19:53
  • The SELECT and UPDATE query will use same connection, so if one works the other will work as well. The UPDATE query itself is not flawed, which means that the most likely cause to the problem would be some custom database rule/trigger is giving the problem, or some other part in your system overwrite the changes. – googletorp Jul 26 '11 at 20:15
  • @EmmyS: Updated with more possible answers. – googletorp Jul 26 '11 at 20:29
  • Thanks. 1) the SELECT very definitely does work; 2) I AM running db_query on a known record. It doesn't seem to be doing anything. 3) I'll look at Devel, thanks. 4) ismi.new_people is very definitely NOT in my Drupal database. – EmmyS Jul 26 '11 at 20:58
  • Well, Devel doesn't help, and I'll tell you why: jquery. This is why I provide background for my questions. All of our actions in this module are triggered by links. The module has a .js file with a main function called Drupal.behaviors.ismi_account_manager, and each link that's clicked uses Drupal.parseJson to handle the actual code. Because the code is being accessed asynchronously and the actual page doesn't refresh, the queries that run don't get appended to the bottom of the page by Devel. Any other suggestions? There must be a way I can display the actual query in the error log, right? – EmmyS Jul 26 '11 at 21:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.