Administrate: Getting session's information from administrate dashboard or field?

Created on 30 Mar 2020  路  5Comments  路  Source: thoughtbot/administrate

  • What would you like to be able to do? Can you provide some examples?
institutions: Field::Select.with_options(collections: -> {
  Pundit.authorize(?user?, Institution.where(pic_id: ?user?.id), :show, policy_class: InstitutionPolicy)
} )
  • How could we go about implementing that?
    I don't how to implement it.
    Is this already available?
  • Can you think of other approaches to the problem?
    I cannot think of alternative

The proc feature on Field::Select is introduced in #1535

dashboards feature fields

Most helpful comment

I think you are right, and there isn't a good way to implement this currently. It looks to me like a design issue with Administrate. I do think it should be fixed, but it won't be trivial.

Fortunately, I think there's a workaround. It's ugly, but it should work: use Thread.current to store the current user, and read it from the proc. Like this:

# app/controllers/admin/application_controller.rb
module Admin
  class ApplicationController < Administrate::ApplicationController
    before_action :authenticate_user! # This line will depend on your authentication library
    before_action :store_current_user

    private

    def store_current_user
      Thread.current[:current_user] = current_user
    end
  end
end
# In your dashboard
institutions: Field::Select.with_options(collections: -> {
  Pundit.authorize(Thread.current[:current_user], Institution.where(pic_id: Thread.current[:current_user].id), :show, policy_class: InstitutionPolicy)
} )

For more information on Thread.current and its risks, be sure to read https://stackoverflow.com/questions/7896298/safety-of-thread-current-usage-in-rails.

I'm going to keep this open, in order to come back to it in the future.

All 5 comments

I think you are right, and there isn't a good way to implement this currently. It looks to me like a design issue with Administrate. I do think it should be fixed, but it won't be trivial.

Fortunately, I think there's a workaround. It's ugly, but it should work: use Thread.current to store the current user, and read it from the proc. Like this:

# app/controllers/admin/application_controller.rb
module Admin
  class ApplicationController < Administrate::ApplicationController
    before_action :authenticate_user! # This line will depend on your authentication library
    before_action :store_current_user

    private

    def store_current_user
      Thread.current[:current_user] = current_user
    end
  end
end
# In your dashboard
institutions: Field::Select.with_options(collections: -> {
  Pundit.authorize(Thread.current[:current_user], Institution.where(pic_id: Thread.current[:current_user].id), :show, policy_class: InstitutionPolicy)
} )

For more information on Thread.current and its risks, be sure to read https://stackoverflow.com/questions/7896298/safety-of-thread-current-usage-in-rails.

I'm going to keep this open, in order to come back to it in the future.

Thank you for taking the time to make the solution. It somehow reminds me of Rails 5's Current.
https://api.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html

Which is also considered harmful by Radar,
https://ryanbigg.com/2017/06/current-considered-harmful .

I think we can expose session and other information (such as request params) to the
Administrate Instance variable, and from there we can pass it to Field.
WDYT @pablobm ? If you are confident with this, I can make a PR for it.

It will, of course, make administrate instances harder to instantiate. But, we already expect administrate to be instantiated from a controller instance.

I forgot about Current. Yeah, I agree it's not a great solution.

Ideally the PR you propose would be good. However, I'm currently working on changes across all fields, so perhaps it'll be better to wait for that. Specifically, I'm working on this: https://github.com/thoughtbot/administrate/issues/1597 It may cause a bunch of conflicts...

What do you think?

The workaround works fine for me. I will wait until you finished with #1597.
It seems like a tedious task considering the amount of tests broken. Good luck, can't wait to remove the association's repetitive config on our dashboards.

Was this page helpful?
0 / 5 - 0 ratings