Feature #504
closed
12 character project id limitation is too short
0%
Description
Just like the limit on passwords I believe that a 12 character project id is too short. While I can understand putting
a limit on ids, something like 40 chars would still be reasonable and allow me to migrate existing projects from gforge
without renaming them. 40 chars should cover a lot of possible names, but 12 seems really short. (You can of course
choose any other limit you like ;-))
Related issues
Updated by Jean-Philippe Lang almost 17 years ago
The field is created as varchar 20 in the database.
Do you think that changing the limit from 12 to 20 is OK (this
wouldn't need a migration) ?
Updated by Nils Adermann almost 17 years ago
While 20 would suffice for my personal needs, I generally
don't like reasonless limitations ;-)
Updated by Derek Montgomery almost 17 years ago
Passwords are already not limited to 12 characters anymore.
In my opinion, 20 is short too.
You seem to have an habit of short names/ids/passwords JP :)
Make it 30+ please.
Updated by Jean-Philippe Lang almost 17 years ago
Changed from 12 to 20 in r949.
Updated by
Updated by Otavio Salvador over 16 years ago
- Status changed from Closed to Reopened
Please reconsider to change it to 30. Specially when Redmine is used inside of companies that has multiple products this is a bad and too short limit.
For example, if the company has two projects with similar names and similar subproject, it's too difficult to get up with nice names for them, example:
Foobar Manager
Foobar Manager - User Manual
Barfoo Installer
Barfoo Manager - User Manual
The most logical names would be:
foobarmanager-usermanual
barfoomanager-usermanual
This obviously doesn't fit on the limit.
This is a must, from my point of view, specially due the multi-project nature of Redmine.
Cheers,
Updated by Adam Knight over 16 years ago
I'm not sure why there's an arbitrary limit on this field. It's a varchar, so it'll only take up what space you enter on disk. There's no reason not to make this varchar(255) IMO. Anything less is just going to be a point of contention.
Updated by Otavio Salvador over 16 years ago
Adam, from database point of view you're right however there're a lot of things to worry about in views and reports.
You can't write a view without having limits for size. That's why I've asked to increase the limit instead of removing it.