Feature #630

Allow non-unique names for projects

Added by Robert Lemke almost 10 years ago. Updated about 7 years ago.

Status:ClosedStart date:2008-02-11
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Projects
Target version:1.1.0
Resolution:Fixed

Description

Currently project names (I'm not referring to project keys) need to be unique. However, we have the situation at forge.typo3.org that we need two projects of the same name but with different project keys.

Is there a technical reason why project names must be unique? I hacked the project name directly in the database and couldn't see any bad effect yet.


Related issues

Duplicated by Redmine - Feature #6530: Allow multiple projects with same name Closed 2010-09-29

Associated revisions

Revision 4391
Added by Jean-Philippe Lang about 7 years ago

Allow non-unique names for projects (#630).

History

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

AFAIK, there shouldn't be any side effect to have 2 projects with the same name.

This restriction was set at the very beginning to be able to identify a project by its name. I finally added the project identifier for that. I'll have a deeper look at this before I remove this restriction.

#2 Updated by Nicklas Holm almost 9 years ago

Is this planned for any coming release, or will the current behaviour be kept for now?

#3 Updated by Ken Sands almost 9 years ago

just a positive nudge for this one, it'd be great to have the restriction lifted especially for subprojects within separate parents, I think a warning if that's not the case that there is already a project with that name would be good but for subprojects it should just do a name check against other subprojects in that set.

#4 Updated by Jeff Dombach almost 9 years ago

+1

#5 Updated by Thomas Pihl almost 9 years ago

You can test this yourself (with the usual disclaimers) by editing /app/models/project.rb

Find the line that say "validates_uniqueness_of :name, :identifier"

Remove ":name, " from that line

Save and test (i assume you run this on a copy of your environment). No warnings will be given if you use a previously used name.

/T

#6 Updated by Ken Sands almost 9 years ago

Thanks, that seems to work great, now I just need to change the subprojects page heading to include the parent more clearly, I'm thinking make the title "PARENT PROJECT NAME > SUBPROJECT NAME" or something similar.

#7 Updated by Ken Sands over 8 years ago

ok understand that I picked up ruby.... err yesterday, and have little idea currently how things are done but this modification in base.rhtml achieves what I put in the above comment. I think the projects class should include a longname function which returns "[ParentName >>] [ParentName >>].... ProjectName" this would return just the project name if it was a top level or the full path otherwise (that is when more than one level of subproject is enabled) and I think would be handy to use in many situations.

    <h1>
    <% if  @project && !@project.new_record? %>
     <% if @project.ancestors.any? %>
      <%= @project.ancestors.collect {|p| link_to(h(p), :action => 'show', :id => p)}.join(" &#187; ") %> &gt&gt 
     <% end %>
    <% end %>
    <%= h(@project && !@project.new_record? ? @project.name : Setting.app_title) %>
    </h1>

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

You should have a look at #2788 and r2485.

#9 Updated by Ken Sands over 8 years ago

Jean-Philippe Lang wrote:

You should have a look at #2788 and r2485.

That's brilliant, thanks.

#10 Updated by Nicklas Holm over 8 years ago

Is this planned for any upcoming release?

#11 Updated by Lorenzo Pisani almost 8 years ago

what is the status on this? there is no reason for project names to be unique
this is especially annoying when 2 different projects need a subproject named for example 'Modules'

#12 Updated by Holger Just over 7 years ago

The uniqueness of the project name is at least assumed in the RedmineReceivingEmails functionality.

#13 Updated by Felix Schäfer over 7 years ago

Holger Just wrote:

The uniqueness of the project name is at least assumed in the RedmineReceivingEmails functionality.

As far as I can tell, the code disagrees on that, see source:trunk/app/models/mail_handler.rb#L161, the project keyword is matched against the identifier only.

I'd be in favor of dropping the uniqueness on project names too, this has become really cumbersome since the projects can be deeply nested.

#14 Updated by Felix Schäfer over 7 years ago

  • Target version set to 1.1.0

Just had a look at where the project name might be of critical importance, and I only found the [[project:page]] wiki-link scheme for which either the name or the identifier of the project are valid (see source:trunk/app/models/wiki.rb#L67 and source:trunk/app/helpers/application_helper.rb#L497, these are the two only "obvious" places, there might be other though).

This is a compatibility break, so I scheduled it for 1.1 (instead of 1.0.1), and it must be decided if we want to break this and if an upgrade path will be provided, though honestly anyone using the project name instead of the identifier in wiki-links is at the mercy of a project name change, so I'd say they're better off without it anyway :-)

#15 Updated by Andrew Sherman over 7 years ago

+1

#16 Updated by Ian DeFazio about 7 years ago

+1

#17 Updated by Albert Rosenfield about 7 years ago

+1

#18 Updated by Axel B. about 7 years ago

+1

#19 Updated by Jean-Philippe Lang about 7 years ago

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

Restriction removed in r4391.

Also available in: Atom PDF