Feature #594

Remove limit on subproject nesting

Added by Pier Giorgio Esposito almost 10 years ago. Updated almost 8 years ago.

Status:ClosedStart date:2008-02-03
Priority:NormalDue date:
Assignee:Jean-Philippe Lang% Done:

0%

Category:Projects
Target version:0.9.0
Resolution:Fixed

Description

I would like to see this enhancement for a better management of larger projects, where a deeper nesting is often used.

subproject_no_level.diff Magnifier (3.95 KB) Jérémie HATTAT, 2008-09-12 15:17


Related issues

Related to Redmine - Feature #15290: Define subproject nesting depth limit New
Duplicated by Redmine - Feature #1989: Multilevel Relationship between Projects Closed 2008-10-05
Duplicated by Redmine - Feature #1840: Merge projects and issues classes to allow more hierarchi... Closed 2008-09-01
Duplicated by Redmine - Feature #1004: Suggestion: Subprojects of subproject...? Closed 2008-04-06

Associated revisions

Revision 2304
Added by Jean-Philippe Lang almost 9 years ago

Merged nested projects branch. Removes limit on subproject nesting (#594).

History

#1 Updated by glen geisen almost 10 years ago

I would utilize this too.

#2 Updated by Karsten Dambekalns almost 10 years ago

I would love to see this, as we really need this over at TYPO3...

What are the reasons for the current limitation? And how hard would it be to remove it?

#3 Updated by Jean-Philippe Lang almost 10 years ago

What are the reasons for the current limitation?

Just to keep it simple.

And how hard would it be to remove it?

To be efficient this would require to replace projects trees by nested sets.
It's not planned for now.

#4 Updated by Denis Anokhin almost 10 years ago

It would be great (and I think enough in the most cases) if there will be support for at least 3 levels of project nesting.

P.S.: Thank you for your great work! Redmine is super! :)

#5 Updated by Sebastian Kurfuerst over 9 years ago

Hello everybody,

I just wanted you to know that I'm currently working on fixing this, see: http://forge.typo3.org/issues/show/439 for the current status of the patch!
Note that we use a custom startpage plugin, that's why not everything in there is relevant for you.

Greets,
Sebastian

#6 Updated by Brian Coughlin over 9 years ago

  • Target version set to 0.8

Adding at least a 3rd level (level below Subproject) would be very helpful.

#7 Updated by Brian Coughlin over 9 years ago

  • Assignee set to Jean-Philippe Lang

Please see code hacks suggested for this Issue at http://www.redmine.org/boards/1/topics/show/893

#8 Updated by Jean-Philippe Lang over 9 years ago

I agree that it would be great, but these simple "hacks" won't do the trick.
It's not that simple.

#9 Updated by Jean-Philippe Lang over 9 years ago

  • Target version deleted (0.8)

#10 Updated by Jean-Philippe Lang over 9 years ago

  • Target version set to 0.9.0

#11 Updated by Andreas Fischer over 9 years ago

I would like to see that too. It would be a great enhancement. Maybe you could introduce a project type 'category' or something similar too. In my opinion it would be good to have somehow an option to group projects together. Like all website projects in one category, all ruby projects in one categories etc. But, hmm, maybe a tagging system would be better to do that.

Best Regards,
bantu

#12 Updated by Jérémie HATTAT over 9 years ago

Hi all,

We have made change to eliminate the 1 level subproject limitation from the r1797.

These change start from the http://forge.typo3.org/issues/show/439 patch.

File to change are : app/model/project.rb, app/model/query.rb and app/controller/project_controller.rb.

We replace the child_ids, by the computation of the full child list.
The all the child issues are visible in the gantt and issues report.

Best regards

#13 Updated by Pier Giorgio Esposito about 9 years ago

Hi,
I have applied the patch provided by Jéremié and I am currently Redmine for a complex project. It is working smoothly, apart some minor problems. For example, the Overview page of each project does not show the correct number of issues related to it, because Redmine does not count them recursively.

Any hint to address this problem?

Thanks
Pier Giorgio

#14 Updated by Yaroslav Matsera about 9 years ago

+1
It's important for me too.

#15 Updated by Stephen Weiss almost 9 years ago

+1

Agreed, while the patch is nice it would be even better if subprojects can inherit settings up the tree, and list/count items like issues recursively... Just had to go through and update the trackers on 20 projects that were all really descendants of one big project. I know it's a lot easier not to but... the work could be very rewarding in terms of how much time it could save.

#16 Updated by Mattis Lind almost 9 years ago

+1

It would be most useful to me to be able to handle three levels of projects in redmine.

#17 Updated by Paul Rivier almost 9 years ago

This will probably happen in 0.9.

Could we open a thread or a wiki page to discuss how to get the most power from this new feature ? I'm thinking of course of version inheritance (#465), but also wiki relations, membership inheritance etc. Generaly speaking, we should define inheritance (parent to children) and accumulation (children to parents) behaviours.

#18 Updated by Jean-Philippe Lang almost 9 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

This is committed in trunk at r2304.
Implementation uses awesome_nested_set plugin which is based on Nested set model and thus performance should not be affected by hierarchy depth.

Paul, that would be a good thing, you can create a wiki page for this. There are several requests about inheritance, a good start would be to list them all.

#19 Updated by Bob Roberts almost 9 years ago

I've update my SVN to get this feature but noticed that the "jump to project" combo box has disappeared. Is this by design or is it now configurable?

#20 Updated by Bob Roberts almost 9 years ago

Please disregard the above. This was a PEBKAC....project jump list appears once users are assigned projects!

#21 Updated by Cedric Moschallski almost 9 years ago

I've just updated to the "nested set" branch and everything seems to work.

Can anybody tell me how "save" it is to use this branch for productive environments? Of course I know that there could arise bugs and data corruption, but as we have regular updates I'm more worried about future updates...

Is it possible to do rake db:migrate once this feature has been merged in the stable branches?

#22 Updated by Jean-Philippe Lang almost 9 years ago

You'd better not use the nested_projects branch. It was used to initialy implement the feature, but it won't be updated and will be removed.
If you really want this feature, you can use the trunk.

#23 Updated by Cedric Moschallski almost 9 years ago

Is using the trunk-version not a bigger risk than using the nested-only branch? I took a look at the mysql tables changes and because I have worked with nested set before I thought this scheme will stay. So instead of using the trunk with many changes and possible problems I choose the nested set branch.

Sadly, immediately after I tried the nested set branch some co-workes started entering many tickets so know I have no choice but to wait for a public roll-out of this feature in the next stable version and hope I get no data-corruption when migrating.

Could you recommend any behaviour right now? Migrate to trunk? Or wait for a final version and try to migrate? Else I have to explain my co-workers that yesterdays work was for nothing :-)

#24 Updated by Nanda P over 8 years ago

I pulled the trunk version & it doesn't have the Project nesting..

Anyone idea?

#25 Updated by Nanda P over 8 years ago

Anyone tried the trunk version (0.8.3)

How to get "Unlimited Project nesting" work with trunk?

Any help will be appreciated.

#26 Updated by Andrew Chaika over 8 years ago

Nanda Palaniswamy wrote:

Anyone tried the trunk version (0.8.3)

0.8.3 is latest stable version. Current trunk version is 0.9.x. You can get it from svn: http://redmine.rubyforge.org/svn
Read - Download - Latest source code or CheckingoutRedmine - Development version

#27 Updated by Joris Aerts over 8 years ago

I just installed RedMine and I really like the unlimited nested project feature. The only problem I encountered so far is that different subprojects can't have the same name. For example, we build a race car every year, and we've got different departments. So our project tree would look something like this:

DUT09
- Electronics
- Suspension
- ...

DUT08
- Electronics
- Suspension
- ...

Right know I have to name them "DUT08" -> "DUT08_Electronics". Would it be possible to allow the same names (or identifiers) here? or to hide the prefix if it's the same as the parent project?

#28 Updated by Jason van Dyk over 8 years ago

Perhaps I've missed understood either that or I have the wrong branch revision. I'm using r2824 and I still have the problem with a sub project can not be a sub of another sub project.

e.g.

ProjectA
-ProjectSub
--ProjectSubSub

And from what I've read r2824 coming from the main trunk should be the version 0.9 release Jean-Philippe is talking about.

Could someone advise me of what's going wrong here.

#29 Updated by frank huang over 8 years ago

Jason van Dyk wrote:

Perhaps I've missed understood either that or I have the wrong branch revision. I'm using r2824 and I still have the problem with a sub project can not be a sub of another sub project.

e.g.

ProjectA
-ProjectSub
--ProjectSubSub

And from what I've read r2824 coming from the main trunk should be the version 0.9 release Jean-Philippe is talking about.

Could someone advise me of what's going wrong here.

I have the same puzzle on it.
I use the version from tags/0.8.5 .but i can not find this feature.
Does it need anything else to make it .

#30 Updated by Mischa The Evil over 8 years ago

frank huang wrote:

Jason van Dyk wrote:

Perhaps I've missed understood either that or I have the wrong branch revision. I'm using r2824 and I still have the problem with a sub project can not be a sub of another sub project.
...
And from what I've read r2824 coming from the main trunk should be the version 0.9 release Jean-Philippe is talking about.

Could someone advise me of what's going wrong here.

I have the same puzzle on it.
I use the version from tags/0.8.5 .but i can not find this feature.
Does it need anything else to make it .

If you are using Redmine 0.8.5 you don't have the feature since its implemented in the Redmine development version (source:/trunk a.k.a. Redmine 0.9.0) only.
The lack of clarity seems to be caused by the (svn-)revisions.

For example: the Redmine version Frank Huang is using is 0.8.5. If you checkout the source of it directly from the SVN-repo (source:/tags/0.8.5) you actually checkout the tag of 0.8.5 at revision r2886. That does not automatically mean that the checkout contains the changeset which is applied with revision r2304 since revision r2304 has been applied only to the source:/trunk.
Redmine 0.8.5 is a point-release for the current stable 0.8.x-branch (source:/branches/0.8-stable) which does not include changes scheduled for another (following) minor-release (Redmine 0.9.0). The changes for 0.9.0 are applied as said only to the source:/trunk

Hope this explains the thing a bit more...

Kind regards,

Mischa.

#31 Updated by frank huang almost 8 years ago

Mischa The Evil wrote:

frank huang wrote:

Jason van Dyk wrote:

Perhaps I've missed understood either that or I have the wrong branch revision. I'm using r2824 and I still have the problem with a sub project can not be a sub of another sub project.
...
And from what I've read r2824 coming from the main trunk should be the version 0.9 release Jean-Philippe is talking about.

Could someone advise me of what's going wrong here.

I have the same puzzle on it.
I use the version from tags/0.8.5 .but i can not find this feature.
Does it need anything else to make it .

If you are using Redmine 0.8.5 you don't have the feature since its implemented in the Redmine development version (source:/trunk a.k.a. Redmine 0.9.0) only.
The lack of clarity seems to be caused by the (svn-)revisions.

For example: the Redmine version Frank Huang is using is 0.8.5. If you checkout the source of it directly from the SVN-repo (source:/tags/0.8.5) you actually checkout the tag of 0.8.5 at revision r2886. That does not automatically mean that the checkout contains the changeset which is applied with revision r2304 since revision r2304 has been applied only to the source:/trunk.
Redmine 0.8.5 is a point-release for the current stable 0.8.x-branch (source:/branches/0.8-stable) which does not include changes scheduled for another (following) minor-release (Redmine 0.9.0). The changes for 0.9.0 are applied as said only to the source:/trunk

Hope this explains the thing a bit more...

Kind regards,

Mischa.

To Mischa~

Thank you very much.I have got it.
But there is another question that how can i make the displaying style of projects to horizontal list like before?
Because we have many projects , and the tree style will make the page scrolled .

#32 Updated by Jan Niggemann (redmine.org team member) about 4 years ago

  • Related to Feature #15290: Define subproject nesting depth limit added

Also available in: Atom PDF