# \[ActiveAdmin\] Scopes personalizzate ed artificio rails

**URL:** <https://www.ruby-forum.com/t/activeadmin-scopes-personalizzate-ed-artificio-rails/218728>\
**Category:** IT\
**Created:** [April 10, 2012, 12:07pm UTC](https://www.ruby-forum.com/t/activeadmin-scopes-personalizzate-ed-artificio-rails/218728 "2012-04-10T12:07:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dubstep](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@dubstep](https://www.ruby-forum.com/u/dubstep)\
**Post date:** [April 10, 2012, 12:07pm UTC](https://www.ruby-forum.com/t/activeadmin-scopes-personalizzate-ed-artificio-rails/218728/1 "2012-04-10T12:07:08Z")

</div>

Non saprei dire se si tratta di un bug o di una funzionalità non  
supportata: avevo trovato il modo per personalizzare le viste (anche se  
non presente nella documentazione) per personalizzare gli scope ma  
successivamente mi sono accorto che non funzionano più i filtri e  
nemmeno il sort.

L’esempio è molto semplice, ogni user ha un gruppo e l’elenco degli  
articoli ha diverse liste (scopes) per visualizzare quelli di competenza  
al gruppo, quelli non assegnati (ma potenzialmente potrebbe visualizzare  
anche quelli di uno specifico gruppo ecc.)

ActiveAdmin.register Article do  
scope :assigned, :default =\> true do  
Article.assigned.where(:group\_id =\> current\_user.group\_id)  
end  
scope :unassigned  
end

class Article \< ActiveRecord::Base  
belongs\_to :group  
attr\_accessible :group\_id, :user\_id, :title

scope :assigned, where(Article.arel\_table[:group\_id].not\_eq(nil))  
scope :unassigned, where(:group\_id =\> nil)  
end

il problema del codice sopra è il passaggio del blocco al metodo scope  
che da quanto ho capito non utilizza tutta la catena che appende le  
opzioni all’oggetto relation.

ho aperto un ticket ma per il momento non posso farci affidamento ed io  
purtroppo non sono in grado di porre rimedio:

> <https://github.com/activeadmin/activeadmin/issues/1209>
>
> For example, given this resource:
> 
> class Product \< ActiveRecord::Base
> belongs\_…to :category
> attr\_accessible :category\_id, :available, :available\_from, :description, :in\_stock, :name, :price
> 
> scope :only\_available, where(:available =\> true)
> end
> 
> In this case it works
> 
> ActiveAdmin.register Product do
> scope :only\_available
> end
> 
> In this case it does not work
> 
> ActiveAdmin.register Product do
> scope :only\_available do
> Product.only\_available.where(:user\_id =\> current\_user.id)
> end
> end
> 
> What is the cleanest way to append the proc to the chain ?

Mi dispiacerebbe rinunciare ad activeadmin non solo perchè ci ho già  
perso del tempo ma perchè mi piace molto, dunque vorrei trovare un altro  
sistema per risolvere, devo in sostanza tornare al sistema classico:

ActiveAdmin.register Article do  
scope :assigned, :default =\> true  
scope :unassigned  
end

prendendo spunto da qualche questione simile trovato sul web ho pensato  
ad una soluzione alternativa ma vorrei condividerla con voi prima di  
avere sorprese in produzione.

Questo è il modello aggiornato da cui si dovrebbe già capire l’idea:

class Article \< ActiveRecord::Base  
belongs\_to :group  
attr\_accessible :group\_id, :user\_id, :title  
cattr\_accessor :current\_user

scope :assigned, lambda{ where(:group\_id =\>  
current\_user.try(:group\_id))}  
scope :unassigned, where(:group\_id =\> nil)  
end

e nell’application controller associo il current\_user ad ogni richiesta:

class ApplicationController \< ActionController::Base  
protect\_from\_forgery

before\_filter :set\_current\_user  
def set\_current\_user  
Article.current\_user = current\_user  
end  
end

Tralasciando il fatto che se Article.current\_user non è valorizzato  
estrae la stessa cosa di :unassigned (è un problema risolvibile),  
cattr\_accessor crea una variabile di classe condivisa con tutti ed anche  
se il numero di utenti è basso, circa una decina contemporaneamente, è  
una soluzione che mi lascia perplesso.

Con rails \>=3.2 si ha un comportamento in sviluppo simile  
alla produzione, debuggando e simulando diversi utenti di gruppi diversi  
sembra funzionare.

Commenti o qualche altra idea?