Rails - Signup code validity check - ruby-on-rails

So, I'm new at this and trying to learn by jumping right in.
I have a slightly odd login in my rails app that works like this:
Admins generate a code and specify an upper limit
Users log in by entering this code and some details which are saved
Models:
class Code < ActiveRecord::Base
has_many :users, dependent: :destroy
attr_accessible :code, :maxusers
end
class User < ActiveRecord::Base
belongs_to :code
attr_accessible :name, :email, :code_id
end
Users controller:
class UsersController < ApplicationController
def create
#user = User.new(params[:user])
if #user.save
redirect_to "/welcome"
end
end
end
So for example the code is 123456 with a limit of 5
The first 5 users can sign up with their Name, Email and 123456
So the question is: How do I check that the code is valid before saving? It must exist and have less than 5 users already assigned.
It seems really simple but I can't figure out the syntax, I was playing with a before_filter in the controller or before save in the model but I'm stuck.

before_filter is a bad idea: models have to bothered about their integrity, not controllers.
You can try something like:
# in your respective model
validate :at_least_five_codes
def at_least_five_codes
errors.add(:base, 'Try another code') unless User.where(code: code).count < 5
end
And you'll be unable to save your model if current code was used for 5 times.

Related

Rails: How to create a user that has a `belongs_to` association

I am brand new to the world of rails so please forgive my ignorance with this question :)
I am currently setting up a new app that has two models:
Account
User
My seed file looks like this:
account = Account.create!(name: 'Account Name')
account.users.create!(
first_name: 'Test',
last_name: 'Test',
email: 'test#test.com,
password: 'test',
owner: true
)
And the users model is:
class User < ApplicationRecord
belongs_to :account
...
end
I have created a custom Devise registrations controller to let new users sign up:
class Users::RegistrationsController < Devise::RegistrationsController
# GET /sign_up
def new
render inertia: 'Auth/Register', props: {}
end
# POST
def create # rubocop:disable Lint/UselessMethodDefinition
super
end
def sign_up_params
params.require(:user).permit( :email, :password, :first_name, :last_name)
end
end
BUT! I need to pre-create an account for a user before I actually create the user here and this is something I have been stuck on for a few days with no luck (to the point I've considered changing the association's).
The error is:
Account must exist
Which makes sense because we don't have an account when we create a new user which is what i need to do before the user is registered.
My best guess was I needed to do something like:
# POST
def create
account = Account.create!(name: 'Test')
account.users.create!(sign_up_params)
end
to mimic the logic of the seeds file but this seems distinctly wrong to me and doesn't work.
So my question is, is it possible and how can I pre-create an Account model for a user and then associate it to the user in the registrations create method before the user is persisted to the database?
In my final production code, the goal would be to create an Account type that will be created and associated with a user on registration but for now just getting a very basic MVC up and running is the goal :)
Thank you so much in advance for any help!
First off, I think the account is supposed to belong to the user, not the opposite.
The user model User.rb should look like this:
has_one :account
And the account model Account.rb should look like this:
belongs_to :user
And to create an account once the user is created, you can simply add this line to your user model:
after_create :create_account
and the account will be created automatically.
What about using?
user = User.new(sign_up_params)
user.build_account(name: 'Test')
user.save!
The problem is the line belongs_to :account in User model.
I would suggest you break your User model in two models
User
UserDetails
You can then add belongs_to :account in UserDetails model.
This will help in independent creation of users, will not be affected by account.
Something like below.
class User < ApplicationRecord
has_one :user_detail
...
end
class UserDetails < ApplicationRecord
belongs_to :user
belongs_to :account
...
end
class Account < ApplicationRecord
has_many :user_details
...
end

Rails 4 + Devise: After create user, create XYZ

I have a User model that gets created through Devise, and after it's creation, I would like to automatically create a new Client (another model in my app). The new Client's atrribute, :user_id, should be equal to the :id of the User that was just created. I believe I need to use something like:
class Users::RegistrationsController < Devise::RegistrationsController
after_create :create_client
def create_client
Client.create(:user_id, :id) # Not sure what should go here
end
end
Is this the correct way to accomplish this? Also, if associations are important Client belongs_to :user and User has_one :client
You can add an after_create callback in User model(user.rb), check here for more information on how to create has_one associations.
class User < ActiveRecord::Base
after_save :add_client
def add_client
self.create_client(client_attribute1: value, client_attribute2: value)
end
end

Rails Devise - How to add more data to current_user

Suppose I have a User model
user.rb
class User < ActiveRecord::Base
...
end
with attributes like: name, username, access
access is an enum that tells me if the user is "staff" or "customer"
To get the name and username of the logged in user, I can do:
current_user.name
current_user.username
And suppose I have a Staff model
staff.rb
class Staff < ActiveRecord::Base
belongs_to :user
end
with attributes like: salary, phone_number
And I also have a Customer model
customer.rb
class Customer < ActiveRecord::Base
belongs_to :user
end
with attributes like: address, phone_number
I want to be able to call this on my staff's controller:
current_user.staff.salary
And this on my customer's controller:
current_user.customer.address
WHAT I TRIED SO FAR
I overwrote sessions_controller.rb
def create
super
model_name = current_user.access.capitalize.constantize
spec = model_name.where(user_id: current_user.id).take
session[:spec] = spec
end
So I'm able to access it via session[:spec], but not via current_user. Any ideas?
Well to begin with, your User model should reference the staff or customer, even if they are to stay blank
class User
has_one :staff
has_one :address
Just by doing this, you should be able to use current_user.customer.address. However...
I suggest you add some convenient methods in ApplicationController or a module that you include
def staff_signed_in?
#staff_signed_in ||= (user_signed_in? and current_user.access == :staff)
end
def current_staff
#current_staff ||= (current_user.staff if staff_logged_in?)
end
# same for customer
# Note that I use instance variables so any database queries are executed only once !
Then you can simply call
<% if customer_signed_in? %>
<h2>Logged in as customer</h2>
<p>Address : <%= current_customer.address %>
<% end %>
EDIT : about your concerns concerning database hits
You gave the example of current_user.customer.cart.products
This is indeed quite a nested association. My suggestion above already reduces it by one level (ie current_customer == current_user.customer). Then you have to go through carts to reach products... it isn't so bad in my opinion.
If you need to call that often (current_customercustomer.cart) you can override the current_customer for a given controller and eager load the resources you know you will use use.
def UserShopController < ApplicationController
# Let's assume current_customer is defined in ApplicationController like I showed above
# UserShopController always uses the customer cart, so let's load it right at the beginning
...
private
# Override with eager loading
def current_customer
#current_customer ||= (current_user.customer.includes(:cart) if customer_logged_in?)
end
add has_one :customer to your user.rb
Your user model should be like below to accessing related model.
class User < ActiveRecord::Base
has_one :customer
end

How to avoid N+1?

I’m building JSON API for a mobile social networking application, users be able to have some posts and other users able to like and comments on those posts.
class Post < ActiveRecord::Base
belongs :user
end
class Like < ActiveRecord::Base
belongs :user
belongs :post, counter_cache: true
end
class PostSerializer < ActiveModel::Serializer
attributes :id, :description, :likes_count, :is_liked
def likes_count
object.likes.size # should pull from counter_cache
end
# did current_user already like this post
def is_liked
object.likes(user_id: scope.id).exists? # N+1
end
end
class PostsController < ApplicationController
def index
#posts = Post.recent
render json: #posts, each_serializer: PostSerializer
end
end
# Output of JSON API to mobile client
{
"id": 1,
"body": "...",
"likes_count": 10,
"is_liked": true
}
User logins into mobile clients and make a request to get recent posts when they open the app, but to be able to generate JSON post response with a flag is_liked, we need to issue query to hit DB to able to know if the user is already liked the post, so on mobile screen we show that status on each post on screen.
I was facing the same problem here, so let's see if I can help you...
When you add belongs_to :post, counter_cache: true in the Like model, you must add a column in the posts table called likes_count type integer.
Also, note that counter caches are incremented or decremented when you create or delete a like, so if you have some data in your database it won't work. You have to reset the counters.
I hope it helps...

How to hide records, rather than delete them (soft delete from scratch)

Let's keep this simple. Let's say I have a User model and a Post model:
class User < ActiveRecord::Base
# id:integer name:string deleted:boolean
has_many :posts
end
class Post < ActiveRecord::Base
# id:integer user_id:integer content:string deleted:boolean
belongs_to :user
end
Now, let's say an admin wants to "delete" (hide) a post. So basically he, through the system, sets a post's deleted attribute to 1. How should I now display this post in the view? Should I create a virtual attribute on the post like this:
class Post < ActiveRecord::Base
# id:integer user_id:integer content:string deleted:boolean
belongs_to :user
def administrated_content
if !self.deleted
self.content
else
"This post has been removed"
end
end
end
While that would work, I want to implement the above in a large number of models, and I can't help feeling that copy+pasting the above comparative into all of my models could be DRYer. A lot dryer.
I also think putting a deleted column in every single deletable model in my app feels a bit cumbersome too. I feel I should have a 'state' table. What are your thoughts on this:
class State
#id:integer #deleted:boolean #deleted_by:integer
belongs_to :user
belongs_to :post
end
and then querying self.state.deleted in the comparator? Would this require a polymorphic table? I've only attempted polymorphic once and I couldn't get it to work. (it was on a pretty complex self-referential model, mind). And this still doesn't address the problem of having a very, very similar class method in my models to check if an instance is deleted or not before displaying content.
In the deleted_by attribute, I'm thinking of placing the admin's id who deleted it. But what about when an admin undelete a post? Maybe I should just have an edited_by id.
How do I set up a dependent: :destroy type relationship between the user and his posts? Because now I want to do this: dependent: :set_deleted_to_0 and I'm not sure how to do this.
Also, we don't simply want to set the post's deleted attributes to 1, because we actually want to change the message our administrated_content gives out. We now want it to say, This post has been removed because of its user has been deleted. I'm sure I could jump in and do something hacky, but I want to do it properly from the start.
I also try to avoid gems when I can because I feel I'm missing out on learning.
I usually use a field named deleted_at for this case:
class Post < ActiveRecord::Base
scope :not_deleted, lambda { where(deleted_at: nil) }
scope :deleted, lambda { where("#{self.table_name}.deleted_at IS NOT NULL") }
def destroy
self.update(deleted_at: DateTime.current)
end
def delete
destroy
end
def deleted?
self.deleted_at.present?
end
# ...
Want to share this functionnality between multiple models?
=> Make an extension of it!
# lib/extensions/act_as_fake_deletable.rb
module ActAsFakeDeletable
# override the model actions
def destroy
self.update(deleted_at: DateTime.current)
end
def delete
self.destroy
end
def undestroy # to "restore" the file
self.update(deleted_at: nil)
end
def undelete
self.undestroy
end
# define new scopes
def self.included(base)
base.class_eval do
scope :destroyed, where("#{self.table_name}.deleted_at IS NOT NULL")
scope :not_destroyed, where(deleted_at: nil)
scope :deleted, lambda { destroyed }
scope :not_deleted, lambda { not_destroyed }
end
end
end
class ActiveRecord::Base
def self.act_as_fake_deletable(options = {})
alias_method :destroy!, :destroy
alias_method :delete!, :delete
include ActAsFakeDeletable
options = { field_to_hide: :content, message_to_show_instead: "This content has been deleted" }.merge!(options)
define_method options[:field_to_hide].to_sym do
return options[:message_to_show_instead] if self.deleted_at.present?
self.read_attribute options[:field_to_hide].to_sym
end
end
end
Usage:
class Post < ActiveRecord::Base
act_as_fake_deletable
Overwriting the defaults:
class Book < ActiveRecord::Base
act_as_fake_deletable field_to_hide: :title, message_to_show_instead: "This book has been deleted man, sorry!"
Boom! Done.
Warning: This module overwrite the ActiveRecord's destroy and delete methods, which means you won't be able to destroy your record using those methods anymore. Instead of overwriting you could create a new method, named soft_destroy for example. So in your app (or console), you would use soft_destroy when relevant and use the destroy/delete methods when you really want to "hard destroy" the record.

Resources