Opened 11 years ago
Closed 11 years ago
#23926 closed Bug (fixed)
Misleading error message provided when custom permission names are too long
| Reported by: | Greatlemer | Owned by: | Joeri Bekker |
|---|---|---|---|
| Component: | contrib.auth | Version: | 1.7 |
| Severity: | Normal | Keywords: | |
| Cc: | Shai Berger | Triage Stage: | Ready for checkin |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
Whilst adding a new custom permission to a model, I accidentally created one that was too long and instead of being informed the problem was an overly long name field, the validation error raised complained about the verbose name of my model being too long.
This was observed in Django 1.7.1 under python 2.7.
I was able to reproduce it by putting the following code in the models.py of an application listed in INSTALLED_APPS:
from django.db.models import Model
class Tmp(Model):
class Meta:
permissions = (
(
'can_do_something_long',
'A custom permission name with greater than 50 chars',
),
)
Then when I ran ./manage.py migrate I got the following error:
(env)blah> python ./manage.py migrate
Operations to perform:
Synchronize unmigrated apps: blah
Apply all migrations: admin, contenttypes, auth, sessions
Synchronizing apps without migrations:
Creating tables...
Creating table blah_tmp
Installing custom SQL...
Installing indexes...
Running migrations:
Applying contenttypes.0001_initial... OK
Applying auth.0001_initial... OK
Applying admin.0001_initial... OK
Applying sessions.0001_initial... OK
Traceback (most recent call last):
File "./manage.py", line 10, in <module>
execute_from_command_line(sys.argv)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
utility.execute()
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/__init__.py", line 377, in execute
self.fetch_command(subcommand).run_from_argv(self.argv)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/base.py", line 288, in run_from_argv
self.execute(*args, **options.__dict__)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/base.py", line 338, in execute
output = self.handle(*args, **options)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/commands/migrate.py", line 164, in handle
emit_post_migrate_signal(created_models, self.verbosity, self.interactive, connection.alias)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/core/management/sql.py", line 268, in emit_post_migrate_signal
using=db)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 198, in send
response = receiver(signal=self, sender=sender, **named)
File "/data/home/ar/tmp/perm_issue/env/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 111, in create_permissions
verbose_name_max_length,
django.core.exceptions.ValidationError: [u'The verbose_name of tmp is longer than 39 characters']
Change History (9)
comment:1 by , 11 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:3 by , 11 years ago
The message is still misleading in that it references verbose_name even for custom permissions.
comment:4 by , 11 years ago
I'd thought for a second that the fix for #8162 fixed that too, because the test code included there uses permissions on permissions. I enjoy ironic recursion like anyone else, but it might be clearer to change that.
comment:5 by , 11 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:6 by , 11 years ago
The error is technically correct but in some cases doesn't point people to the most obvious cause. The cryptic database error mentioned in #18866 was replaced with the current message. It was an improvement but with custom permissions, the error is still cryptic.
comment:7 by , 11 years ago
Separated 2 the two error cases with 2 separate error messages to help fix the issue by the developer.
comment:8 by , 11 years ago
| Has patch: | set |
|---|---|
| Triage Stage: | Accepted → Ready for checkin |
This is actually fixed by #8162 which was fixed (only on master) by cf252dbea66d9c4a84aa1bc8da93b5e5cc759b9a. I'm not sure if we should backport.