AASM Ruby Gem: Superuser ohne Einschränkungen

Question

das nächste Modell mit dem AASM gem Gegeben:

class Job 
    include AASM 

    aasm do 
    state :sleeping, :initial => true 
    state :running, :cleaning 

    event :run do 
     transitions :from => :sleeping, :to => :running 
    end 

    event :clean do 
     transitions :from => :running, :to => :cleaning 
    end 

    event :sleep do 
     transitions :from => [:running, :cleaning], :to => :sleeping 
    end 
    end 
end 

Ich habe 2 Arten von Benutzern auf meiner Web-Anwendung (normaler Benutzer und Superuser). Ich brauche einen Super-User-Typ, der in der Lage ist, das gewünschte Ereignis anzurufen. Wie #run bei einem Job mit state = cleaning aufrufen.

So, wie ich verstehe, was ich brauche, ist die des Übergangs zur Laufzeit von zu lösen. Wenn der Benutzer ein Superuser ist, würde die von alle Zustände sein, aber wenn der Benutzer kein Superuser ist, würde jede von verschiedenen Zuständen haben.

Gibt es einen sauberen Weg, das zu tun? Hast du eine Idee?

Answer 1

Treffen von Entscheidungen in einer Modellschicht auf Basis von current_user ist schon immer ein Codegeruch in Betracht gezogen worden, so ein paar sauberen Möglichkeiten, um Ihr Ziel könnte erreicht werden:

1. eine Erbschaft zu implementieren, wie:

   CommonUserJob < Job 
       # move your current AASM validations here 
   end 
   
   AdminJob < Job 
       aasm do 
       event :run do 
        all_states = Job.aasm.states.map{|i| i.name} 
        transitions :from => all_states, :to => :running 
       end 
       # other events here in same manner 
       end 
   end  
   

   Dann sollten Sie eine CommonUserJob oder AdminJob Instanz basierend auf Ihrer Benutzerrolle erhalten und eine Statusänderung aufrufen.

2. Um eine gewisse Zusammensetzung (siehe composition over inheritance) zu implementieren, mit dem Sie Ihre rollenspezifische aasm Code-Module bewegen würde bedeuten, und job Objekt mit einem bestimmten bei einer Laufzeit zu verlängern.

Beachten Sie, dass beide dieser Vorschläge an alle Ihre Basis Job Klasse ohne aasm Validierungen lassen. Dies scheint einem üblichen Rails-Weg zu widersprechen, folgt aber einem DCI paradigm, der besagt, dass wir das System vom System trennen sollten (Domänenmodell) (Funktionalität). Basisklasseninstanzen sollten dennoch ihren aktuellen Status erhalten können.