One model, two dashboards

[thebravoman]

• What would you like to be able to do? Can you provide some examples?
  The job to be done for me is to use Administrate not only for administrators. I would like to use Administrate both for the administrators and for the end users.
  I am trying to create a model Campaign with properties that could be seen and edited by admins and that could be seen and edited by normal users.

• How could we go about implementing that?
  I solution I see is: One model, Two Namespaced Dashboards
  Here are the possible steps

1. One dashboard is accessible on /admin through app/controllers/admin/campaigns_controller.rb with a dashboard app/dashboard/campaign_dashboard.rb
2. The other dashboard is accessible on /brands through app/controllers/brands/campaigns_controller.rb with a dashboard app/dashboards/brands/campaign_dashboard.rb

The problem that I am facing is that once the /brands dashboard is called Brands::CampaignDashboard because of the namespace 'brands', the administrate is looking for "brands/campaign" model and "new_brands_brand_campaign_* paths and urls.

This is caused by

module Administrate
  module Page
    class Base
      ...
      def resource_name
        @resource_name ||=
          dashboard.class.to_s.scan(/(.+)Dashboard/).first.first.underscore
      end

where the resource_name for Brands::CampaignDashboard is always 'brands/campaign' and not 'campaign'

What I think should happen is not to use the dashboard.class as a way to get the resource but to use the model specified by the dashboard.

Here is a script to create the project and reproduce the issue

rails new campaigns
cd campaigns
echo 'gem "administrate", "1.0.0.beta1"' >> Gemfile
bundle install
rails g model campaign title:string admin_property:integer
rake db:migrate
rails generate administrate:install
rails generate administrate:install --namespace=brands

mkdir app/dashboards/brands
echo 'require "administrate/base_dashboard"

class Brands::CampaignDashboard < Administrate::BaseDashboard

  # We override the model method that is already available in BaseDashboard
  # to be explicit that we want to use the Campaign model and we should not be 
  # looking for Brands::Campaign model as there is no such model. It is same model
  # two dashboards problem.
  class << self

    def model 
      Campaign
    end

  end

  ATTRIBUTE_TYPES = CampaignDashboard::ATTRIBUTE_TYPES

  COLLECTION_ATTRIBUTES = %i[
    id
    title
    created_at
  ].freeze

  SHOW_PAGE_ATTRIBUTES = %i[
    id
    title
    created_at
    updated_at
  ].freeze

  FORM_ATTRIBUTES = %i[
    title
  ].freeze

  COLLECTION_FILTERS = {}.freeze
end
' > app/dashboards/brands/campaign_dashboard.rb

echo '
module Brands
  class CampaignsController < Brands::ApplicationController

    def dashboard_class
      Brands::CampaignDashboard
    end

  end
end
' > app/controllers/brands/campaigns_controller.rb

rails s -p 3002

open http://localhost:3002/brands/campaigns/

There will be an error

Stop server

echo '
# administrate patch that will not use the dashboard name 
# but the dashboard.class.model method that is already defined 
# for the Brands::CampaignDashboard and for all other BaseDashboards
module Administrate
  module Page
    class Base

      def resource_name
        @resource_name ||=
          dashboard.class.model.to_s.underscore
      end

    end
  end
end
' > config/initializers/administrate_patch.rb


rails s -p 3002

open http://localhost:3002/brands/campaigns/

/brands/campaigns allows for creating and updating of campaigns but without the admin_property
/admin/campaigns allows for creating and updating of campaigns but with the admin_property

• Can you think of other approaches to the problem?
  I went down the path of overriding polymorphic_path, creating brands/campaign.rb models, but could not get it working. Too involved.

[thebravoman]

I did a commit in my fork.
thebravoman@992993c

Could prepare a PR if I am not missing something

[emersonthis]

This is an interesting idea. I have a similar use case. Is this solution working well for you?

[nickcharlton]

This is an interesting idea!

If it's working well for you, could you look at creating a PR for it? We can then pick up the discussion from there.

[goosys]

I’ve solved this using a different approach.
I created a new resolver that resolves the controller namespace as a permission role. This allows my application to offer separate admin panels for multiple roles such as admin, manager, provider, and analyzer , and it’s working fairly well so far.

Is there anything else I can help with regarding this issue?

[nickcharlton]

Oh, interesting. I'd be interested to hear if that works well for everyone else here.

[thebravoman]

Thanks @nickcharlton

This is an interesting idea!

If it's working well for you, could you look at creating a PR for it? We can then pick up the discussion from there.

I will take a look at creating a pr for this.

This is an interesting idea. I have a similar use case. Is this solution working well for you?

Yes @emersonthis

I've been using it on production for a few months now, and I am happy with it.