I'm a newbie to the ROR world and I'm trying to use ActiveAdmin to design the Admin Panel for an Artists Portfolio Website.
The idea is that each artist has a login/password and can manage assets.
The models are set with has_many in the AdminUser table, and belongs_to in the linked models.
For example, an AdminUser has_many Videos.
There are many linked assets.
What would be the best approach so that:
The currently logged in AdminUser only has access to his own assets?
The currently logged in AdminUser is set as the admin_user_id field
for each newluyy created asset?
Thank you very much for your help!
I am not sure if this answer is in time.
Q1. The currently logged in AdminUser only has access to his own assets.
A1. use cancan for your authorization framework. By default ActiveAdmin doesn't provide the authorization ability for you. so , the key code may looks like:
# in your app/models/ability.rb
class Ability
include CanCan::Ability
def initialize(user)
can :read, Asset, :admin_user_id => user.id
end
end
for more detailed steps of using Cancan (very easy, you can deal with it in 15 minutes ), please refer to : https://github.com/ryanb/cancan
Q2. The currently logged in AdminUser is set as the admin_user_id field for each newluyy created asset.
A2: AdminUser is just a "User" model. so, you can call it "current_user" in your view and controller as the regular Devise's way. e.g.
#in your controller
def create_xx
# save the admin_user_id to the newly created asset.
Asset.create(:admin_user_id => current_user.id)
end
for more details of Devise, see its official website: https://github.com/plataformatec/devise
Related
I'm making a Rails 6 application where I'm using Devise for authentication, Pundit for authorization and I added Active-Admin because I need a dashboard where admin users manage the content of the app.
Other than admin, I have a couple of more roles president, manager, guest. An admin can be president or manager.
I'm little confuse on what to use to implement the roles, with devise? pundit? I do it by hand?
Is it better to unite the User and the AdminUser model active-admin created? Because this way UserAdmin users can't log in to the application, only to the dashboard and that is not what I want.
I have seen tutorials where people add an admin:boolean column to the users, should I do something like that?
Is it better to unite the User and the AdminUser model active-admin created? Because this way UserAdmin users can't log in to the application, only to the dashboard and that is not what I want.
That depends more on your business logic. It may be a good idea to keep your users and admin_users tables separated; The users table will probably need to have a lot of associations with other tables, that will not be necessarily needed by admin_users, right?
I'm little confuse on what to use to implement the roles, with devise? pundit? I do it by hand?
You may define a role column in your admin_users table, and use that column in pundit policies, for example:
class ResourcePolicy
# ...
# ...
# ...
def update?
user.admin? || user.president?
end
end
in AdminUser, you can do the following:
class AdminUser < ActiveRecord::Base
def admin?
role == 'admin'
end
def president?
role == 'president'
end
end
There are many other ways to implement that, and they all depend on what you need to achieve.
I am currently setting up my role management in my Rails app with the Rolify gem - both with the latest versions.
In my case, a user can only have one role at the same time for one specific resource. This means, that before I do a
user.add_role :lead, #resource
I would like to delete all maybe already existing roles. Unfortunately something like
user.current_role.remove #resource
is not existing. I only could loop through all maybe existing roles, check if it is existing and delete it. This sounds ugly to me. Stuff like
user.roles = []
does not help either me because i want to delete all roles for a specific resource.
Is there any standard functionality in rolify to support something like this?
Thanks for your help in advance!
Callback methods to the rescue!
class User < ActiveRecord::Base
rolify before_add: :before_add_method
def before_add_method(role)
# do something before it gets added
end
end
I ended up wanting a more substantial solution which removed all kinds of roles from the resource. I made a gist out of it:
user.rb
class User < ApplicationRecord
rolify :strict => true, :before_add => :before_add_role
#Helper method to remove any existing role this user has for a resource
def remove_all_roles resource
# README: This syntax relies on changes on the following PR
# https://github.com/RolifyCommunity/rolify/pull/427
# Or include the source of this directly:
# gem 'rolify', :git => "git://github.com/Genkilabs/rolify.git"
remove_role nil, resource
end
protected
#ensure that we only have a single role per resource
def before_add_role(role)
if role.resource
Rails.logger.debug "User::before_add_role: Adding the role of #{role.name} for #{role.resource_type} #{role.resource_id} to user #{id}"
#remove any pre-existing role this user has to the resource
remove_all_roles role.resource
end
end
end
I am creating a website in Ruby and I would like to have the option to sign up as an admin or a user. I have created the sign up system using devise and I would like to be able to give different permissions to different users, i.e Admins and Users. Thanks guys.
There's a comprehensive guide here.
Here's a post about using Devise and CanCan to accomplish what you are looking for.
You can add boolean fields admin and users into your User model. So while creating you can assign admin or user role.
This question is answered here:
how to define user roles
you can use devise + cancan and define roles like user and admin to separate common user and application admin.
class User < AB
has_many :roles
def is_admin?
roles.include?(:admin)
end
end
class Role < AB
end
and then check it in cancan's definition file like this
can :update, Model do |model|
user.admin?
end
this video give you detail about it http://railscasts.com/episodes/192-authorization-with-cancan
I`m looking to create two models: trainer & client.
When signing up those two types of models share the basic auth info, such as email & password.
Thus I would like to use Sorcery to do the authentication for me, the gem creates a User model by default.
Searching through StackOverflow I understand I could use Single Table Inheritance, which most people find problematic.
Is there a better/simpler solution for those two types of users to share the basic auth info but be separate models which would contain their role specific data?
I`m sorry if I mixed things up.
What kind of "role specific data" do your two users have?
I was in a very similar situation as you are in an app that I'm still developing. I chose to use a role based approach using CanCan.
class User < ActiveRecord::Base
has_one :client_profile # or whatever a client has here
has_one :trainer_profile # or whatever a trainer has here
end
Then, you would define your abilities
class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new # anonymous user
if user.is? :trainer
can :create, TrainerProfile
# some other trainer specific roles here, like editing his/her profile
elseif user.is? :client
can :create, ClientProfile
# some other client specific roles here, like editing his/her profile
end
end
end
Of course, the above code assumes an is? method on the User class to check the user role.
More info on CanCan can be found on the CanCan wiki, and also the Railscast on CanCan.
I want to make a record management system. The system will have 4 different user roles: Admin, Viewer, Editor and Reviewer.
While the first two are easy to implement using gems such as cancan and declarative authorization, the other two are not so simple.
Basically each new record is created by an Admin (only an Admin can create new records), and should have its own separate Editor and Reviewer roles. That is, a user can be assigned many different roles on different records but not others, so a user might be assigned Editor roles for Record A and C but not B etc.
Editor: can make changes to the record, and will have access to specific methods in the controller such as edit etc.
Reviewer: will be able to review (view the changes) made to the record and either approve it or submit comments and reject.
Viewer: Can only view the most recent approved version of each record.
Are there any ways of handling such record-specific user roles?
This can be accomplished without too much effort with the cancan gem and a block condition. A block condition checks for authorization against an instance. Assuming your Record class had an editors method that returns an array of authorized editors the cancan ability for updating a Record might look something like this:
class Ability
include CanCan::Ability
def initialize(user)
user ||= User.new # guest user (not logged in)
...
can :update, Record do |record|
record.editors.include?(user)
end
...
end
end
See "Block Conditions" on the CanCan wiki:
https://github.com/ryanb/cancan/wiki/Defining-Abilities
Update
Storing which users have which access to which records could be done many ways depending on your specific needs. One way might be to create a model like this to store role assignments:
class UserRecordRoles < ActiveRecord::Base
# Has three fields: role, user_id, record_id
attr_accessible :role, :user_id, :record_id
belongs_to :user_id
belongs_to :record_id
end
Now create a has_many association in the User and Record models so that all role assignments can be easily queried. An editors method might look like this:
class Record < ActiveRecord::Base
...
has_many :user_record_roles
def editors
# This is rather messy and requires lot's of DB calls...
user_record_roles.where(:role => 'editor').collect {|a| a.user}
# This would be a single DB call but I'm not sure this would work. Maybe someone else can chime in? Would look cleaner with a scope probably.
User.joins(:user_record_roles).where('user_record_roles.role = ?' => 'editor')
end
...
end
Of course there are many many ways to do this and it varies wildly depending on your needs. The idea is that CanCan can talk to your model when determining authorization which means any logic you can dream up can be represented. Hope this helps!