Столкнулся давеча с интересным явлением при использовании плагина ScopedAccess.
Оказывается, что сей шедевр программерской мысли распространяет своё зловредное полезное влияние не только на контроллер, в котором ему предписано работать, но и на модели, используемые в многострадальном контроллере.
В моём случае саботажу подверглись валидации, а конкретно - validate_uniqueness_of. Этот полезнейший метод может проверять на уникальность вводимые в какие-либо поля значения - не дожидаясь, пока сработает соответсвующий уникальный индекс в БД (если таковой имеет место быть).
Суть оказалась в том, что при добавлении новой записи в таблицу должна была сработать эта проверка на уникальность, а плагин, руководствуясь, вероятно, самыми низменными побуждениями, вероломно подставил скоуп, используемый в контроллере, и в модель тоже. Соответственно, проверка на уникальность происходила только в рамках текущего scope, что влекло за собой SQL Error (в случае присутствующего unique index) - в лучшем случае, а при отсутствии оного - добавляло запись с ошибочным повторным значением в таблицу.
После непродолжительных, но ожесточённых боёв со скудной и нелепой документацией было решено попробовать опцию от метода around_filter - :except => :my_method, где my_method - метод, в котором как раз происходило добавление записи, инициирующее валидацию. Собственно, исключительно этот параметр - не упомянутый в описании, заметьте - и спас отца русской демократии.
А ещё выяснилось, что сами разработчики Rails настоятельно не рекомендуют использовать этот плагин, вот.










Вчера как раз баг поэтому в коде происходил, что scoped_access из контроллера на валидацию в модели влиял. Весьма актуальный вопрос в RubyOnRails.
просто надо помнить что scoped_access копает _глубже_ чем та модель на которую мы влияем, и обращаться с ним аккуратно