Project

General

Profile

Actions

Feature #630

closed

Allow non-unique names for projects

Added by Robert Lemke about 16 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Projects
Target version:
Start date:
2008-02-11
Due date:
% Done:

0%

Estimated time:
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

Related to Redmine - Patch #32522: Add Project.find_by_name to target_projectNew

Actions
Has duplicate Redmine - Feature #6530: Allow multiple projects with same nameClosed2010-09-29

Actions
Actions #1

Updated by Jean-Philippe Lang about 16 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.

Actions #2

Updated by Nicklas Holm about 15 years ago

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

Actions #3

Updated by Ken Sands about 15 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.

Actions #4

Updated by Jeff Dombach about 15 years ago

+1

Actions #5

Updated by Thomas Pihl about 15 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

Actions #6

Updated by Ken Sands about 15 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.

Actions #7

Updated by Ken Sands about 15 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>
Actions #8

Updated by Jean-Philippe Lang about 15 years ago

You should have a look at #2788 and r2485.

Actions #9

Updated by Ken Sands about 15 years ago

Jean-Philippe Lang wrote:

You should have a look at #2788 and r2485.

That's brilliant, thanks.

Actions #10

Updated by Nicklas Holm about 15 years ago

Is this planned for any upcoming release?

Actions #11

Updated by Lorenzo Pisani about 14 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'

Actions #12

Updated by Holger Just over 13 years ago

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

Actions #13

Updated by Felix Schäfer over 13 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.

Actions #14

Updated by Felix Schäfer over 13 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 :-)

Actions #15

Updated by Andrew Sherman over 13 years ago

+1

Actions #16

Updated by Ian DeFazio over 13 years ago

+1

Actions #17

Updated by Albert Rosenfield over 13 years ago

+1

Actions #18

Updated by Axel B. over 13 years ago

+1

Actions #19

Updated by Jean-Philippe Lang over 13 years ago

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

Restriction removed in r4391.

Actions #20

Updated by Mischa The Evil over 4 years ago

  • Related to Patch #32522: Add Project.find_by_name to target_project added
Actions

Also available in: Atom PDF