permissable 0.2.0 → 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- 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
|