Bug #38670

Feature #36172: Forge cleanup and update umbrella issue

fix project tree / structure

Added by Peter Niederlag over 9 years ago. Updated almost 7 years ago.

Could have
Server Administration
Target version:
Start date:
Due date:
% Done:


Estimated time:


currently the tree structure of the projects seems pretty much messed up and doesn't reflect the logical structure. This seems to be fixd by some hacks for the navigation pane on the left.

It should be fixed by checking the parents of all projects and assigning the proper parent projects.


Updated by Peter Niederlag over 9 years ago

  • Parent task set to #36172

Updated by Peter Niederlag over 9 years ago

  • Assignee deleted (Peter Niederlag)

Updated by Michael Stucki over 9 years ago

Peters mail, for later reference:

Hi Stucki,

danke für dein Feedback bis hier.

- http://forge.typo3.org/projects/usability/issues > Erstes Issue in der
Liste > Facebook chars .. bla > "typo3.org Projekt"
- Wenn auf "Add Filter" klickst und dann "Subproject" auswählst und dort
dann "is" anwählst, seist du die Liste aller Subs.

Soll ich das admin Team anschreiben?
Wirkt auf mich eher wie ein Konzept / Architektur Fehler oder Config bug.

Greez Jens


well, afaik we didn't change anything in this regard, at least not me.

as a matter of fact this reflects the current structure of the projects
as it is set in the database.

Don't really know why all of these projects are assigned as subprojects
of the usability team. Looking at the project tree(screen attached) the
whole structure seems pretty weird to me.

Btw. we are talking about the "Usability Team" here, which has the key

There is also a project "Usability & Design" withe the key

<phewww>this one seems to be the intended parent? also it doesn't
reflect the structure this one will show three subprojects in the
navigation on the left.</phewww>

This definitly needs some attention/cleanup! don't know when I'll find
time for this as I will be on vacation next week. I created a ticket for
this issue:



Updated by Steffen Gebert over 9 years ago

  • Status changed from New to Resolved
  • Assignee set to Steffen Gebert

Resolved by running

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

See http://www.redmine.org/issues/3722 and http://www.redmine.org/issues/6579


Updated by Steffen Gebert almost 9 years ago

  • Status changed from Resolved to Closed

Updated by Steffen Gebert over 8 years ago

  • % Done changed from 0 to 100

Updated by Steffen Gebert almost 7 years ago

The same issue occurred once again, however with Issues instead of projects (issue #63692).

Due to the number of issues (64,000), the rebuild takes several hours (on a testing instance).

The final solution was to copy the data base to a testing instance and DELETE FROM issues @WHERE root_id <> 63692. Now, the Issue.rebuild! takes only seconds. Afterwards, the new values for lft and rgt have to be set on the production database (for sure, assuming that no issue relationships regarding that root_id have changed during that time).

For documentary purposes, the Issue.rebuild! as documented above and in redmine's issue tracker throwed after ~15min

ActiveRecord::StaleObjectError: ActiveRecord::StaleObjectError

The solution for that problem is described here: http://www.expertsys.hu/2014/11/25/redmine-awesome_nested_set-issue-rebuild-lock_version-and-activerecordstaleobjecterror/

Therefore, the command that should be run is ruby script/runner -e production 'ActiveRecord::Base.lock_optimistically = false; Issue.rebuild!' (but as said, this still would take hours).

Also available in: Atom PDF