Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

permissions: undefined method `can_read_forem_forums?' #88

Closed
kulpae opened this issue Nov 29, 2011 · 21 comments
Closed

permissions: undefined method `can_read_forem_forums?' #88

kulpae opened this issue Nov 29, 2011 · 21 comments

Comments

@kulpae
Copy link

kulpae commented Nov 29, 2011

Running webrick for development I keep getting this nasty error:

Showing /home/kulpae/.rvm/gems/ruby-1.9.2-p180/bundler/gems/forem-76d997679209/app/views/forem/categories/_category.html.erb where line #1 raised:

undefined method `can_read_forem_forums?' for #<User:0x000000050f3020>

I've an initializer config/initializers/forem.rb with

Forem.user_class = User

Observations:

  • After the server is started, the first request works, the following requests don't.
  • Overriding the can_* methods in the User model fixes the error, but I don't think it's how it supposed to be...
@radar
Copy link
Collaborator

radar commented Nov 29, 2011

Oh bother. That's because the User class is reloaded every request in dev environment.

You can get around this bug by putting this inside your User model:

include Forem::DefaultPermissions

I will fix this in the morning to be inside a config.to_prepare hook on the engine.

Thanks for reporting!

On 29/11/2011, at 22:23, Paul [email protected] wrote:

Running webrick for development I keep getting this nasty error:

Showing /home/kulpae/.rvm/gems/ruby-1.9.2-p180/bundler/gems/forem-76d997679209/app/views/forem/categories/_category.html.erb where line #1 raised:

undefined method `can_read_forem_forums?' for #User:0x000000050f3020

I've an initializer config/initializers/forem.rb with

Forem.user_class = User

Observations:

  • After the server is started, the first request works, the following requests don't.
  • Overriding the can_* methods in the User model fixes the error, but I don't think it's how it supposed to be...

Reply to this email directly or view it on GitHub:
#88

@radar
Copy link
Collaborator

radar commented Nov 29, 2011

I fixed this in @056de4c and forgot to mention it in the commit message. Thanks again for letting us know of this one.

@radar radar closed this as completed Nov 29, 2011
@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

weird, the bug is still there.. In case I've messed up s.th. in my app or some gem is interfering, I created a new rails 3.1.1 app with devise and forem only, still the same error.

Observations:

  • to_prepare is being called before the error occurs as expected
  • After replacing Forem.user_class.send :include, Forem::DefaultPermissions with User.send :include, Forem::DefaultPermissions the error disappears
  • puts Forem.user_class before Forem.user_class.send :include, Forem::DefaultPermissions outputs User as supposed (Forem.user_class.class => Class)

@radar radar reopened this Nov 30, 2011
@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Wow, that's very weird. It totally didn't expect that. Looking into it.

@radar radar closed this as completed in 10083b3 Nov 30, 2011
@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Ok, I'm stupid. It happens sometimes. Was hardcoding it to User in forem/ability.rb (fix is in @10083b3), which believe it or not is actually different to Forem.user_class due to the wonders of class reloading. Joy of joys.

But hey! We got it fixed :)

@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

:) I think it's still not fixed ^^
The same error message again...

If I put user.class.send :include, Forem::DefaultPermissions in ability.rb, it works, so for some reason the value of Forem.user_class in engine.rb's to_prepare and in ability.rb differ.

@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Could you show me what your forem/ability.rb look slik eplease?

@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Ok, that's exactly what I have and with my local version I can make multiple requests and not have it error out. What page are you doing this on? Maybe that has something to do with it?

@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

amazing.. I just went to localhost:3000/forem/ with firefox, and it works, refreshing, still works... with chromium it throws this error... on the same server.. so tried clearing the cookies.. here we go, works now... so for some reason some cookie caused it? (also on a new rails app, but yeah the domain is still the same, d'oh)
---- oh forget to login... after login the same error...

@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Super weird! I don't know, sorry.

@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

Whats interesting is, it worked yesterday on dev and it still works on production, so not a big deal...
I know I bundle updated and rerun rails g forem:install since.

@kulpae
Copy link
Author

kulpae commented Nov 30, 2011

Thank you for your time ;)

@radar
Copy link
Collaborator

radar commented Nov 30, 2011

You don't need to run rails g forem:install after bundle update if you've already run it once. It's designed to a one-time only thing: https://github.com/radar/forem/blob/master/lib/generators/forem/install_generator.rb.

@radar
Copy link
Collaborator

radar commented Nov 30, 2011

Thanks for your interest in using Forem :)

@radar
Copy link
Collaborator

radar commented Dec 5, 2011

This issue is still happening!

I think it's due to a class caching issue. Whatever's responsible for specifying the class for current_user is doing it wrong. I think it's using an old version of the User class or something like that, because the current_user object that's being passed to the initialize method inside forem/ability.rb doesn't have the permission methods on it.

As much as I hate to, I've done a bandaid fix in @6d84403 to work around this issue. Hopefully very temporarily.

@kulpae
Copy link
Author

kulpae commented Dec 5, 2011

works now ;) thank you very much

@radar
Copy link
Collaborator

radar commented Dec 19, 2011

I think I understand why it's happening now, at least. In dev environment when you set user_class you're setting it to a class object, which I suspect is the original User class. This is why it works on the first request but not on the second.

What I think we need to do is make people set this to a string so that when we go to reference it we call it like this:

Forem.user_class.constantize

What that'll do is that it'll grab the currently available User class, which will not be the old one but the one that's been most recently loaded by Rails.

For my next trick, I'm going to need to work out how to deprecate this neatly.

@radar radar closed this as completed in bb394d9 Dec 20, 2011
@radar
Copy link
Collaborator

radar commented Dec 20, 2011

Pretty damn confident in the above explanation. Deprecating user_class= taking a Class argument now after the 20th January. I think that one month is long enough now.

@wiseleyb
Copy link

wiseleyb commented Mar 4, 2012

Any tips for getting this working along side Spree? I'm getting:

undefined method `can_read_forem_forums?' for #Spree::User:0x007f90ea45a3f8

I think the easiest thing would be to use something other than User in the app and leave User to spree (1.0.0) but thought I'd check first.

@radar
Copy link
Collaborator

radar commented Mar 5, 2012

Hey Ben,

You did set this up as Forem.user_class yes?

If you happen to have two User classes, then you would need to manually include the Forem::DefaultPermissions module into Spree::User class as a to_prepare hook in your application. That's the module that'll define the can_read_forem_forums? method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants