Adding in unlocks controller and specs. This should resolve #927.

[brycesenz]

This should resolve the core issue of #927. However, it has these known shortcomings (and perhaps more that I haven't identified):

1. The redirect after an unlock is just the root path (i.e. '/'), and it is set in a controller method. I'm not as familiar with how the library does configuration and default handling, but this would make more sense as a configurable option.
2. The messages for the Unlocks controller only have English translations in the locales

[zachfeldman]

Thanks so much @brycesenz !

Any reason some of the tests are commented out? Otherwise looks pretty good to me, especially for a first cut.

[brycesenz]

@zachfeldman - oh, haha, probably just human error. Like I said, I'm awful with Minitest - I couldn't figure out the command to test just one spec in isolation (as opposed to the whole file), so I took to commenting things out once they worked. Please let me know the rest of your thoughts once you've had a chance to review.

Also, as should be clear from the code, I added an API endpoint to let a user trigger an unlock email to be sent to his/her account (a create method in the controller). The specs cover that as well, but I do want to call it out since it's functionality beyond the scope just of this issue.

[zachfeldman]

No problem, mind uncommenting that so we can run Travis against it?

Yeah that sounds like a good thing to have! Thanks for pointing it out.

[zachfeldman]

All checks have passed. Going to approve this - if one more person does, I will merge.

[MaicolBen]

Nice work there, I feel you about Minitest, however, you did great testing!

But I don't like some copy/pasted code from SessionsController. In fact you didn't take into account a recent change in the providers' query: #964

Can you in some way refactor the first part of the create method to a concern or to the DeviseTokenAuth::ApplicationController ? Let us know if you can't.

[brycesenz]

@MaicolBen - Haha, yeah, I ripped a lot of stuff from the PasswordsController actually. The two are very similar! That provider change has actually not made its way into the PasswordsController yet I see - good reason to abstract it! Is that the only part of the create action that you were talking about refactoring? It seems like a fair bit of the library could use some refactoring (no offense; that's the nature of open source sometimes), but I don't want to have the scope of this PR bleed too far.

[brycesenz]

Ok, submitted a refactor with a new module. Some parts of the code still aren't really clear to me - for example, this block appears in theApplicationController, but if I try to move it to a separate module, specs start failing. And minitest unfortunately gives me so many warnings that it's hard to track down what's actually going wrong.

    def resource_class(m=nil)
      if m
        mapping = Devise.mappings[m]
      else
        mapping = Devise.mappings[resource_name] || Devise.mappings.values.first
      end

      mapping.to
    end

[MaicolBen]

You didn't give me time to tell you to not do it if it were too much effort! But you did great work! I will review it. I'm thinking in cleaning it more in the future.

[lynndylanhurley]

It seems like a fair bit of the library could use some refactoring

Agreed. The code climate score for this project is really embarrassing x_x

[brycesenz]

@lynndylanhurley - But the test coverage is solid! I mean for real - I would not have had the confidence to change anything if I didn't have a test suite to run against to make sure I didn't break anything. Y'all have done an awesome job keeping the test suite in order!

[MaicolBen]

Shouldn't be :uid instead?

[MaicolBen]

Is this message correct? I would put request unlock without email

[brycesenz]

@MaicolBen - Both of those points are valid. I have incorporated those changes into the PR.

[zachfeldman]

Looks good to me! Love the ResourceFinder abstraction. Merging