permissable 0.2.0 → 0.2.1
Sign up to get free protection for your applications and to get access to all the features.
- data/README.rdoc +12 -3
- data/VERSION +1 -1
- data/lib/permissable/member.rb +8 -0
- data/lib/permissable.rb +3 -3
- data/permissable.gemspec +1 -1
- metadata +3 -3
data/README.rdoc
CHANGED
@@ -54,14 +54,23 @@ member model that will be called prior to checking permissions from the database
|
|
54
54
|
end
|
55
55
|
end
|
56
56
|
|
57
|
+
== Chaining Permissions
|
58
|
+
|
59
|
+
If you want your permissions to have a heirarchy, use the :chain option. For example, say you have three permission types: read, write, and moderate. In this instance, moderators should also be able to read and write a resource, and members who can write should also be able to read the resource. To do this, add this chain when calling has_permissions_for:
|
60
|
+
|
61
|
+
class User < ActiveRecord::Base
|
62
|
+
has_permissions_for [:resource],
|
63
|
+
:to => [:read, :write, :moderate],
|
64
|
+
:chain => { :moderate => [:read, :write], :write => [:read] }
|
65
|
+
end
|
66
|
+
|
67
|
+
Now calling can?(:read, @resource) will evaluate to true when permissions exist for reading or writing, and can?(:read, @resource) will evaluate to true when permissions exist at least to write.
|
68
|
+
|
57
69
|
== Planned Updates
|
58
70
|
|
59
71
|
In the near future there are plans to add the ability to "eager_load" permissions on a user the first time it is created. When using this configuration
|
60
72
|
option, ALL permissions relating to that user are looked up in a single database query, and then cached to the user instance. By default I think this may be the proper way to handle it anyway.
|
61
73
|
|
62
|
-
We are also planning to implement permission "chains". Basically this will define a series of "levels" to your permission. For instance a user
|
63
|
-
who can "write" a model, would also be able to "read" a model. You would be able to tell Permissable which methods chain from each other and
|
64
|
-
the order they should rely on. Think about how a statemachine transitions from one state to another in a way....
|
65
74
|
|
66
75
|
== Note on Patches/Pull Requests
|
67
76
|
|
data/VERSION
CHANGED
@@ -1 +1 @@
|
|
1
|
-
0.2.
|
1
|
+
0.2.1
|
data/lib/permissable/member.rb
CHANGED
@@ -30,6 +30,11 @@ module Permissable
|
|
30
30
|
# TODO: There has to be a friendlier way to mass assign permissions to roles rather than
|
31
31
|
# looping each one for existence and then saving separately.
|
32
32
|
def can!(methods, resources)
|
33
|
+
|
34
|
+
# This method should return all of the new permissions that were created, so we build a
|
35
|
+
# response array to return
|
36
|
+
response = []
|
37
|
+
|
33
38
|
[resources].flatten.each do |resource|
|
34
39
|
|
35
40
|
# Kind of unecessary but since some methods allow you to specify a Classname directly, this just
|
@@ -48,10 +53,13 @@ module Permissable
|
|
48
53
|
perm = Permission.new(:member_id => member_id, :member_type => identifier[:member_type], :permission_type => method.to_s.downcase)
|
49
54
|
perm.resource = resource
|
50
55
|
perm.save
|
56
|
+
response << perm
|
51
57
|
end
|
52
58
|
end
|
53
59
|
end
|
54
60
|
|
61
|
+
(response.size == 1) ? response.first : response
|
62
|
+
|
55
63
|
end
|
56
64
|
|
57
65
|
# This sets the member information for our permission lookup based on the current resource scope.
|
data/lib/permissable.rb
CHANGED
@@ -71,7 +71,7 @@ module Permissable
|
|
71
71
|
|
72
72
|
# Our association also creates a has_many association on our permissions table.
|
73
73
|
assoc.class_eval do
|
74
|
-
has_many(:permissions, :as => :member, :conditions => { :member_type => "#{self.to_s}" }) unless respond_to? :permissions
|
74
|
+
has_many(:permissions, :as => :member, :conditions => { :member_type => "#{self.to_s}" }), :dependent => :destroy unless respond_to? :permissions
|
75
75
|
include Permissable::Member
|
76
76
|
class_inheritable_accessor :permission_types
|
77
77
|
write_inheritable_attribute(:permissable_associations, {})
|
@@ -85,7 +85,7 @@ module Permissable
|
|
85
85
|
|
86
86
|
# Setup a has_many association of permissions on our resource.
|
87
87
|
resource.constantize.class_eval do
|
88
|
-
has_many(:permissions, :as => :resource, :conditions => { :resource_type => "#{self.to_s}" }) unless respond_to? :permissions
|
88
|
+
has_many(:permissions, :as => :resource, :conditions => { :resource_type => "#{self.to_s}" }), :dependent => :destroy unless respond_to? :permissions
|
89
89
|
end
|
90
90
|
|
91
91
|
resource.constantize.instance_eval{ include Permissable::Resource }
|
@@ -101,7 +101,7 @@ module Permissable
|
|
101
101
|
self.send :permission_types=, options[:to]
|
102
102
|
|
103
103
|
# Members create a has_many association on permissions as a member.
|
104
|
-
has_many(:permissions, :as => :member, :conditions => { :member_type => "#{self.to_s}" }) unless respond_to? :permissions
|
104
|
+
has_many(:permissions, :as => :member, :conditions => { :member_type => "#{self.to_s}" }), :dependent => :destroy unless respond_to? :permissions
|
105
105
|
|
106
106
|
end
|
107
107
|
|
data/permissable.gemspec
CHANGED
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: permissable
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 21
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 2
|
9
|
-
-
|
10
|
-
version: 0.2.
|
9
|
+
- 1
|
10
|
+
version: 0.2.1
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Brent Kirby
|