Closed del82 closed 11 years ago
Current validations make this difficult to implement, because the validations require the user's password for any changes to the user record-- not at all conducive to a recent_target field that should be updated all the time and completely transparent to the user. More work to be done here, possibly using the devise gem.
Deferring to 1.1 because this isn't necessary for initial deployment, it makes sense to do this as part of a larger re-working of the user auth machinery.
What if we had some sort of stats table? If we linked this to a user, would we still require their password each time?
I don't know what we'd use the stats table for at the moment... recent target, targets worked on, hits seen, etc?
This is actually kind of insane... Something that takes all of one line in something like PHP takes literally forever in Rails. I have yet to figure it out. I tried branching and switching to Devise, but that wasn't any easier. When they say "not for people just starting Rails" they meant "you're probably going to have to rewrite everything from scratch to make this work."
Anywho... still trying some other hacks.
I implemented this by linking a User to Stats table. This implementation might actually be easier than trying to store that sort of stuff in the User model. One - cause trying to avoid password authentication is all wack. Two - this separates "user" data (e.g. name etc.) and system data about the user (recent target, other stats.)
I'm going to close this as the base is all done. Any changes can either be done without an issue or submitted as a bugfix.
For each user add a recent target, so the user could go to `user/user#/recent and go right back to their most recent target.