ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Hierarchical project identifiers (Feature #1092)

Added by Tomáš Jukin at 2012-07-24 10:23 am. Updated at 2012-08-20 09:25 pm.

Status:Open Start date:2012-07-24
Priority:Normal Due date:
Assignee:- % Done:


Category:Issue tracking
Target version:-
Remote issue URL: Affected version:3.1.0


Could we make generated project identifiers hierarchical?

Eg. If I have a project "Contracts" and this project has subproject "Foo Application". And I would like to add a subproject "iOS" to project "Foo Application", the generated project identifier is "ios". But it would be much more usefull if it could be eg. "contracts-foo-application-ios".

Is this possible? I use subprojects heavilly and this would save me much time for renaming project identifiers when creating them.

What do you think?

Related issues

related to Feature #662: Project path formatting Open 2011-10-16

Associated revisions

Revision a6311a96
Added by Jean-Philippe Lang at 2008-04-26 01:59 pm

Estimated time recognizes improved time formats (#1092).

git-svn-id: e93f8b46-1217-0410-a6f0-8f06a7374b81


Updated by Felix Schäfer at 2012-07-24 02:14 pm

I'm not sure if it's something that should go in the core (Holger?), but I've written a plugin for exactly that some time ago (I haven't tested it on current ChiliProject though, ping me in the GitHub Project if it doesn't work).

Updated by Holger Just at 2012-08-20 07:31 pm

I think we could adapt the automatically generated identifier to include the parent project's identifier I don't think this should be enforced on the model level right now as then the identifier would be required to change if you move the project around in the hierarchy.

After thinking a bit more, I also think this behavior should be configurable (with the default being the current behavior). I can see the use-case for both variants.

  • Priority changed from High to Normal

Updated by Tomáš Jukin at 2012-08-20 09:25 pm

I perfectly agree with you, Holger

Also available in: Atom PDF