얻은 기록은 가장 자유롭게 정의된 기능과 일치해야 한다

묘사

1.6.5와 1.6.8 사이에서 일어난 듯한 컴백을 만났다.기본적으로 나는 내 응용 프로그램에서 다음과 같은 기능을 정의했다.

if user.role? :admin
  can :manage, :all
elsif user.role? :other
  #...
end

can :manage, Something, :user_id => user.id

그 목적은 "관리자는 무엇이든 할 수 있고, 다른 캐릭터의 사용자는'모모'를 할 수 있으며, 모든 사용자는 자신의 물건을 관리할 수 있다"는 것이다.1.6.5에서 이것은 매우 효과적이다. accessible_by 방법은 일반 사용자에게'가진'모델을 되돌려주고 관리자에게 모든 모델을 되돌려준다.1.6.8에서는 기본적으로 마지막으로 정의된 기능을 더 좋아하고 모든 사용자(관리자 포함)에게만'가진'모델을 되돌려준다.
나는 이것이 언제 도입된 '합병 가능 조건' 기능과 관련이 있다고 믿는다.결합할 수 없는 조건이 결정되면 유효한 하이퍼조건이 존재하지 않습니다.첨부 파일은 규범화된 인출 요청으로 나의 문제를 해결할 수 있지만, 이 코드에 대한 나의 이해/경험이 제한되어 있기 때문에, 이것은 아마도 가장 좋은 해결 방안이 아닐 것이다.그 밖에 데이터 맵이나mongoid를 사용하지 않았기 때문에 나는 심지어 그곳의 어떤 문제도 해결하려고 시도하지 않았다.
여느 때와 마찬가지로 당신의 위대한 해방에 감사 드립니다!
(방금 내가 기존의 인출 요청/문제를 살펴보는 데 잘하지 못했다는 것을 깨달았기 때문에 나는 여기서 시간을 낭비하지 않았으면 좋겠다...하지만 @travisbot이 나를 좋아해서 기쁘다!:P

토론 #1

이 인출 요청passes(e2783f55를 b4285ae4에 통합한다).

토론 #2

방주(비비판)로
문제는 다음과 같습니다.

if user.role? :admin
  # there is no point in eating CPU cycles beyond this point
  return can(:manage, :all)
elseif user.role? :other
 # ...
end

토론 #셋

@coffeeaddict, 이 특수한 사례에 대해 좋은 해결 방안이 될 수 있습니다!
그러나 나는 이것이 이 문제를 해결할 수 있을지 없을지 확실하지 않다.물론 복귀 후에도 더 복잡한 기술을 계속 사용해야 할 수도 있다.어쨌든 이것은 일종의 후퇴다.아마도 @ryanb는 이 때문에 고민하고 싶지 않을 것이다. 왜냐하면 그는 현재 v2에 들어갔기 때문이다.
이거는요?

if user.role? :somethingeer
  return can :manage, Something
else if user.role? :widgeteer
  can :manage, Widgets
end

can :manage, Something, :user_id => user.id

user가 somethingeer와 widgeteer의 역할을 동시에 가진 상술한 능력을 고려해 보자.그럼 user 관리Widget할 수 있어요?이것은 단지 나의 생각일 뿐이기 때문에 아마도 더 좋은 방법으로 이 능력을 정의할 수 있을 것이다.

토론 #4

wiki 항목의 능력 우선순위를 보면 두 개의 If 블록으로 나누고 순서를 뒤바꿔야 하기 때문에 더 자유로운 것이 맨 뒤에 있다고 생각합니다.(첫 번째 댓글을 말합니다.)나는 방금 이 문제에 부딪혔다.나의 용례는 기본적으로 다음과 같다.

can :read, [User, Post]

if user
  can :manage, User, id: user.id
  can :manage, Post, user_id: user.id
end

목적: 누구나 사용자와 게시물을 읽을 수 있지만 로그인한 사용자만 자신과 자신의 게시물을 관리할 수 있다.
실제 상황: 로그인한 사용자는 자신의 사용자 대상과 게시물만 읽을 수 있습니다.

토론 #5

네, 순서만 변경하면

토론 #6

if 블록 뒤에 있습니다.can :read, [User, Post]@fBunemann 이것이 바로 제가 한 해결 방안입니다.나는 최소한의 서프라이즈를 원칙으로 논평하는 경향이 있다.도와 주셔서 감사합니다.

토론 #7

@fbunemann@jonathanhefner 나는 단지 이 홍보를 돌이켜 보았을 뿐이다. 아마도 사후에 보면 그것은 완전히 침묵한 것 같다.The wiki 코드 순서에 따라 정의된'낮음'능력이 상기 능력보다 우선임을 명확히 지적했다.나는 이미 오랫동안 나의 최초의 문제를 고려하지 않았지만, 단지

토론 #8

줄을 모든 문제 위로 옮기면 문제를 해결할 수 있지 않겠는가?@fBunemann이 제대로 된 것 같습니다.
나는 언젠가 이 문제를 다시 생각해 보고 이 문제를 해결할 수 있을 것이다.당신들의 의견에 감사 드립니다: can :manage, Something, :user_id => user.id @iamvery 동의합니다. 부딪히는 모든 문제를 해결하는 것은 매우 쉽습니다.마지막 규칙이 승리한다는 전략은 따르기 쉽다.그러나 나는 내가 언급한 예에서 어떤 충돌도 이길 필요가 없다고 생각한다.

# anyone can read these things
can :read, [User, Post]

if user
  # a user can read himself--redundant to the first rule, but not a contradiction
  can :manage, User, id: user.id  
  # a user can read his posts--also redundant, but not a contradiction
  can :manage, Post, user_id: user.id
end

만약 규칙 사이에 확실히 충돌이 존재한다면 마지막 규칙이 승리하는 것은 일리가 있다.

can :manage, Wiki
cannot :destroy, Wiki # conflicts the above and below lines
can :destroy, Wiki, user_id: user.id # redundant to 1st line but conflicts 2nd