Persist allow_password_change in the database

[MohamedBassem]

Fixes #481
@resource.allow_password_change is not persisted across requests which makes it impossible to reset a user's password after a password reset when config.check_current_password_before_update is set to :password.
This pull request:
1- Modifies the generators to add the new column.
2- Adds a new test to cover this case.
3- Removes the old attribute accessors.

[bernica]

I think you should add the new attribute to the except list at token_validation_response (User concern) so it doesn't get serialized.

[bernica]

@MohamedBassem @lynndylanhurley Any news on this?

[zachfeldman]

Makes sense to me and no merge conflicts. Didn't review the code but will try to come back to this soon has anyone else reviewed the code here? @bernica perhaps you can commit the change you recommended?

[lynndylanhurley]

I'm cleaning up the test suite and the original test around this feature is now failing. Looking at this now and I'm not sure how it was ever passing.

[misham]

I know this has already been merged in and I'm coming late to the party but how are existing users supposed to leverage this now? Is the expectation to regenerate the User migration or .... ?

Some kind of docs on this would be amazing. Happy to write something up, but given the current state of the code, the only way forward I see is a manually generated migration.

If this is the expected path forward, let me know and I can create a wiki page.

[lynndylanhurley]

@misham - that's a good question. should we include a new migration for the fix? how is this situation usually handled by other gems?

[misham]

The "easy button" option would be a separate migration that is created for existing installs for the default case. That is, User model exists with the default columns.

Bonus points would be to use the configuration in the existing app to detect what the model is/are and create migration(s) for everything that's needed.

If the above is not feasible, then an upgrade section in the README would be the next best thing.

One caveat to the above, I solved this by implementing a version of the solution proposed here: #481 (comment)

So I had to back my changes out before I anything else. Not sure how that plays into this though.

[zachfeldman]

@misham I'd be down to see a pull request for either that migration and/or an upgrade to the README. Thanks for your suggestions.