Reactivating a HipChat user without an email server

[Josef Koza]

I have a HipChat Server installation that was installed from the HipChat Server OVA.  One quirk about this installation is that we do not have the server connected to any email servers.  We utilize the server on a disconnected network and use it for chat and notifications (non-email notifications).  We also have the server hooked into a Crowd LDAP (Active Directory) directory for users.

The situation which we are running into is as follows:  One of our users is somehow in an "Unactivated" state.  When looking under the Users section as an admin, in the column for "Last Active" I see "Unactivated (resend email)".  Deactivating and Reactivating the user will continue to show the "Unactivated" state.  When the user tries to log in, there are no error messages presented and the user simply cannot log in.  Clicking on "Log in" after providing the user name and password will reset the page and clear out the user name and password.  No error messages.  Other users can still log in and use HipChat just fine.

1. Is there any way to fix the account so that the user can be activated without an email server?
2. Is it just a bad idea to try and use HipChat without an email server?

Thank you for any and all help.

[David Maye]

Hey all,

I was just made aware of this post. I went back and reviewed the ticket and I believe 4th step should read:

{code}
UPDATE user SET metadata = NULL WHERE id=n;
{code}

Which will wipe any metadata that could keep the user from auth'ing to the directory. The original step number 4 looks like a typo on my part, sorry about that.

Cheers,
-David
HipChat Server Support Engineer | Atlassian

[JohnG]

David,

I had noticed that typo and opted to set an arbitrary confirmation time as follows

UPDATE users SET confirmed=1 WHERE is_deleted=1';
UPDATE users SET metadata='{"confirmation_unix_time": 1479839396}' WHERE is_deleted=1;
UPDATE users SET is_deleted=0;

This specifically confirms and activates all deactivated accounts.

I also went ahead and cleared out the password for external accounts as the local password is not needed

UPDATE users SET password=NULL WHERE external_id is not NULL;

This seems to have resolved our user problem and all accounts are now active and confirmed and users are able to login successfully.

[Josef Koza]

I asked the same question as a support ticket and I got the following answer with a big thanks to David Maye of Atlassian.  Hopefully it is okay for me to share and hopefully it helps someone else.

The situation which we are running into is as follows: One of our users is somehow in an "Unactivated" state. When looking under the Users section as an admin, in the column for "Last Active" I see "Unactivated (resend email)". Deactivating and Reactivating the user will continue to show the "Unactivated" state. When the user tries to log in, there are no error messages presented and the user simply cannot log in. Clicking on "Log in" after providing the user name and password will reset the page and clear out the user name and password. No error messages. Other users can still log in and use HipChat just fine.

It sounds like an admin may have 'deactivated' the user, then reactivated them. In this version, whenever that happens to a user that is linked to an external directory, they get stuck in this 'limbo mode': The user cannot log in, even if the password is changed on the user directory and/or locally. This is due to metadata in the users hipchat user account being added and causes a linked user to be perpetually locked out. The only two ways to clear this is by the email (which contains a link to clear the metadata via means of password reset) or by direct database manipulation. Since the postfix server (embedded email server in HipChat Server) can't reach outbound to send emails, the only way to clear is via the db.

I've outlined out to clear this metadata and restore the user below:

Check for user id

1. Snap-shot your HipChat Server instance (or have a backup available).
2. Log into the HipChat Server web UI. Navigate to GROUP ADMIN then to USERS.
3. Search for the user who is unactivated. Click on their name then look at the URL. It'll say something like https://your.server.address/admin/user/325. In my example, the users id is 325.

Clear metadata and confirm user

1. Log into the HipChat Server terminal

2. Run this command to gain access to the database terminal:

   DBPASS=$(awk '/"pass"/ {gsub(/[",]/,"");print $2}' /hipchat/config/site.json) && mysql -p$DBPASS hipchat

3. Now run this command, be sure to replace n with the user id from the previous step

   UPDATE users SET confirmed=1 WHERE id=n;

4. Same for this command

   UPDATE user SET confirmed = NULL WHERE id=n;

5. Repeat for any other users having the problem.
6. exit to exit back to the command line.

 Clear Redis entry (temporary cache)

1. On the HipChat Server command line, run the following command, replacing n with the user id.

   redis-cli del user:n

2. You're all set. The user should be able to log in now (using their AD password).

1. Is there any way to fix the account so that the user can be activated without an email server?

Yes, detailed above.

2. Is it just a bad idea to try and use HipChat without an email server?

It was designed with email in mind, since that's how users get email (offline) notifications and is a mechanism to confirm user accounts (internal user accounts only) as well as reseting local internal accounts (if any exist). This particular issue you ran into is a bug that will be fixed in an upcoming release, so this workaround is somewhat temporary.

Please let me know if you have any questions!

Cheers,
-David
HipChat Server Support Engineer | Atlassian

[Ansar Rezaei]

Hi
I try this but it didn't work for me

[Philippe Verheyen]

It didn't work for me either...

Are you sure that first you have to do:

UPDATE users SET confirmed=1 WHERE id=n;

And then:

UPDATE users SET confirmed = NULL WHERE id=n;

Is there some kind of trigger which first does something when setting confirmed to 1, and afterwards to null ? Or how should I see this?

Thanks.

Philippe

[JohnG]

Thanks for posting this, hopefully Atlassian will soon add the ability to disable two-step verification for on-premise deployments. Understandably HipChat was a cloud-based product acquired so it takes time for Enterprise features to be incorporated into a product. Does anyone know if there is a HipChat ticket for this feature request?

[Teerace]

I would like to know the answer to that too!