[CompInaBox-discuss] Compinabox using Ruby on Rails Update...

[Eric D N. <nie...@MI...>]

Here's an update on the compinabox rewrite to RoR for the list (and a few others
BCC'd)

I was at a Ruby on Rails training studio for most of last week, and while I had
already taught myself most of what they were teaching, I did come away with a
lot of using tidbits, not to mention living Rails for three days 9-5 in class,
plus hacking away 6-midnight most evenings can really help.

I know I've been saying this for a while, but I am very closs to deploying the
current code base to my beta test server.

I currently have user createable/configurable competitions (no registration
rules or pricing details yet though).  I have rudimentary stats with a basic
registration process in place.

I have four items left on my immediate to-do list:
  Name conflict
  Login/auto-password
  Competition Ownership
  Refactor the admin section

The first two are probably what's holding up the intial beta roll-out.  The
third is needed soon, but the app could be played with by some people without
it.  The fourth is jsut for me as I don't like how that code is arranged right
now.

I'm running into some design issues with the first two however.  Historicially
I've already viewed three main use cases for registration:
a) first-time/infequent user -- I wanted the process to be easy and
straightforward.  I didn't want to require an account creation process before
registration, especially when it was per competition.  This is what the
existing sliding doors was an implementation of.
b) regular user, couple-based -- This was my envisioned "portal" based
registration system that would remember your recent partners/events and
streamline future registrations based on that.  Accounts are required here.
c) regular user, team/studio based -- This is what the Team admin section was
aiming to meet -- people who register a whole team repeatedily.  Accounts are
required here.

Now that all the competitions live in one database, instead of being broken out
part of the justication for a) is gone.  Plus the close-name match problem is
going to be greatly increased due to the larger database.  I'm thinking about
moving to an account required for use, and I'd like to know what you think
about that option?

My current though is that I'll keep the no-log in required path, and like the
current sliding doors, it will generate a password for further changes.  It
will, however also create a full user account with user name auto-generated as
well (something like firstname_lastname_digit), probably with an embedded
special character that will be illegal in regular usernames.  The first time a
user logs in with such a username, they'll be asked to change it and the
autogenerated password.  Does this sound reasonable to y'all?  Should this
happen with the "prime" registrant only, or with all the individuals created
during a registration process?

Other thoughts how how I should handle identity and accounts?

Thanks

eric