https://avo.cool logo
Join Discord
Powered by
Police fields
# avo-2
c
Anybody have a good strategy for handling resources for different user roles? For example, an admin user can edit all the attributes of a Book but an editor is limited to a subset of attributes.
l
Hmm 🤔 if it's not mandatory to be visible you can always use den visible option to hide the field according to the role on edit view
If want to be visible, readonly or disabled options should do the trick
c
Suppose I have 3x roles, 20x models, and any model may have 30x attributes. Is that still the most elegant approach?
l
Hmm, if you do with tje with_options block it can become elegant but still tricky if want some restrict order on the fields
c
Is it possible to create a version of a resource (eg. limited_editor_book_resource.rb) with its own Policy?
l
Hmm got it
c
with_options seems like a good fit for a lot of cases. But I'm wondering if there might be a cleaner approach where I don't have to worry about getting so granular on every attribute line by line in the resource.
l
Totally got it, let me get on the PC and try something, I'll be in touch later today
c
Thanks, Paul!
l
Hei, i think this will do the trick. You can override 
index
edit
show
etc.. methods on the let's say avo books controller and call super if user is admin or redirect it to a more restrictive resource if another role, you can even do a switch and redirect each role to a diferent resource. You can also use I18n to make all resources be called as "Book" and it will be clean and elegant.
Make sense?
Index and edit example:
Copy code
ruby
class Avo::BooksController < Avo::ResourcesController
  def index
    if current_user.is_admin?
      super
    else
      redirect_to resources_limited_editor_books_path
    end
  end

  def edit
    if current_user.is_admin?
      super
    else
      redirect_to resources_limited_editor_books_path(id: params[:id])
    end
  end
end
you can apply this logic to 
update
show
new
create
destroy
if necessary (with the adequate path helpers)
Let me know if found something wrong with the approach or having trouble implementing it, maybe it seems kinda hacky but i think it fits on what you want to achieve. @lemon-wall-20836 can you think on a simpler way to implement this?
l
yes, this might be the best solution for you
have custom resources for each user type
you can add them on the sidebar and authorize them accordingly (show the proper one to the proper role)
and each of those resources will be able to update only their fields
let me know if you'd like to prototype something together
there might be some issues along the associations. is a user has_many 
books
the main 
BookResource
will be used. you can use the 
use_resource
option to specify the resource based on the role
c
Thanks. I will have a go at this shortly. I'll let you know if I can make it fly (or crash and burn).
@loud-jewelry-99127 @lemon-wall-20836 , update: this worked well for me. The limited resource model combined with the redirects in the main model was the secret sauce. I haven't employed this much - policy integration and visible options have satisfied most needs. But for large models, this is an elegant way to handle it. Thanks for pointing me in the right direction!
l
nice! thanks for the update
PreviousNext
Powered by