Project

General

Profile

Actions
Copy link

Defect #4257

open

Broken support for Principal plugins

Added by Alexey Palazhchenko about 15 years ago. Updated almost 12 years ago.

Status:
New
Priority:
High
Assignee:
-
Category:
Plugin API
Target version:
-
Start date:
2009-11-20
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

I'm not sure when exactly it happens (it's worked sometime ago), but things becomes broken for Principal with empty plugin.

How to reproduce:

$ cat vendor/plugins/test_plugin/init.rb
require 'redmine'

require 'dispatcher'
Dispatcher.to_prepare :test_plugin do
  require_dependency 'principal'
end

Redmine::Plugin.register :test_plugin do
end

(no other files in vendor/test_plugin)

$ rake test:units
<...>
1) Failure:
test_roles_updated(GroupTest) [/test/unit/group_test.rb:57]:
<[1, 2]> expected but was
<[1]>.
2) Failure:
test_visible_scope_for_user(IssueTest) [/test/unit/issue_test.rb:94]:
<false> is not true.
478 tests, 2036 assertions, 2 failures, 0 errors

Related issues

Related to Redmine - Defect #5434: Redmine 0.9.3 - HTTP500 when trying to filter users for adding to a groupClosedJean-Philippe Lang2010-05-04

Actions
Actions
Copy link
 #1

Updated by Alexey Palazhchenko almost 15 years ago

Any ideas? Please help, it's showstoper for me.

Actions
Copy link
 #2

Updated by Alexey Palazhchenko almost 15 years ago

  • Assignee changed from Eric Davis to Jean-Philippe Lang

Jean-Philippe, any ideas?

Actions
Copy link
 #3

Updated by Alexey Palazhchenko almost 15 years ago

Ok, second failure was bisect down to r3039. No idea about first yet...

Actions
Copy link
 #4

Updated by Eric Davis almost 15 years ago

Aleksey:

That's really odd. I have a few plugins that work with Users that are still working. Is this failing in just a test plugin or something you are working on?

Actions
Copy link
 #5

Updated by Alexey Palazhchenko almost 15 years ago

Eric, I'm working on plugin for some Redmine models. When I found this 2 broken tests, I started to remove code from my plugin – and it's ended with this bare skeleton.

Actions
Copy link
 #6

Updated by Jean-Baptiste Barth about 14 years ago

  • Assignee deleted (Jean-Philippe Lang)

Had the same kind of problem recently with memberships. It seems Rails has some troubles reloading things correctly when some classes has been reloaded through engines. It may have something to do with STI (doesn't affect other classes from what I've seen).

For instance, with your test plugin, in test/unit/group_test.rb, line 57: 

assert_equal [1, 2], user.reload.roles_for_project(project).collect(&:id).sort
#=> KO
assert_equal [1, 2], User.find(9).roles_for_project(project).collect(&:id).sort
#=> OK

I tried to mark some classes as unloadable in the core, doesn't change anything...

Actions
Copy link
 #7

Updated by Jean-Baptiste Barth about 14 years ago

  • Status changed from New to 7
  • Assignee set to Jean-Baptiste Barth

I continue to think it's a rails bug, but it's solved by forcing memberships reload in User model : 

  def reload(*args)
    @name = nil
    self.memberships.reload
    super(*args)
  end

Any thought about integrating that into the core ? (note it also works when monkey patching User class this way in the plugin...)

Actions
Copy link
 #8

Updated by Alexey Palazhchenko about 14 years ago

Any thought about integrating that into the core ?

I'm for it, with a big FIXME comment.
Is it a know Rails bug?

Actions
Copy link
 #9

Updated by Jean-Baptiste Barth about 14 years ago

Alexey Palazhchenko wrote:

Is it a know Rails bug?

Didn't find it on lighthouse. It seems inherited scopes (in our case User#like) are also lost when reloading...

Actions
Copy link
 #10

Updated by Jean-Baptiste Barth over 12 years ago

  • Assignee deleted (Jean-Baptiste Barth)
Actions
Copy link
 #11

Updated by Jean-Philippe Lang almost 12 years ago

  • Status changed from 7 to New

Assigned issue with no assignee back to New status.

Actions
Copy link

Also available in: Atom PDF