ruby on rails - sitepoint - Ámbitos de administración activa para cada instancia de un modelo relacionado

react rails tutorial

Question

Tengo un problema con un alcance dinámico de administración activa. Estoy intentando crear un alcance para cada "administrador" de un "proyecto" en mi aplicación. Sin embargo, los ámbitos no parecen actualizarse cuando se crea un nuevo administrador (o se lo asigna a un proyecto) pero SI 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.

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

Aquí está el código en cuestión (que funciona pero solo 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 el modelo de Active Admin Project:

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

Answer 1

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

Es un truco, pero es una solución viable cuando corresponde:

El truco es actualizar los ámbitos en un before_filter en la acción de índice de los controladores .

Esto podría ser malo si tiene muchos ámbitos creados en un recurso (aunque puede establecer algunos límites fácilmente)

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

Answer 2

Los verdaderos ámbitos dinámicos dentro de los bloques de registro de 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. Entonces puedes 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 puedes ver https://github.com/gregbell/active_admin/issues/1261#issuecomment-5296549

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

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

Answer 3

Me pareció que esto funcionaba 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 es de esperar que ayude a alguien a salir.

Answer 4

Rails solo carga clases una vez en el 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 utilizar 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.