Opened 10 years ago
Closed 10 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 , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:3 by , 10 years ago
The message is still misleading in that it references verbose_name
even for custom permissions.
comment:4 by , 10 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 , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 10 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 , 10 years ago
Separated 2 the two error cases with 2 separate error messages to help fix the issue by the developer.
comment:8 by , 10 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.