1

Issue Summary

After successfully going through the migration script redash-toolbelt/redash_toolbelt/docs/redash-migrate at master · getredash/redash-toolbelt · GitHub , meta.json was generated with user invite links.

However, some of my users’ invite links have expired. Our mail server isn’t set up so we can’t use the “I forgot my password” process. How do I get these users to login?

Technical details:

2

Use this API:

curl --request POST \
  --url http(s)://<redash host>/api/users/<user-id>/reset_password \
  --header 'Authorization: Key <admin-api-key>' \
  --header 'Content-Type: application/json' \
  --data '{}'

It will return a response that includes a new password reset link.

1 Like
3

As a data point, that …/reset_password link wasn’t working for me tonight in a customer’s v10 (release image) instance. It just kept on returning:

{"message": "Not found"}

That “not found” response kind of looks like I’d made a typo or something. But no, it definitely was correct, and the same url without the /reset_password text fragment after the user id indeed returned the user’s info json. And later on, the /disable version of the url worked for the users.

At some point I’ll probably investigate with a debugger in a development instance to gain more insight, but that’s not here and now. So, just mentioning it for awareness in the meantime. :smile:

4

It didn’t work because the user is disabled. You can’t reset passwords for disabled users. If you look at the API response from the /users endpoint you’ll see that is_disabled: true.

This message is generated on these two lines:

To re-enable the user:

  1. Go to Settings > Users
  2. Filter by Disabled Users
  3. Select the user you’d like to enable
  4. Click the “Enable User” button
  5. Try your network request again

Or if you need to do a lot of them, use the API to DELETE to /api/users/<user_id>/disable. This “deletes” the disabled status.

We should probably update the message to be more clear :slight_smile:

1 Like
5

Interesting. I captured the json output after the migration, and for that user in the target instance it had:

  "disabled_at": null,

Hmmm, I could potentially run the migration again into a test instance to double check that, but it won’t be tonight.

I’ll try to double check this over the next few days (just in case), around other things. :smile: