2

I am a Rails n00b and have been advised that in order for me to keep track of the status of my user's accounts (i.e. paid, unpaid (and therefore disabled), free trial, etc.) I should use an 'AASM' gem.

So I found one that seems to be the most popular: https://github.com/rubyist/aasm But the instructions are pretty vague.

I have a Users model and a Plan model. User's model manages everything you might expect (username, password, first name, etc.). Plan model manages the subscription plan that users should be assigned to (with the restrictions).

So I am trying to figure out how to use the AASM gem to do what I want to do, but no clue where to start.

Do I create a new model ? Then do I setup a relationship between my User model and the model for AASM ? How do I setup a relationship? As in, a user 'has_many' states ? That doesn't seem to make much sense to me.

Any guidance would be really appreciated.

Thanks.

Edit: If anyone else is confused by AASMs like myself, here is a nice explanation of their function in Rails by the fine folks at Envy Labs: http://blog.envylabs.com/2009/08/the-rails-state-machine/

Edit2: How does this look:

include AASM


  aasm_column :current_state

  aasm_state :paid
  aasm_state :free_trial
  aasm_state :disabled #this is for accounts that have exceed free trial and have not paid
  #aasm_state :free_acct

  aasm_event :pay do
    transitions :to => :paid, :from => [:free_trial, :disabled]
    transitions :to => :disabled, :from => [:free_trial, :paid]
  end
marcamillion
  • 29,563
  • 49
  • 161
  • 337
  • 1
    The envylabs link doesn't work anymore. Here is the working link for that blogpost: http://madewithenvy.com/ecosystem/articles/2009/rails-state-machine/ – Prakash Murthy Oct 20 '15 at 19:50

1 Answers1

3

given it thought and this is what came out:

you're right about not making the states in the Plan, dunno what I was thinking. Either do it in the User model, or make an Account model, which belongs_to :user. Then, in your account try these (it's all about logics, so if you want more states, just mak'em up):

aasm_initial_state :free

aasm_state :free
aasm_state :paid
aasm_state :disabled

aasm_event :pay do
  transitions :to => :paid, :from => [:free, :disabled]
end

aasm_event :disable do
  transitions :to => :disabled, :from => [:free,:paid]
end

So when you create a new user, build an account for it too. Don't worry about the initial state at account creation, it will automatically be set to "free" when an account is created. Or, if it sounds easier, in the User model, as you suggested.

Andrei S
  • 6,232
  • 5
  • 34
  • 51
  • This definitely helps to put things more into perspective for me - given what I have been reading around. Thanks very much for this explanation. – marcamillion Feb 04 '11 at 21:57
  • Btw, I just read that Rails 3 core has a state machine as part of the core. Am I better off using the Rails 3 core state machine or using aasm or some other gem? And why ? – marcamillion Feb 04 '11 at 21:58
  • this question might help: http://stackoverflow.com/questions/349711/ruby-on-rails-state-machines – Andrei S Feb 04 '11 at 22:00
  • I actually stumbled across that earlier, but it looks like that question was asked in 08 - i.e. before Rails 3 came out. – marcamillion Feb 04 '11 at 22:02
  • So just that I understand fully, given my situation, how many transitions would I have ? Only three? A user account can only go from `:free_trial` to `:paid` or `:disabled`. Or from `:disabled` to `:paid`, or from `:paid` to `:disabled` if they missed a payment. Am I missing something or does that sound accurate ? – marcamillion Feb 04 '11 at 22:38
  • Btw, I have updated the question with my updates - how does that look ? – marcamillion Feb 04 '11 at 22:43
  • To answer the "state machine in Rails" question, http://guides.rubyonrails.org/3_0_release_notes.html says: "While an implementation of State Machine has been in Active Record edge for some months now, it has been removed from the Rails 3.0 release." – Michelle Tilley Feb 05 '11 at 00:00
  • Ok Thanks for that BinaryMuse. – marcamillion Feb 05 '11 at 00:47
  • Andrew...one correction to your suggestion here. I should put it in my `User` model, not the `Plan` model, because it is going to be each user that has a different state. – marcamillion Feb 05 '11 at 00:51
  • If you update the answer to reflect this, I will mark it as answered. – marcamillion Feb 05 '11 at 01:09
  • yes, you're right about not putting the state in the plan. edited my answer, i did. – Andrei S Feb 05 '11 at 07:20