Cannot logon to vBulletin Admin Control Panel

This is a bug and needs to be fixed in 2.x.

I ran into this testing 2.0-beta1, but there is a way to work around it in the interim. Take the following steps in the vBulletin database:

1. Initially, do *not* delete the new admin record that is created as a Junior Member. This information is needed.
2. Copy the user name, email, password and salt values from the Junior Member record to the Administrator record. Overwrite whatever is there.
3. Delete the Junior Member admin record from the user table, and also delete related IDs in the userfield and usertextfield tables.

At this point you should be able to log out of Drupal, log back in, and be connected as an admin in both Drupal and vBulletin.

Note: DrupalvB currently does not know whether an admin wants to overwrite or ignore existing vB users during the export. IMHO, this needs to be an configurable option for the export action.
However, there's one caveat when an admin does not overwrite (reset) passwords of existing users in vB: Dual logins won't work for those users, because the password in Drupal is not identical to the one in vB.

Any thoughts on this would be appreciated.

One way to handle it would be to create a new table in the Drupal datbase something like drupal_vb_ignore. In this table you could have the first column be uid (from Drupal's users table) and the second column be userid (from vBulletin's user table).

If the admin selects to ignore existing vB users during the export, those IDs would be collected from vBulletin and inserted into the drupal_vb_ignore table along with the Drupal uid. Then when a user logs into Drupal, a check can be done against the drupal_vb_ignore table to see if there is a match. If so, the user should be logged in to vBulletin as well.

Whenever an admin performs an export, Drupal vB would need to have a check against the drupal_vb_ignore table to see if new records need to be added, or existing records need to be deleted in the case where the admin has decided to overwrite existing vB users.

Hm. Maybe I didn't get your point... We already need to check whether a Drupal user already exists in vB during the export (*live* in vB's users table), so there's no need to duplicate that information in another table.

Based on my arguments in #3, I tend to simply overwrite the passwords of already existing users. The goal of this module is an integration between Drupal and vB -- so if users cannot login due to asynchronous passwords, this will result in plenty of bug reports.

Attached patch updates the password of an existing user in vB during user export. Please test.

Tested this myself.