AASM рубиновый камень: суперпользователя без ограничений

Question

Учитывая следующую модель с использованием AASM камень:

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 

У меня есть 2 типа пользователей на моем веб-приложений (обычных пользователей, а также супер-пользователей). Мне нужен тип суперпользователей, который может вызвать событие, которое они хотят. Как вызов #run на работу с состоянием = очистка.

Итак, я понимаю, что мне нужно, чтобы разрешить перехода от во время выполнения. Если пользователь является суперпользователем, от будет состоять из всех состояний, но если пользователь не является суперпользователем, каждый из них будет иметь разные состояния.

Есть ли какой-либо чистый способ сделать это? У тебя есть идеи?

Answer 1

Принятие решений в модели слоя на основе current_user всегда считались кодом запаха, так что пара чистых способов для достижения своей цели может быть:

1. Чтобы реализовать некоторые наследования, как:

   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  
   

   Затем вы должны получить экземпляр или AdminJob, основанный на роли пользователя и вызывающий изменение состояния.

2. Для реализации некоторых состава (см composition over inheritance), что означало бы вы двигаете роль конкретных aasm кода модулей и расширить job объект с определенным по одному за время выполнения.

Обратите внимание, что оба этих предложения оставить свою базу Job класса без aasm валидаций вообще. Это, похоже, противоречит общему пути Rails, но следует за DCI paradigm, в котором говорится, что мы должны отделить то, что система (модель домена) от того, что делает система (функциональность). Однако экземпляры базового класса все равно могут получать текущее состояние.