2012-05-04 6 views
8

Tengo un problema con un ámbito de administración activo dinámico. Estoy intentando crear un alcance para cada "administrador" de un "proyecto" en mi aplicación. Sin embargo, parece que los ámbitos no se actualizan cuando se crea un nuevo administrador (o se lo asigna a un proyecto), sino que se actualizan si reinicio el servidor. Entonces, el código "funciona" per se, pero obviamente no de la manera que me gustaría. Soy un novato de ruby ​​/ rails, así que no estoy seguro si necesito hacer algo para "actualizar" el alcance de alguna manera.Ámbitos de administración activa para cada instancia de un modelo relacionado

Como un FYI, estoy usando Rails 3.2 en Heroku cedro con ActiveAdmin

Aquí está el código en cuestión (que funciona, pero sólo trae nuevos administradores después de reiniciar el servidor):


Manager.find_each do |m| 
    scope m.first_name do |projects| 
    projects.where(:manager_id => m.id) 
    end 
end 

Y todo Active modelo de administración de Proyectos:

ActiveAdmin.register Project do 
menu :priority => 1 
index do 
    column :name 
    column :company_name 
    column :status 
    column :projection do |project| 
    number_to_currency project.projection 
    end 
    column :updated_at 
    default_actions 
end 

scope :all 
scope :working, :default => true do |projects| 
    projects.where(:status => 'working') 
end 

Manager.find_each do |m| 
    scope m.first_name do |projects| 
    projects.where(:manager_id => m.id) 
    end 
end 
end 
+0

La siguiente respuesta es grande. No entiendo por qué no lo marcó como respondí. –

Respuesta

1

rieles sólo carga en clases ce en modo de producción. Esto significa que sus ámbitos solo se invocan una vez y luego se almacenan en caché. Esta es la razón por la que los nuevos ámbitos no aparecen hasta después de un reinicio. Lo mismo sería cierto si editó el nombre del administrador en su caso.

Creo que la solución podría ser usar una lambda o Proc, pero en los pocos minutos que jugué con ella, no tuve éxito. Es posible que no sea posible la forma en que activeadmin también está escrito.

+0

Es correcto que no es posible. La forma en que activeadmin ha implementado su envoltorio de alcance alrededor del método de alcance de registro activo lo prohíbe. Tal vez un método "reload_scope" podría estar de alguna manera expuesto a activerecord después de guardar/comprometer ganchos. ¿Tienes alguna idea de cómo hacer eso? –

2

Los verdaderos ámbitos dinámicos dentro de los bloques de registro AA no funcionarán. Con eso quiero decir que los cambios en la tabla Manager no se reflejarán en los ámbitos dinámicos creados en 'inicialización'. También vea: https://github.com/gregbell/active_admin/wiki/Creating-dynamic-scopes. Lo que podría intentar es usar filtros en lugar de ámbitos. A continuación, puede escribir algo como:

filter :managers, :as => :select, :collection => proc { Manager.order('name ASC').map(&:first_name) } 

y los cambios en las propiedades de los administradores se mostrarán (después de la actualización de la página) sin reiniciar el servidor. También marque https://github.com/gregbell/active_admin/issues/1261#issuecomment-5296549

También tenga en cuenta que los ámbitos del registro activo son! Diferentes! desde ámbitos de administración activos. es posible que desee comprobar

http://apidock.com/rails/ActiveRecord/NamedScope/ClassMethods/scope

+1

¡Gracias! Encapsular la colección en un proceso es correcto para que se ejecute a pedido. Esto también resuelve los problemas 'rake db: schema: load' y' rake db: migrate'. Los filtros de ActiveAdmin intentarán acceder al esquema antes de que se haya creado si no se incluye en un proceso. – scarver2

3

he encontrado que esto funcione para mí:

archivo ActiveAdmin

scope :working, :default => true do |projects| 
    Project.working 
end 

Modelo

scope :working, -> { where(:status => 'working') } 

Un poco tarde en la respuesta, pero con suerte, ayuda a alguien a salir.

+2

¿Realmente funcionó para crear múltiples ámbitos? Veo que se creó un alcance. – James

10

Aquí hay una solución real a este problema ... Aunque usar filtros es más deseable estabilidad y mantenimiento, esto se ve mejor en ActiveAdmin y es más fácil de usar ya que los ámbitos se convierten en pestañas atractivas.

que es un poco de un truco, pero es una solución viable en su caso:

El truco es actualización de los alcances en un before_filter en la acción index controladores.

Esto podría volver a empeorar si tiene muchos ámbitos creados en un recurso (Altho se pueden crear fácilmente algunos límites)

ActiveAdmin.register Project do 
    menu :priority => 1 
    index do 
    column :name 
    column :company_name 
    column :status 
    column :projection do |project| 
     number_to_currency project.projection 
    end 
    column :updated_at 
    default_actions 
    end 

    scope :all 
    scope :working, :default => true do |projects| 
    projects.where(:status => 'working') 
    end 

    controller do 
    before_filter :update_scopes, :only => :index 

    def update_scopes 
     resource = active_admin_config 

     Manager.all.each do |m| 
     next if resource.scopes.any? { |scope| scope.name == m.first_name } 
     resource.scopes << (ActiveAdmin::Scope.new m.first_name do |projects| 
      projects.where(:manager_id => m.id) 
     end) 
     end 

     # try something like this for deletions (untested) 
     resource.scopes.delete_if do |scope| 
     !(Manager.all.any? { |m| scope.name == m.first_name } || ['all', 'working'].include?(scope.name)) # don't delete other scopes you have defined 
     end 

    end 
    end 
end 
+0

Gracias a Daxter en github por hacer algunas recomendaciones: [Problema asociado con GitHub] (https://github.com/gregbell/active_admin/issues/1261#issuecomment-22207740) –

+0

Cómo acerca de cuándo se eliminan? –

+1

No estoy configurado para probarlo, pero acabo de agregar algunos códigos que deberían ayudar a eliminarlos. –

Cuestiones relacionadas