Redmine

Forgot to add, after the patch to awesome_nested_set, you need to run the following in the Rails Root directory.

bundle exec ruby script/rails runner -e production 'Project.update_all(:lft=>nil,:rgt=>nil); Project.rebuild!'

Note that you do not need to run Project.rebuild_tree!, just awesome_nested_set's Project.rebuild!.

@ go2null wrote:

Forgot to add, after the patch to awesome_nested_set, you need to run the following in the Rails Root directory.
[...]

Note that you do not need to run Project.rebuild_tree!, just awesome_nested_set's Project.rebuild!.

You need to run Project.rebuild_tree!.
See source and comment.
source:tags/2.5.2/app/models/project.rb#L417

@ go2null wrote:

Workaround (#6836#note-12) per Ken Zalewski still works.
[...]

It is not work because Redmine build tree after_save .
source:tags/2.5.2/app/models/project.rb#L82

@ go2null wrote:

Apparently, this is due to the removal, in v2.5, of the patched awesome_nested_set plugin from the Redmine lib/plugins directory.
http://www.redmine.org/projects/redmine/repository/show/tags/2.4.6/lib/plugins
http://www.redmine.org/projects/redmine/repository/show/tags/2.5.0/lib/plugins
http://www.redmine.org/projects/redmine/repository/show/branches/2.4-stable/lib/plugins
http://www.redmine.org/projects/redmine/repository/show/branches/2.5-stable/lib/plugins

The patched awesome_nested_set is still available in trunk.
http://www.redmine.org/projects/redmine/repository/show/trunk/lib/plugins

It is because awesome_nested_set after 2.1.6 refactoring is broken.

I tried both rebuild! and rebuild_tree!, but without the patched rebuild! in awesome_nested_set it did not work.

The issue is not with rebuild_tree!. In fact, based on some debug puts that I added, the issue is actually that the move_to_left_of(to_be_inserted_before) in set_or_update_position_under does not properly update the lft and rgt. (The incorrect sort is consistent and reproducible every time.)

(I'm mobile so can't attach debug log nor be as descriptive as I'd like.)

A naive question : is nested set functionality needed for Projects?

@ go2null wrote:

I tried both rebuild! and rebuild_tree!, but without the patched rebuild! in awesome_nested_set it did not work.

What is patched?
awesome_nested_set 2.1-stable on Redmine trunk is refactored heavily.

Unit tests cover these cases.
source:tags/2.5.2/test/unit/project_nested_set_test.rb

Toshi MARUYAMA wrote:

@ go2null wrote:

I tried both rebuild! and rebuild_tree!, but without the patched rebuild! in awesome_nested_set it did not work.

What is patched?
awesome_nested_set 2.1-stable on Redmine trunk is refactored heavily.

I was referring to my manual patching of .id to .name in a pristine awesome_nested_set-2.1.6.

@ go2null wrote:

I was referring to my manual patching of .id to .name in a pristine awesome_nested_set-2.1.6.

Did you copy awesome_nested_set 2.1.6 to plugin/ directory?

OK, found why the problem happens.

Say I have a project with 4 subprojects ([id] name):
=> [790] Project 1, [792] Project 2, [789] Project 3, [791] Project 4

• rebuild_tree!
• rebuild!(false)
  • sorts by id.
  • => [789] Project 3, [790] Project 1, [791] Project 4, [792] Project 2
• all.each { |p| p.set_or_update_position_under(p.parent) }
  • processes each project by id order.
  • => [789] Project 3
• set_or_update_position_under
• to_be_inserted_before = sibs.sort_by {|c| c.name.to_s.downcase}.detect {|c| c.name.to_s.downcase > project.name.to_s.downcase }
  • gets project that should be on the right, sorted alphabetically by name.
  • => [791] Project 4
• if to_be_inserted_before @move_to_left_of(to_be_inserted_before)
  • moves to left of project found above
  • => [790] Project 1, [789] Project 3, [791] Project 4, [792] Project 2

Repeating this for each project yields:
=> [789] Project 3, [790] Project 1, [791] Project 4, [792] Project 2 # sorted by id
=> [790] Project 1, [789] Project 3, [791] Project 4, [792] Project 2 # [789] P3 < P4
=> [789] Project 3, [791] Project 4, [790] Project 1, [792] Project 2 # [790] P1 < P2
=> [789] Project 3, [790] Project 1, [792] Project 2, [791] Project 4 # [791] P4 < end
=> [792] Project 2, [789] Project 3, [790] Project 1, [791] Project 4 # [792] P2 < P3

Toshi MARUYAMA wrote:

@ go2null wrote:

I was referring to my manual patching of .id to .name in a pristine awesome_nested_set-2.1.6.

Did you copy awesome_nested_set 2.1.6 to plugin/ directory?

No, I just edited the one in /usr/lib/... as I was trying different things.

deleted

1. include back the vanilla awesome_nested_set 2.1.6 and
   1. patch the id to name, and
   2. no need for the all.each { |p| p.set_or_update_position_under(p.parent) } in rebuild_tree!. (At least for this use case), or
2. patch set_or_update_position_under to recursively process each to_be_inserted_before. (to_be_inserted_before becomes an array?)

Disclaimer: my ruby skills are virtually non-existent :-)

@ go2null wrote:

Toshi MARUYAMA wrote:

@ go2null wrote:

I was referring to my manual patching of .id to .name in a pristine awesome_nested_set-2.1.6.

Did you copy awesome_nested_set 2.1.6 to plugin/ directory?

No, I just edited the one in /usr/lib/... as I was trying different things.

Did you modify gem *.rb files?
It causes unexpected result.
If you want to modify awesome_nested_set 2.1.6,
you should copy awesome_nested_set 2.1.6 as r12687 and r12688,
then remove awesome_nested_set from Gemfile.
source:tags/2.5.2/Gemfile#L10

Toshi MARUYAMA wrote:

@ go2null wrote:

Toshi MARUYAMA wrote:

@ go2null wrote:

I was referring to my manual patching of .id to .name in a pristine awesome_nested_set-2.1.6.

Did you copy awesome_nested_set 2.1.6 to plugin/ directory?

No, I just edited the one in /usr/lib/... as I was trying different things.

Did you modify gem *.rb files?
It causes unexpected result.
If you want to modify awesome_nested_set 2.1.6,
you should copy awesome_nested_set 2.1.6 as r12687 and r12688,
then remove awesome_nested_set from Gemfile.
source:tags/2.5.2/Gemfile#L10

Ok, will do so next week.

Do you have any update on this? Ordering projects by name is definitely broken in redmine 2.5.3 and I guess it's still broken in redmine 2.6.* since no fix is mentioned in the changelogs.

Furthermore I can confirm that applying the patch / workaround mentioned in the ticket and running Project.rebuild_tree! fixes the issue

Daniel Freudenberger wrote:

Do you have any update on this? Ordering projects by name is definitely broken in redmine 2.5.3 and I guess it's still broken in redmine 2.6.* since no fix is mentioned in the changelogs.

Yes, it's broken in 2.6.x. Currently i'm using 2.6.1.stable (without any modifications in sources) and after running Project.rebuild_tree! i got a total mess with sorting (even worst than before).

Redmine 2.x sorts projects at source:tags/2.6.1/app/models/project.rb#L1045 ,
due to awesome_nested_set bugs.
This logic is removed in Redmine 3.

I too am seeing this issue.

We are also seeing this issue, following a migration from 2.6.0 to 3.0.1.

Toshi MARUYAMA wrote:

If your project tree of Redmine 3.0 is broken, it was broken in Redmine 2.6.

Ok, thank you for the quick answer. We'll try this fix. We did not have any issues in 2.6.0. Since migrating to 3.0.1 last week, all new projects created appear at the bottom, but the ones created before the migration are correctly sorted by name. Anyway, if the Project.rebuild_tree! command doesn't do it, we'll open a new issue.