Feature #630
closedAllow non-unique names for projects
0%
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
Updated by Jean-Philippe Lang almost 17 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.
Updated by Nicklas Holm almost 16 years ago
Is this planned for any coming release, or will the current behaviour be kept for now?
Updated by Ken Sands almost 16 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.
Updated by Thomas Pihl almost 16 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
Updated by Ken Sands almost 16 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.
Updated by Ken Sands almost 16 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(" » ") %> >> <% end %> <% end %> <%= h(@project && !@project.new_record? ? @project.name : Setting.app_title) %> </h1>
Updated by Jean-Philippe Lang almost 16 years ago
Updated by Nicklas Holm over 15 years ago
Is this planned for any upcoming release?
Updated by Lorenzo Pisani almost 15 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'
Updated by Holger Just over 14 years ago
The uniqueness of the project name is at least assumed in the RedmineReceivingEmails functionality.
Updated by Felix Schäfer over 14 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.
Updated by Felix Schäfer over 14 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 :-)
Updated by Jean-Philippe Lang about 14 years ago
- Status changed from New to Closed
- Resolution set to Fixed
Restriction removed in r4391.
Updated by Mischa The Evil about 5 years ago
- Related to Patch #32522: Add Project.find_by_name to target_project added