능력 범위는 Mongoid입니다.결함

묘사

Mongoid와 규칙의 역할 영역을 사용할 때 문제가 발생했습니다.
이렇게 오랫동안 미안하지만, 나는 상하문이 필수적이라고 생각한다.
저는 User형과 Profile형이 있습니다.중간에 ProfileUser모델이 있는데 그 중에서 permission의 추가 속성을 포함한다. 이 속성은 manager 또는 collaborator일 수 있다.
이것은 Mongoid이기 때문에 우리는 :through과 다른 관계를 맺을 수 없다. 나는 User에서 이 작은 방법을 실현했다. 이것은 Profile에서 ProfileUser의 연결을 모의했다.이 모듈은 관심 있는 ProfileUser의 조건을 최적화할 수 있는 모듈을 제공합니다.

class User
  ...

  def profiles(&block)
    pu = profile_users.scoped
    pu = pu.instance_eval(&block) if block_given?
    Profile.where(:id.in => pu.only(:profile_id).map(&:profile_id))
  end
end

그래서 나는 지금 말할 수 있다. 예를 들어 @user.profiles { where( ... the join document meets some condition ... ) }.
권한 수여에 관해서는 User이 Profile의 구성원이라면 모든 조작을 허용하는 것이 목적이다.만약 그들이 manager이라면, 그들은 읽기 권한만 있을 것이다.그렇지 않으면 그들은 들어갈 수 없다.내 collaborator은 다음과 같다.

class Ability
  include CanCan::Ability

  def initialize(user)
    user ||= User.new
    ...
    can [:read], Profile, user.profiles do |profile|
      user.profiles { where(profile_id: profile.id, :permission.in => ['manager', 'collaborator']) }.exists?
    end
    can [:manage], Profile, user.profiles { where(permission: 'manager') } do |profile|
      user.profiles { where(profile_id: profile.id, permission: 'manager') }.exists?
    end
    ...
  end
end

첫 번째 규칙 A와 두 번째 규칙 B를 호출합니다.
보시다시피, 저는 ability.rb 방법을 범위 매개 변수로 사용하여 User#profiles의 행위를 변경하려고 합니다.규칙 A에 대해 내가 말한 범위는 바로 사용자의 accessible_by이다.규칙 B에 대해 나는 사용자가 반드시 Profile의 manager이어야 한다는 추가 제약을 추가했다.Profile을 사용하여 수집 작업을 수행하기 전까지는 이 모든 것이 좋았습니다.

class ProfilesController < ApplicationController
  before_filter :authenticate_user!
  load_and_authorize_resource

  respond_to :html

  def index
    respond_with @profiles
  end

  ...
end

작용역은 작용하지 않고 load_resource이 모든 @profile을 포함한다.
나는 칸칸 법전을 조사했는데 문제는 CanCan::ModelAdapters::MongoidAdapter#database_records에서 비롯되었다.나의 Profile은 마침 current_user에 대한 어떠한 manager의 권한도 없기 때문에 규칙 B ProfileUser에 대해 line 42까지 실행하고 모든 문서를 되돌려준다.
마지막으로, 나의 문제는 규칙 A (이 사용자의 rule.conditions.empty? => true은 규칙 A) 를 계속 사용하고, 그가 A를 통해 방문한 문서만 되돌려주는 것을 허용해야 하는가 하는 것이다.
나는 규칙 B를 수정하여 이 문제를 더욱 구체적으로 해결할 수 있다고 생각한다(rule.conditions.empty? => false으로 :manage을 교체하고 규칙 A로 [:update, :destroy]을 처리하게 한다). 그러나DSL의 능력에 대한 이해는 이것이 필요하지 않다는 것이다.
나는 이미 한동안 연구를 했는데, 나는 :read 변수가 삭제되기만 하면 규칙이 계속 처리될 수 있다고 추측했다.그러나 나는 또 다른 문제가 있다고 생각한다.
만약에 내가 규칙에 범위를 제공한다면 process_can_rules은 rule.conditions이 될 것이다. 그러나 코드는 여러 규칙이 있다면 조건이 모두 Mongoid::Criteria이라고 가정하는 것 같다. 코드는 그것들에 대해 Origin 방법(Hash)을 사용하려고 시도하고 오류가 발생할 것이다.
그럼 이게 벌레예요, 아니면...?건의해 주셔서 감사합니다.or 최신 버전의 cancan(현재 1.6.10)을 사용해서 문제가 해결되었는지 확인할 수 있습니까?
이것은 가장 오래된 칸막이 문제 중의 하나로 토론한 적이 없다.캔캔은 현재 200건에 육박하는 rails 4 지원을 위해 노력하고 있다.만약 우리가 오래된 문제를 해결하고 문제를 카운트다운할 수 있다면 그것은 매우 큰 도움이 될 것이다.감사합니다!

토론 #1

그래요. 제가 가장 작은 프로젝트에서 1.6.10을 사용해서 복제를 시도해 봤는데 아직까지는 괜찮은 것 같아서 끝낼 수 있을 것 같아요.