can: 비헤이비어 관리

묘사

만약에 내가 can:manage에 속성을 전달하면 컨트롤러가 새로운 작업에 접근할 때 기대치를 던질 수 있다. 아마도 자원이 조건에 부합되지 않기 때문일 것이다.정상적이거나 와 authorize 자원을 불러와야 합니다. 미리 설정된 속성을 사용하여 자원을 구축해야 합니다. (rails 3의 역할 영역과 유사합니다.)
다음은 코드입니다.
능력rb
can:manage,Activity,:user_id=>user.신분증
활동 제어기.rb
리소스 로드 및 권한 부여
...
def 새
끝맺다
발전하다.저널
이 페이지에 액세스할 수 없습니다.

토론 #1

load_and_authorize_resource는 new 작업의 선행 필터에서 이 작업을 수행합니다.
@ 활성 = 활성새것
권한 부여!:새, @activity
하나의 실례가 들어왔기 때문에 이벤트user_id는 0이 되므로 user.id와 일치하지 않습니다.더 나은 솔루션이 있을 수 있지만 동시에 CanCan 1.3의 새로운 기능:through을 사용할 수 있습니다.이것은 현재 실례 변수에 의존하기 때문에 before 필터에서 현재 사용자를 이 변수로 설정해야 합니다.
필터 전:현재 사용자 로드
리소스 로드 및 승인:=>:현재 사용자를 통해
프라이빗
def load 현재 사용자
@ 현재 사용자 = 현재 사용자
끝맺다
이런 방식을 통해 모든 활동은 @current_user.activites협회를 통해 구축/획득될 것이다.만약 실례 변수가 존재하지 않는다면, 나는 :through 옵션을 사용하여 방법명을 검사할 수 있으며, 이렇게 하면 단독before 필터를 사용할 필요가 없다.
다른 방법은 다른 can 호출을 추가해서 user_id 요구 없이 이벤트를 만들 수 있도록 하는 것입니다.
can:manage,Activity,:user_id=>user.신분증
can: 창조, 활동

토론 #2

두 번째 옵션은 제가 지금 하고 있는 것입니다. 저는 단지 CanCan이 필요한 모든 속성을 가지고 있는 이상 내부에서build을 호출해서 이 속성을 기본값으로 설정할 수 있는지 알고 싶을 뿐입니다.

토론 #셋

before 필터에서 자동으로 실행하기를 원하십니까?문제는 이것이 @activity.user_id = current_user 속성에 마력을 줄 수 있다는 점인데, 나는 CanCan이 명확한 고지 없이 속성을 할당하는 것을 원하지 않는다.때로는 user_id 속성이 자동으로 user_id로 설정되지 않기를 원할 수도 있다.
그러나 나는 이것이 흔히 볼 수 있는 모델이므로 간소화해야 한다는 것에 동의한다.이렇게 간단했으면 좋겠어요.
리소스 로드 및 승인:=>:현재 사용자를 통해
그러나 나는 이 점을 어떻게 가장 잘 할 것인가를 고려해야 한다. 왜냐하면 그것은 실례적인 변수가 아니기 때문이다.이것은 모든 찾기/생성 호출을 현재 사용자를 통해 내가 흔히 볼 수 있는 행위라고 생각하는 모든 작업을 수행하게 할 것이다.이게 네가 여기서 하고 싶은 거야?current_user 그때 제 생각은 이랬어요.
can:manage,Activity,:user_id=>user.id::activity_type=>“bacon”....
그런 다음 CanCan은 이러한 리소스를 지능적으로 구축하려고 시도할 수 있습니다...
@ 활성 = 활성구축(: 사용자 id=>??,: 활동 유형 =>??)...기다린다
기입하면 안 돼요?사용 능력 정의의 값은?물론 아직 캔캔의 원천을 깊이 연구하지 않은 사람에게서 온 것이기 때문에 나는 가능성의 기초에서 완전히 벗어났을 것이다.

토론 #4

전단에서 그의 작업 원리는 오실로그래프와 유사하다고 생각합니다.
범위: bacon 활동, 여기서(이벤트 유형=?),베이컨)
활동베이컨 활동.생성

토론 #5

현재

토론 #6

정의는 권한을 검사하는 데 사용되지 권한을 통해 생성하는 것이 아닙니다.그러나 네가 여기서 제기한 문제는 기술적으로 가능할 것이다.
기본값이 아니면 옵션일 수 있습니다.나는 여러 가지 상황을 좀 더 고려하고 고려해야 한다.그리고 더 많은 정보를 얻고 싶은데, 다른 사람들이 이 기능이 유용하다고 생각할까요?여기에 글을 올려주세요.can 잠시 생각한 후에 나는 이것이 더욱 의미가 있다고 생각한다.현재

토론 #7

작업에 대해 일련의 조건이 있다면 new 거의 쓸모가 없습니다. 왜냐하면 새로운 공백 항목에서는 이러한 조건을 영원히 만족시키지 못하기 때문입니다.
만약 어떤 프로젝트에 대한 요구가 있다면 프로젝트를 구축할 때 반드시 이러한 요구를 만족시키려고 시도해야 한다는 것도 일리가 있다.나는 한 지점에서 이 생각을 더 많이 토론할 것이며, 버전 1.4에서 구현되기를 희망한다.
만약 같은 항목에 여러 개load_and_authorize_resource의 정의가 있거나 can 조건이 존재한다면 실현은 상당히 복잡해질 것이다.하지만 간단한 경우에만 적용된다고 해도 괜찮다고 생각한다.cannot하하, 이 생각이 당신을 끌어당기는 것을 보니 기쁩니다.테스트해 보고 싶으니까 도움이 필요하시면 말씀해 주세요.
기반이 좋고 CanCan이 좋다. 기초를 고수하기 때문에 개발자가 독특한 제한을 가지고 있다면 그들은 새로운 조작에서 자체적으로 자원을 구축하여 이러한 제한을 처리할 수 있다.정확했어

토론 #8

에 단순 build=>true 로고가 있을 수도 있습니다.req'd 속성을 사용하여 구축하지 않습니다.load_and_authorize_resource 네, 낡은 행동으로 되돌아가는 옵션이 호환성에 필요하다고 생각하지만 시도해 보려고 합니다.

토론 #9

신규 및 창설 작업은 현재 능력 조건에 따라 산열된 속성을 사용하여 자원을 구축합니다. - a744377ac965f121fff8e3353e04a549646b7167

토론 #10

에서 닫습니다. 감사합니다!