Our current task is to weave these forms into Argon’s pages.
For example, Argon’s
register page is pretty, but it doesn’t actually do anything. We’re going to copy the
contents of register.html.erb into devise/registrations/new.html.erb.
Then we pull in the Rails form helpers generated by Devise into the Argon form.
You might also notice the
authentication layout. I’ve defined a custom layout for our Devise views, since
they all look pretty much the same.
I’ve declared this layout in my own controllers that extend Devise controllers:
RegistrationsController, SessionsController, and
PasswordsController. These small, one-line controllers allow me to say Hey Rails -
use the authentication layout for this controller’s pages, but use the existing Devise
controller for everything else.
I also have to tell Devise about my controllers in routes.rb:
Chapter 6 - Add Accounts and associate with Users and
I’m not gonna lie - this chapter really should’ve been immediately after Chapter 2 where we
added Users with Devise. But better late than never!
You may have noticed the glaring oversight in BugTracker’s security - every user can view,
edit, and delete all bugs from all users. Not ideal.
Users should only be able to view, edit, and delete their own bugs. But really,
users belong to teams, and all teams should have access to all bugs reported by users in their
So we’ll take this as a great opportunity to introduce an Account model.
Think of an Account as a team. An Account has_many Users, and
Bugs belong_to an Account rather than individual Users.
6.1 - Set up Account model and associations
this commit, we create the Account model and its
has_many association with Bug.
(Later we’ll add the belongs_to Account association in Bug that we
6.2 - Create new Account when users register
We don’t yet have the ability for Users to invite other Users to
their Account. Right now, we create a new Account for all
Users when they join.
Creating both resources at the same time adds a bit more complexity than it might seem at
the surface (would’ve been much easier to do this earlier!).
When a User registers, we need to create 2 resources: a User and an
Account. To do this all in one fell swoop, we’ll take advantage of the Rails
accepts_nested_attributes_for class method. By adding
accepts_nested_attributes_for :users to Account,
we’ll be able to create a User when we create its parent Account.
To create both resources at once with accepts_nested_attributes_for,
we need to go through the parent (Account), not the child (User).
Which means we need to move our registration views and controller methods from Users