Feature #36172: Forge cleanup and update umbrella issue
fix project tree / structure
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 Michael Stucki about 9 years ago
Peters mail, for later reference:
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.
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
Updated by Steffen Gebert about 9 years ago
- Status changed from New to Resolved
- Assignee set to Steffen Gebert
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
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
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).