undefined method `registered' for nil:NilClass

64 views
Skip to first unread message

Emilio

unread,
Nov 21, 2011, 10:09:30 AM11/21/11
to cantango
After following the Quickstart (adapted for my test project), I'm
receiving the error in the subject when issuing
CanTango.debug_permits_registry. I'd appreciate any guidance for
finding what I am doing wrong.

cantango gem version: 0.9.4.3

Emilio

Kristian Mandrup

unread,
Nov 21, 2011, 1:25:36 PM11/21/11
to cant...@googlegroups.com
undefined method `registered' for nil:NilClass, means that it is trying to operate on some object, expecting it to be a Registry (see cantango/configuration folder) but for some reason that configuration object is nil. Could you please show me the backtrace of the error.

I'm currently doing some major refactoring of cantango, splitting it into smaller parts and improving the test suite to make sure the code is pretty much fully covered. I have been developing new features a bit "too fast" since 0.9 and not been testing all the pieces thoroughly enough, so I appreciate anytime one of you finds and notifies me of a bug.

You could also clone the repo and reference your local version from your project and then debug and make fixes yourself and then when fixed, make me a pull request ;)

Thanks!

Kristian

Emilio

unread,
Nov 21, 2011, 1:46:14 PM11/21/11
to cantango

Hi Kristian,

Here https://gist.github.com/1cdbf67c876c0abeb635 is the trace for the
error. I'll try to understand what is happening and see if I can help.

Emilio

Kristian Mandrup

unread,
Nov 21, 2011, 2:45:16 PM11/21/11
to cant...@googlegroups.com
If you look at cantango/configuration/permit_registry.rb

      def all
        (CanTango.config.permits.available_types - [:special]).map{|p| send(p) if respond_to?(p)}
      end
def get permit
end

Ah, I recently changed the API here to use the #get method instead !
Should instead be:

      def all
        (CanTango.config.permits.available_types - [:special]).map{|p| get p }
      end

Well, would be better named as:

def get_permit label
end

      def all
        (CanTango.config.permits.available_types - [:special]).map{|label| get_permit label }
      end

Then if you look at cantango/configuration/permits.rb

      def available_types
        available_permits.keys
      end
      def available_permits
        @available_permits ||= default_permits
      end
      def default_permits
        { :user => CanTango::Permits::UserPermit,
          :account => CanTango::Permits::AccountPermit,
          :role => CanTango::Permits::RolePermit,
          :role_group => CanTango::Permits::RoleGroupPermit,
          :special => nil
        }
      end
Hope that helps!

Kristian Mandrup

unread,
Nov 21, 2011, 3:11:45 PM11/21/11
to cant...@googlegroups.com
I've just fixed the bug in master and released a new gem patch release

On Nov 21, 2011, at 7:46 PM, Emilio wrote:

Emilio

unread,
Nov 21, 2011, 3:24:31 PM11/21/11
to cantango
Nice.

I tested the 0.9.4.5 and it now prints

permits registry:[#<Hashie::Mash>, #<Hashie::Mash>, #<Hashie::Mash>,
#<Hashie::Mash>]

And when I try a user_can?(...), I get a "no key", which is raised
when it tries to invalidate session[:permission], I guess. Here is the
trace for this error: https://gist.github.com/7eee1f2394f89a0cb8c8

Thanks,

Emilio

> > Herehttps://gist.github.com/1cdbf67c876c0abeb635is the trace for the

Kristian Mandrup

unread,
Nov 21, 2011, 3:35:50 PM11/21/11
to cant...@googlegroups.com
The "No key" error is (unfortunately) a common error :P

It means that cantango tries to cache the ability rules for the user, but that it doesn't know how to generate a unique hash for that user (cache key).
In order to do so, it needs to know of a unique field to use for that key, typically :email (#email method). You can configure (customize) which field/method to use (see Configuration in the wiki).

Check out the cantango-demo to see an example setup somewhat resembling the Quickstart tutorial. I might have missed a few things in the tutorial.
I should also have a FAQ page describing common errors/problems. Please also check the state of your User. Some people have been using User.new, where all attributes are nil, and thus email is also nil, which is not valid for generating the hash (cache) key.

Kris

Emilio

unread,
Nov 21, 2011, 6:31:53 PM11/21/11
to cantango
Well, the User model has the #email method and there is an entity in
the database with the field filled.

After some debugging, I found that the session[cache_key] is not set
for cache_key = :permission, only for :rules_cache.

Emilio

> >>> Herehttps://gist.github.com/1cdbf67c876c0abeb635isthe trace for the

Kristian Mandrup

unread,
Nov 22, 2011, 3:27:11 AM11/22/11
to cant...@googlegroups.com
Could you please raise an issue on my github page for can tango, and then show me where exactly the problem lies. Would like to have it fixed ASAP. Thanks :)

betasheet

unread,
Nov 23, 2011, 10:22:06 AM11/23/11
to cantango
@Kristian: In your fix, it seems to me, that you forgot to change
"get(type).registered" in line 16 of permit_registry.rb to
"get_permit(type).registered".

> >>>>> Herehttps://gist.github.com/1cdbf67c876c0abeb635isthetrace for the

Kristian Mandrup

unread,
Nov 23, 2011, 10:40:09 AM11/23/11
to cant...@googlegroups.com
Yes, it was a quick fix - not well tested. Since then I have made a project cantango-config, with full test coverage of all the config options. Would be better to include this gem cantango-config from cantango

I am currently refactoring can tango from the ground up.

If you are having problems with the Permission store, please try to contact @stanislaw as he was the main implementer of the storage and load system.

Kristian

betasheet

unread,
Nov 23, 2011, 11:53:25 AM11/23/11
to cantango
Thanks, we've just encountered another place where get should be
changed to get_permit:

cantango-0.9.4.5/lib/cantango/configuration/permits.rb:84
registry.get(permit_type)[permit_name] = permit_clazz

change to:
registry.get_permit(permit_type)[permit_name] = permit_clazz

Best regards
Eric

> >>>>>>> Herehttps://gist.github.com/1cdbf67c876c0abeb635isthetracefor the

betasheet

unread,
Nov 24, 2011, 4:30:22 AM11/24/11
to cantango
Hi Kristian,

could you push the fixes for the two bugs into the repo including a
new version bump, please?
Then, we could use the plugin in our team environment without having
every team member have to manually fix them..

Thanks a lot
Eric

betasheet

unread,
Nov 24, 2011, 5:05:04 AM11/24/11
to cantango
Sorry to bother you again :-/
Is there any particular reason for the debug message "valid_mode? true
[:no_cache] false" appearing in the logs even though debug is set to
off?

Kristian Mandrup

unread,
Nov 24, 2011, 6:02:36 AM11/24/11
to cant...@googlegroups.com
It sounds like this is another bug, probably a leftover from some internal debugging I did at some point…
Thanks :)

Kristian Mandrup

unread,
Nov 24, 2011, 6:04:06 AM11/24/11
to cant...@googlegroups.com
Please send me a pull request with your fixes to troles and cantango master. Thanks again :)

Den 24/11/2011 kl. 11.05 skrev betasheet:

Kristian Mandrup

unread,
Nov 24, 2011, 7:22:49 AM11/24/11
to cant...@googlegroups.com
I just pushed the fixes to master and released v0.9.4.6

You can now configure the role/role groups system directly like this:

Cantango.config.roles.role_system = :troles

And the role_list method should be set "correctly" to match the given role system API. Same goes for role groups. Pushed to master branch for now.

module CanTango
class Configuration
class Roles < RoleRegistry
include Singleton

def role_system= name
raise ArgumentError, "Must be a label" if !name.kind_of_label?
@role_system = name.to_sym
end

def roles_list_map= role_systems_hash
raise ArgumentError, "Must be a hash fx :troles => :role_list, was: #{role_systems_hash}" if !role_systems_hash.kind_of?(Hash)
@roles_list_map = role_systems_hash
end

def role_system
@role_system ||= :troles
end

def add_role_system role_system_hash
raise ArgumentError, "Must be a hash fx :troles => :role_list, was: #{role_system_hash}" if !role_system_hash.kind_of?(Hash)
roles_list_map.merge! role_system
end

def default_has_method
:has_role?
end

def default_list_method
roles_list_map[role_system] || :roles_list
end

def roles_list_map
@roles_list_map ||= {
:troles => :role_list
}
end
end
end
end


Den 24/11/2011 kl. 11.05 skrev betasheet:

betasheet

unread,
Nov 24, 2011, 8:39:11 AM11/24/11
to cantango
Great idea :) Did you publish the latest role system change commit,
too? Seems to me like setting Cantango.config.roles.role_system is not
yet possible in 0.9.4.6, but in the head of the git master branch it
is.
By the way, we had to switch to simple_roles instead of troles, as
configuring the roles for a user wasn't possible through rails CRUD
functionality. Somehow, the views always ran into undefined method
errors for e.g. role_list.
With simple_roles, we could just add a select for the "roles" field of
the user.

Thanks for your help!
Eric

Kristian Mandrup

unread,
Nov 24, 2011, 8:59:37 AM11/24/11
to cant...@googlegroups.com
Yeah, for now I recommend using @simple_roles@ gem. Good choice!
I will rework troles once I get CanTango to 1.0.
True, I didn't release the role_system config changes to a gem yet. Will do…
Glad to hear you are making progress and have overcome the worst hurdles. You are welcome to add a FAQ or troubleshooting page to the Wiki with your experiences etc. Thanks!

Kristian Mandrup

unread,
Nov 24, 2011, 9:54:11 AM11/24/11
to cant...@googlegroups.com
Pushed the latest fixes to 0.9.4.7. Check the README in the Update section ;)
simple_roles is now assumed as the default role system.

Den 24/11/2011 kl. 14.39 skrev betasheet:

Reply all
Reply to author
Forward
0 new messages