tickets

32,817 rows sorted by summary

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: stage, severity, resolution, easy, has_patch, needs_better_patch, needs_tests, needs_docs, ui_ux, last_pulled_from_trac (date)

id created changetime last_pulled_from_trac stage status component type severity version resolution summary ▼ description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
1122 2005-12-26 21:21:35 2005-12-31 17:12:51 2022-03-06 03:22:31.263838 Unreviewed closed Core (Other) defect critical 0.90 invalid Django do not serve static binary files (e.g. images) correctly Django do not serve static binary files (e.g. images) correctly '''Solution:''' django-0.90-py2.4.egg\django\views\static.py line 52: Change line 52 from: return HttpResponse(open(fullpath, 'rb').read(), mimetype=mimetype) to: return HttpResponse(open(fullpath).read(), mimetype=mimetype) adrian hipertracker@gmail.com static files images 0 0 0 0 0 0
9623 2008-11-18 15:36:10 2008-11-18 19:26:35 2022-03-06 03:45:19.191823 Unreviewed closed Uncategorized     1.0 wontfix !ChoiceField widgets should never be empty In oder to have valid HTML always, the widgets for !ChoiceFields and its decendants, namely Select and !MultipleSelect, should never be empty. Instead, they should show some dummy selection (e.g. "---------") with empty value, which is then evaluated in the clean method to the empty list. nobody bronger   0 0 0 0 0 0
14522 2010-10-21 15:08:02 2010-11-13 19:59:23 2022-03-06 03:58:05.504405 Unreviewed closed Uncategorized     1.2 duplicate !ModelMultipleChoiceField returns list for no data submitted It should return an EmptyQuerySet nobody zmsmith   0 0 0 0 0 0
25102 2015-07-10 15:38:34 2015-07-10 15:50:49 2022-03-06 04:40:14.718036 Unreviewed closed contrib.admin Cleanup/optimization Normal 1.8 duplicate !important in admin's CSS It's hard to maintance or extend when styles contains '''!important'''. nobody ar4s styles, improvements 0 0 0 0 0 1
33127 2021-09-21 16:47:51 2021-09-24 05:41:45 2022-03-06 05:00:53.851004 Ready for checkin closed Database layer (models, ORM) Cleanup/optimization Normal 3.1 fixed "&" and "|" operators are silently ignored after QuerySet.union(), intersection(), and difference(). This looks like a similar issue to the one fixed in [https://code.djangoproject.com/ticket/27995 #27995] Example: {{{ class MyModel(models.Model): name = models.CharField() for name in ['a', 'b', 'c']: MyModel.objects.create(name=name) group1 = MyModel.objects.filter(name='a') group2 = MyModel.objects.filter(name='b') group3 = MyModel.objects.filter(name='c') combined_group = group1.union(group2) group_and = combined_group & group1 group_or = combined_group | group 3 }}} In this example, combined_group, group_and and group_or all have the same SQL. These operators should raise an exception if they can not be applied after combinator functions. hramezani MTietze   0 1 0 0 0 0
22992 2014-07-10 14:37:49 2014-07-14 17:07:08 2022-03-06 04:21:17.243551 Ready for checkin closed contrib.contenttypes Bug Release blocker 1.7-rc-1 fixed "'GenericForeignKey' object has no attribute 'get_lookup'" exception on 1.7 Current 1.7 breaks querying by content_object on a model with generic relations. {{{ >>> MonitorData.objects.get(content_object=site) Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/local/lib/python2.7/dist-packages/django/db/models/manager.py", line 92, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 345, in get clone = self.filter(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 689, in filter return self._filter_or_exclude(False, *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/django/db/models/query.py", line 707, in _filter_or_exclude clone.query.add_q(Q(*args, **kwargs)) File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1287, in add_q clause, require_inner = self._add_q(where_part, self.used_aliases) File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1314, in _add_q current_negated=current_negated, connector=connector) File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1186, in build_filter condition = self.build_lookup(lookups, col, value) File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/query.py", line 1092, in build_lookup final_lookup = lhs.get_lookup(lookup) File "/usr/local/lib/python2.7/dist-packages/django/db/models/sql/datastructures.py", line 25, in get_lookup return self.output_field.get_lookup(name) AttributeError: 'GenericForeignKey' object has no attribute 'get_lookup' }}} MonitorData looks like: {{{ from django.contrib.contenttypes.fields import GenericForeignKey, GenericRelation from django.contrib.contenttypes.models import ContentType class MonitorData(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() value = models.Posi… nobody glicerinu@gmail.com contenttypes GenericForeignKey get_lookup 0 1 0 0 0 0
22994 2014-07-10 14:45:28 2014-07-14 16:52:52 2022-03-06 04:21:22.668959 Ready for checkin closed contrib.contenttypes Bug Release blocker 1.7-rc-1 fixed "'GenericForeignKey' object has no attribute 'opts'" exception on 1.7 Django raises a "'GenericForeignKey' object has no attribute 'opts'" when using 'content_object' on a `ModelAdmin.list_display` {{{ Traceback: File "/usr/local/lib/python2.7/dist-packages/django/core/handlers/base.py" in get_response 137. response = response.render() File "/usr/local/lib/python2.7/dist-packages/django/template/response.py" in render 103. self.content = self.rendered_content File "/usr/local/lib/python2.7/dist-packages/django/template/response.py" in rendered_content 80. content = template.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/base.py" in render 148. return self._render(context) File "/usr/local/lib/python2.7/dist-packages/django/test/utils.py" in instrumented_test_render 88. return self.nodelist.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/base.py" in render 844. bit = self.render_node(node, context) File "/usr/local/lib/python2.7/dist-packages/django/template/debug.py" in render_node 80. return node.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/loader_tags.py" in render 126. return compiled_parent._render(context) File "/usr/local/lib/python2.7/dist-packages/django/test/utils.py" in instrumented_test_render 88. return self.nodelist.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/base.py" in render 844. bit = self.render_node(node, context) File "/usr/local/lib/python2.7/dist-packages/django/template/debug.py" in render_node 80. return node.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/loader_tags.py" in render 126. return compiled_parent._render(context) File "/usr/local/lib/python2.7/dist-packages/django/test/utils.py" in instrumented_test_render 88. return self.nodelist.render(context) File "/usr/local/lib/python2.7/dist-packages/django/template/… Tim Graham <timograham@gmail.com> glicerinu@gmail.com GenericForeignKey content_object opts list_display 0 1 0 0 0 0
25292 2015-08-19 15:00:02 2016-06-30 12:57:27 2022-03-06 04:40:43.011461 Accepted closed Core (System checks) Bug Normal 1.8 fixed "'str' object has no attribute '_meta'" crash in ManyToManyField.through_fields check '''version 1.8 doesn't handle an error properly in ManyToManyField.through_fields and gives useless feedback when performing system checks''' I made a typo in defining a many to many through field in a model. See below. In my ManyToManyField.through_field for "Stage" I have "StageCatgeory" which is not correct the e and g are backwards. See the stack trace below when running in v 1.8.4. it provides this useless info... '''AttributeError: 'str' object has no attribute '_meta'.''' It wasn't until I tried running my app in 1.7.10, stack trace also below, that I got useful feedback on the problem and was able to solve it. '''Field specifies a many-to-many relation through model 'StageCatgeory', which has not been installed.''' This seems like a bug that 1.7 handled it and 1.8 did not. {{{ class Stage(models.Model): stage_id = models.AutoField(primary_key=True) categories = models.ManyToManyField('Category', through='StageCatgeory', related_name="stage_category") class StageCategory(models.Model): stage = models.ForeignKey('Stage', db_column='stage_id') category = models.ForeignKey('Category', db_column='category_id') class Category(models.Model): category_id = models.AutoField(primary_key=True) stage = models.ManyToManyField('Stage', through='StageCategory', related_name="stage_category") }}} {{{ Django version 1.8.4, using settings 'my.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Performing system checks... Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x102cbad90> Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/django/utils/autoreload.py", line 225, in wrapper fn(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/django/core/management/commands/runserver.py", line 110, in inner_run self.validate(display_num_errors=T… nobody thbarrons   1 0 0 0 0 0
13175 2010-03-22 01:53:08 2011-09-28 16:12:23 2022-03-06 03:54:28.236282 Accepted closed contrib.admin     dev fixed "+ Add another [...]" bug with final_attrs['id'] When adding a new inline in the admin through "+ Add another [...]" the id of the inputs is different from what final_attrs.id says it should be. For example when rendering a widget that prints final_attrs.id I get {{{ id_sponsor_set-4-logo }}} but actually the id is {{{ id_sponsor_set-3-logo }}} To make this clear (can't express myself clearly) you can try changing line 218 from django/forms/widgets.py to {{{ 212 def render(self, name, value, attrs=None): 213 if value is None: value = '' 214 final_attrs = self.build_attrs(attrs, type=self.input_type, name=name) 215 if value != '': 216 # Only add the 'value' attribute if a value is non-empty. 217 final_attrs['value'] = force_unicode(formats.localize_input(value)) 218 return mark_safe(u'<input%s />' % flatatt(final_attrs)) 218 return mark_safe(u'expected id: %s <input%s />' % (final_attrs['id'], flatatt(final_attrs))) }}} and add a new inline through the link and check what's been printed with the id of an input inside the newly created inline This small changes breaks many 3rd party apps. DrMeers rasca inline javascript 0 1 0 0 0 0
29348 2018-04-21 03:26:41 2018-04-21 08:10:46 2022-03-06 04:51:00.732295 Unreviewed closed Internationalization Cleanup/optimization Normal 2.0 invalid "-" and "_" in language code should be consistent for some languages eg, en-us hyphen is used but in zh_hans underscore is used. If zh-hans is used, django would not show the translation. Here's some tests and resutls Language code: zh_hans, folder zh_hans -> works Language code: zh_hans, folder zh-hans -> ` No translation files found for default language zh_hans.` Language code: zh-hans, folder zh-hans -> does not work. No errors, no translations Language code: zh-hans, folder zh_hans -> does not work. No erros, no translations looks like django does not treat zh-hans as a valid language code, which is very very confusing because the default en-us is valid. It look me a very long time to figure this out. Edit: even zh_hans is not working with browser language detection, the folder has to be named 'zh_Hans' even though request.LANGUAGE is 'zh-hans' is there somether in the doc that pointed this out? nobody ericls i18n, inconsistency 0 0 0 0 0 0
24513 2015-03-20 13:59:34 2015-04-07 13:27:39 2022-03-06 04:27:51.870337 Ready for checkin closed Migrations Bug Release blocker 1.8 fixed "... has no field named None" with M2MField when migrating In Django 1.8c1 migrations from scratch don't work for me anymore, this effectively prevents testing. (When you see project I'm talking about an app, btw) See file traceback.txt for a test-call and a backtrace. See file 0011_auto_20140914_2032.py for the migration that failed. And see file user_model.py for the model that should be migrated. --- I can't provide much code sadly. I tried to simplify my big project, but I can't get it done without disclosing half of my product (or it would take me days to do so …). Instead I did a git-bisect to get the commit that makes my migrations fail: {{{ (testenv)kondou:django/ (4e9ecfe) $ git bisect good a1ba4627931591b80afa46e38e261f354151d91a is the first bad commit commit a1ba4627931591b80afa46e38e261f354151d91a Author: Markus Holtermann <info@markusholtermann.eu> Date: Mon Feb 9 01:11:25 2015 +0100 [1.8.x] Fixed #24225, #24264, #24282 -- Rewrote model reloading in migration project state Instead of naively reloading only directly related models (FK, O2O, M2M relationship) the project state needs to reload their relations as well as the model changes as well. Furthermore inheriting models (and super models) need to be reloaded in order to keep inherited fields in sync. To prevent endless recursive calls an iterative approach is taken. Backport of b29f3b51204d53c1c8745966476543d068c173a2 from master :040000 040000 2faa54b906f309ddb353a73abbef7db950b18d1c 2eb05be062be72e8a8f4d54961fbe3ec96d0edf1 M django }}} Doing a git revert a1ba4627931591b80afa46e38e261f354151d91a on 1.8c1 tag indeed fixes this problem for me. nobody Kondou-ger migrations, bug 0 1 0 0 0 0
26492 2016-04-11 20:10:15 2016-04-12 13:03:25 2022-03-06 04:44:01.482678 Ready for checkin closed Migrations Bug Release blocker dev fixed "./manage.py migrate" causes "maximum recursion depth exceeded" error With the latest master (`0247c9b08f8da4a2d93b9cede6c615011552b55a`), I'm getting the following exception: {{{ [snipped] File "/home/berker/projects/django/django/core/management/commands/migrate.py", line 62, in _run_checks issues.extend(super(Command, self).check(**kwargs)) File "/home/berker/projects/django/django/core/management/base.py", line 385, in check include_deployment_checks=include_deployment_checks, File "/home/berker/projects/django/django/core/management/commands/migrate.py", line 61, in _run_checks issues = run_checks(tags=[Tags.database]) File "/home/berker/projects/django/django/core/checks/registry.py", line 81, in run_checks new_errors = check(app_configs=app_configs) File "/home/berker/projects/django/django/core/checks/database.py", line 9, in check_database_backends for conn in connections.all(): File "/home/berker/projects/django/django/db/utils.py", line 226, in all return [self[alias] for alias in self] RuntimeError: maximum recursion depth exceeded }}} I created a sample project to demonstrate the bug: https://bitbucket.org/berkerpeksag/django-bug You can see the full output of `./manage.py migrate` at https://bitbucket.org/berkerpeksag/django-bug/src/b527f36d15c4e68168621dd39db164a8beaf905e/tdj/log.txt?at=master&fileviewer=file-view-default The project is simple. I only created a model: https://bitbucket.org/berkerpeksag/django-bug/src/b527f36d15c4e68168621dd39db164a8beaf905e/tdj/polls/models.py?at=master&fileviewer=file-view-default I believe the cause of the issue is at https://github.com/django/django/commit/0d3c616fbb2f49fa7ff6809e5a6777275352b35b#diff-e835ddfb52774b39749788a0d046e477R62 If I replace line 62 with {{{ issues.extend(super(Command, self)._run_checks(**kwargs)) }}} it works as expected. berkerpeksag berkerpeksag   0 1 0 0 0 0
562 2005-09-26 21:08:56 2007-09-16 11:30:03 2022-03-06 03:21:04.345138 Accepted closed contrib.admin defect normal   wontfix "Add another" JavaScript doesn't add new value to all fields relating to the same type Suppose we have a model containing two fields: {{{ class Foo(meta.Model): field1 = meta.ForeignKey(Bar) field2 = meta.ForeignKey(Bar) ... }}} The admin interface generates "Add another" links next to the dropdowns. If the link next to field1 is clicked, and a new value is added, then the new value only appears in the field1 dropdown and not in the dropdown for field2. This is also seen in "Add another" links next to edit_line fields. nobody Esaj   0 0 0 0 0 0
20 2005-07-13 19:32:17 2007-07-03 23:03:44 2022-03-06 03:19:28.799681 Ready for checkin closed contrib.admin enhancement normal   duplicate "Add another" for many-to-many relationships Django already creates an "Add another..." link in one-to-many select boxes. (Example: The "place" select box on the "Add event" admin page has an "Add another..." link at the bottom of it.) Many-to-many fields -- represented in the admin as multi-select boxes -- also need "Add another..." capability. It could probably appear as the last entry in the select box, as in the one-to-many add-anothers. adrian adrian   0 0 0 0 0 0
13644 2010-05-27 22:39:43 2010-05-28 09:36:37 2022-03-06 03:55:46.337487 Unreviewed closed contrib.admin     1.2 invalid "Add another" link doesn't appear in Inlines with many-to-many I have created a model Offer with one-to-many Option fields (ie. Option model has ForeignKey to Offer). Option contained a ForeignKey to Accomodation. Then, I made the Admin for Offer with inline of Option. Everything worked fine and the "Add another" link appeared. Then, I had a note from my customer, who asked me to make Accomodation as many-to-many with Option. But then, the "Add another" disappeared". nobody mateusz.haligowski@nostromolabs.pl admin inline 0 0 0 0 0 0
25903 2015-12-09 18:09:38 2015-12-21 14:30:46 2022-03-06 04:42:31.771440 Ready for checkin closed contrib.admin Bug Release blocker 1.9 fixed "Add another" related field buttons in list_editable don't open a popup I am referring to the popups you can use to creare a new record on-the-fly while editing an other record. After upgrade from Django 1.7 to 1.9 those popups aren't opening a popup in the web browser anymore, instead, the page will change, allowing to create a new record. After saving, a page saying "Closing Popup" will appear, but the page won't go back to the original one. timgraham Cuuuurzel modeladmin popup 0 1 0 0 0 0
32247 2020-12-06 13:04:51 2020-12-07 06:06:27 2022-03-06 04:58:41.444419 Unreviewed closed Error reporting Cleanup/optimization Normal 3.1 invalid "App does not have migrations" message could be more helpful It has happened to me and probably many many others several times that running {{{ manage.py migrate SOME_APP }}} would yield an error like {{{ CommandError: App 'SOME_APP' does not have migrations. }}} all while a migrations folder with migrations *does exist* in the specified app. It is often the case that the cause of the issue is simply that the `__init__.py` file is missing from the directory, but that is not at all apparent. Even running {{{ manage.py showmigrations SOME_APP }}} is unhelpful and unless the programmer is specifically aware of this potential issue (and even then it's easy to forget) the problem can be confusing to solve. I propose a simple change of the error message to: {{{ CommandError: No migration detected for app 'SOME_APP'. Is an '__init__.py' file present in the 'migrations/' directory? }}} Or something to the same effect.   berzi documentation, errors, error messages 1 0 0 0 0 0
33013 2021-08-11 11:00:01 2021-08-17 07:29:37 2022-03-06 05:00:36.727132 Unreviewed closed Core (Other) Bug Normal 3.2 wontfix "AppConfig" subclass imports found in Django 3.2's automatic "AppConfig" discovery We are in the process of adding support for Django 3.2 to [https://github.com/django-oscar/django-oscar Oscar]. Oscar [https://github.com/django-oscar/django-oscar/blob/04dd391c900537a61dbb0ae5250ca5c2df6bbc4b/src/oscar/core/application.py#L139 mixes in] its apps' configurations into Django's `AppConfig` class, and developers using Oscar then subclass these, to make their own modifications: {{{ # my_app/apps.py from oscar.core.application import OscarConfig class MyAppConfig(OscarConfig): # my app modifications }}} With Django 3.2, for apps added to `INSTALLED_APPS` using the dotted Python path to the app package, Django finds all `AppConfig` subclasses in the `apps.py` (using [https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e#diff-0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R110-R120 Python's] `inspect.getmembers`), including ones imported to be subclassed. `django.apps.config.AppConfig` itself does get excluded, but this is not sufficient, as we and the developers using Oscar do a lot of sub classing of these classes. To solve this, we would have have to do: {{{ # my_app/apps.py from oscar.core import application class MyAppConfig(application.OscarConfig): # my app modifications }}} And then ask the developers using Oscar to also do the same. The problem with this is: - it is not intuitive - Python developers would not typically expect imports to cause side effects like this, which creates the potential for confusing and hard-to-debug issues - it is flaky - a new developer may innocently refactor imports not realising why they were done that way, and then encounter the confusing issues - explicit class imports are normally preferred in Python, unless they cause local name clashes, so requiring them for this reason is a bit odd - Django itself [https://github.com/django/django/commit/3f2821af6bc48fa8e7970c1ce27bc54c3172545e#diff-0f8bc657bc27c9f80385c4814c2c2ebc033bda3e03285a7212965309a481cc70R110-R120 does a check] to exclude… nobody jwayodi   0 0 0 0 0 0
20262 2013-04-15 11:40:20 2013-04-15 20:29:59 2022-03-06 04:13:27.376036 Ready for checkin closed Documentation Bug Normal 1.4 fixed "Article" in the note should be "Author" There's a note in the beginning of the generic editing views page (https://docs.djangoproject.com/en/dev/ref/class-based-views/generic-editing/) that reads as follows: {{{ Some of the examples on this page assume that an Article model has been defined as follows in myapp/models.py: ... class Author(models.Model): ... }}} The "Article" should probably be "Author", since the model's name in the note and in following examples is "Author". mossplix anonymous   1 1 0 0 0 0
19675 2013-01-27 22:55:07 2013-02-23 16:10:13 2022-03-06 04:11:55.184209 Ready for checkin closed Documentation Cleanup/optimization Normal 1.4 fixed "At A Glance" does not say where to put "sitelogo.gif" This is non-trivial, and needs to be briefly mentioned -- MEDIA_ROOT? STATIC_ROOT? A STATICFILES_DIRS entry? Does it have to be listed in "urls.py"? anonymous anonymous   0 0 0 0 0 0
31678 2020-06-08 06:54:59 2020-06-08 07:02:24 2022-03-06 04:57:16.242331 Unreviewed closed Database layer (models, ORM) Bug Normal 3.0 duplicate "AttributeError: 'ManyToOneRel' object has no attribute 'select_format'" fails in 3.0.7 When upgrading to 3.0.7 my CI fails with the following stacktrace in my unit tests. When reverting back to 3.0.6 there is no error, which seems weird (as 3.0.7 is just a security update). I am not sure what other information is needed. Due to the nature of the stacktrace, it is difficult for me to know exactly what field is causing this failure, but it is happening on my custom User class. https://gist.github.com/C0DK/12df9ec3ab67fd238e27b0a949a05fc8 The exact cause is unknown to me, so i am not to much help, but can gladly answer questions of any nature. nobody C0DK   0 0 0 0 0 0
25424 2015-09-18 00:29:17 2015-09-19 13:02:04 2022-03-06 04:41:08.298610 Accepted closed Testing framework Bug Normal 1.8 fixed "AttributeError: '__proxy__' object has no attribute 'decode'" using reverse_lazy in test client This is basically the same as [https://code.djangoproject.com/ticket/18776 this bug], just starting from the test client. The relevant stack trace: {{{ Traceback (most recent call last): File "$SRC/tests/test_planner.py", line 49, r = self.client.get(reverse_lazy('generator')) File "$HOME/venvs/webapp/lib/python3.4/site-packages/django/test/client.py", line 500, in get **extra) File "$HOME/venvs/webapp/lib/python3.4/site-packages/django/test/client.py", line 303, in get return self.generic('GET', path, secure=secure, **r) File "$HOME/venvs/webapp/lib/python3.4/site-packages/django/test/client.py", line 357, in generic parsed = urlparse(path) File "$HOME/.pythonz/pythons/CPython-3.4.3/lib/python3.4/urllib/parse.py", line 292, in urlparse url, scheme, _coerce_result = _coerce_args(url, scheme) File "$HOME/.pythonz/pythons/CPython-3.4.3/lib/python3.4/urllib/parse.py", line 112, in _coerce_args return _decode_args(args) + (_encode_result,) File "$HOME/.pythonz/pythons/CPython-3.4.3/lib/python3.4/urllib/parse.py", line 96, in _decode_args return tuple(x.decode(encoding, errors) if x else '' for x in args) AttributeError: '__proxy__' object has no attribute 'decode' }}} SoftwareMaven SoftwareMaven   0 1 0 0 0 0
13872 2010-07-02 21:34:48 2010-07-06 22:01:42 2022-03-06 03:56:24.422620 Unreviewed closed contrib.admin     1.2 worksforme "AttributeError: 'module' object has no attribute 'day_abbr'" when using Admin to add instance of model with DateField, TimeField, or DateTimeField I'm running Django 1.2.1 on Python 2.5.4 Whenever I try to add a new instance of a model that contains one of either DateTimeField, DateField, or TimeField, I get "AttributeError: 'module' object has no attribute 'day_abbr'" I have a feeling it's related to [http://code.djangoproject.com/ticket/13560] but I'm not sure. Here are my models. Adding a Baz works just fine, but adding a Bar causes the exception: {{{ from django.db import models class Bar(models.Model): name = models.TextField() publish_date = models.DateTimeField() class Baz(models.Model): name = models.CharField(max_length = 10) age = models.IntegerField() }}} And a traceback: {{{ Environment: Request Method: POST Request URL: http://localhost:8000/admin/foo/bar/add/ Django Version: 1.2.1 Python Version: 2.5.4 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.admin', 'foobar.foo'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware') Traceback: File "C:\Python25\Lib\site-packages\django\core\handlers\base.py" in get_response 100. response = callback(request, *callback_args, **callback_kwargs) File "C:\Python25\Lib\site-packages\django\contrib\admin\options.py" in wrapper 239. return self.admin_site.admin_view(view)(*args, **kwargs) File "C:\Python25\Lib\site-packages\django\utils\decorators.py" in _wrapped_view 76. response = view_func(request, *args, **kwargs) File "C:\Python25\Lib\site-packages\django\views\decorators\cache.py" in _wrapped_view_func 69. response = view_func(request, *args, **kwargs) File "C:\Python25\Lib\site-packages\django\contrib\admin\sites.py" i… nobody Lexo attributeerror module day_abbr strptime datefield datetime datetimefield timefield admin 0 0 0 0 0 0
30492 2019-05-20 11:54:08 2019-05-20 11:59:47 2022-03-06 04:54:04.779944 Unreviewed closed Template system Bug Normal 2.2 invalid "B" seen as time-related format specifier. I have currently set DATE_FORMAT = "d B Y" in my project settings. If I try to run it like this, I get the following TypeError: The format for date objects may not contain time-related format specifiers (found 'B') However, it works with 'b' Any clue why this is happening? nobody RaduNicoara date, datetime, format, template 0 0 0 0 0 0
32300 2020-12-27 11:02:05 2020-12-27 17:56:48 2022-03-06 04:58:48.134873 Unreviewed closed Database layer (models, ORM) Bug Normal 3.1 wontfix "BIGINT UNSIGNED value is out of range" occurs when substraction operation between PositiveBigIntegerField and BigIntegerField using F() * Environment {{{ MacOS 10.15.3 Django 3.1 MySQL 5.7.32 mysqlclient==2.0.1 }}} * Model {{{ class SomeModel(models.Model): positive_big_int_column = models.PositiveBigIntegerField(default=0) big_int_column = models.BigIntegerField(default=0) }}} * Test {{{ SomeModel.objects.create(positive_big_int_column=100, big_int_column=300) qs = SomeModel.objects.filter(positive_big_int_column=100) qs.update(big_int_column=F('positive_big_int_column') - F('big_int_column')) }}} * Expected query UPDATE SomeModel SET big_int_column=(100-300) * Error IntegrityError: (1690, "BIGINT UNSIGNED value is out of range in blabla") nobody jun318zz mysql unsigned 0 0 0 0 0 0
11359 2009-06-24 00:36:07 2009-09-12 23:06:24 2022-03-06 03:49:44.447760 Ready for checkin closed Documentation     dev fixed "Built-in signals" API reference doc fails to mention "Signals" documentation. There is a "See also" section at the top of the Signals API reference which includes a link to documentation of signals in the comments app, but no "see also" describing how to use signals. Add a link to the "Using Django" > "Signals" document in the "See also" section, probably with text similar to what is seen in the comments signals reference: {{{ See the introduction to signals for information about how to register for and receive these signals. }}} nobody tyson signals documentation 0 0 0 0 0 0
17963 2012-03-23 17:38:58 2012-03-29 15:07:10 2022-03-06 04:07:17.382014 Accepted closed Documentation Bug Normal 1.4-rc-2 fixed "Bulk Insert" link from 1.4 release notes broken https://docs.djangoproject.com/en/dev/releases/1.4/#backwards-incompatible-changes-in-1-4 "bulk insert" in the first bullet point of Overview points to: https://docs.djangoproject.com/en/dev/releases/1.4/Model.objects.bulk_createintheORM/ Which currently is "Page not found" nobody anonymous   1 0 0 0 0 0
28833 2017-11-22 22:51:28 2018-02-06 15:00:53 2022-03-06 04:49:43.446387 Accepted closed HTTP handling Cleanup/optimization Normal 1.8 fixed "Cache-Control: private" responses should not be cached by server If the "Cache-Control: private" directive is set on a response, it must not be stored in a shared cache. Django's serverside caching system is a shared cache, but stores such responses anyway. A response such as {{{ Cache-Control: private Content-Type: text/plain Here is your own special random number: 42 }}} should be cacheable only by the user's own browser [more or less], but Django currently reuses the response for subsequent requests from ''anyone''. Some workarounds might be: * use @never_cache or similar to ensure a max-age of 0 which **is** respected by the cache middleware, but also prevents the users own private cache from storing * make sure the response varies on something private to the user (i.e. `Vary: Cookie`) in which case the entry will still be stored in a shared — but now less accessible — manner shangdahao natevw   0 1 0 0 0 0
8849 2008-09-03 17:43:55 2008-09-03 20:55:07 2022-03-06 03:43:19.623812 Unreviewed closed Documentation     dev fixed "Changed|New in Django development version" and version*:: 1.0 fixes See atacjed patch nobody ramiro   0 1 0 0 0 0
31597 2020-05-16 19:16:33 2020-05-20 19:36:03 2022-03-06 04:57:03.389832 Ready for checkin closed contrib.admin Bug Release blocker 3.1 fixed "Clear all filters" link removes TO_FIELD_VAR and is always displayed in raw_id_fields popup. The new "Clear all filters" link does not play nice with `raw_id_fields` lookup popup window. The new link is shown in the popup regardless of any filters being selected or not. Present in `3.1a1`. To reproduce: * create two models, `ModelA` and `ModelB` * create a Foreign key field on `ModelA` pointing to `ModelB` * create a boolean field on `ModelB` * create an admin page for `ModelA` * add the FK field to `raw_id_fields` list * create an admin page for `ModelB` * add the boolean field to `list_filter` list * open the admin page in a browser * click on the "magnifying class" icon for the `ModelB` field * expected: * no `X Clear all filters` link * actual: * yes `X Clear all filters` link Additionally, clicking the link removes `_to_field` query param, which it should not do (`_popup` param is correctly preserved). [[Image(clearallfiltersrawidfields.jpg)]] frnhr frnhr   0 1 0 0 0 1
31603 2020-05-18 14:14:35 2020-05-20 19:36:03 2022-03-06 04:57:04.237196 Ready for checkin closed contrib.admin Bug Release blocker 3.1 fixed "Clear all filters" link removes ordering and search criteria. "Clear all filters" link removes ordering and search criteria, it should clear only filters. It is a new feature added in Django 3.1 (see #27888 and b94764e178056a2118eff3f53f567207219e737d. [https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!topic/django-developers/zrQSMqJsnRQ Discussion on the mailing list]. Thanks Fran Hrženjak for the report. nobody felixxm   0 1 0 0 0 0
679 2005-10-22 03:54:32 2006-10-07 21:56:27 2022-03-06 03:21:24.233839 Unreviewed closed contrib.admin defect normal   fixed "Collapse" class not processed correctly in admin interface When specifying a number of fieldsets in the meta.Admin constructor (the fields parameter), an entry of "classes": "collapse" is only correctly handled (i.e. the Javascript support is only included) for the first tuple in the list. The attached patch fixes this. adrian malcolm@pointy-stick.com   0 0 0 0 0 0
6538 2008-02-03 06:07:17 2008-03-18 19:55:21 2022-03-06 03:37:23.825687 Unreviewed closed contrib.syndication     dev invalid "Complex" Syndication Example Error? Following the example at: http://www.djangoproject.com/documentation/syndication_feeds/#a-complex-example I've arrived at the following: {{{ class BpostCatPosts(Feed): """ Shows the latest blog posts from an individual blog post category. """ def get_object(self, bits): # In case of "/feeds/bpcatposts/0613/foo/bar/baz/", or other such clutter, # check that bits has only one member. if len(bits) != 1: raise ObjectDoesNotExist return BlogCategory.objects.get(id__exact=2) def title(self, obj): return "Greg Taylor's Latest: %s" % obj.name def link(self, obj): if not obj: raise FeedDoesNotExist return obj.get_absolute_url() def description(self, obj): return "The latest posts from the %s category of Greg Taylor's blog." % obj.name def items(self, obj): return BlogPost.objects.filter(category=[obj.id])[:10] }}} My feed section of urls.py looks like this: {{{ feeds = { 'latest_bpost': LatestBposts, 'latest_bpostcat': BpostCatPosts, } urlpatterns = patterns('', # Serve Media via Django (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}), # Default Page (r'^', include('apps.pages.urls')), # Standard Pages (r'^pages/', include('apps.pages.urls')), # Blog URLs (r'^blog/', include('apps.blog.urls')), # Django Admin Interface (r'^admin/', include('django.contrib.admin.urls')), # RSS Feeds (r'^feeds/(?P<url>.*)/$', 'django.contrib.syndication.views.feed', {'feed_dict': feeds}), ) }}} When visiting the URL http://localhost:8000/feeds/latest_bpostcat/2/ I am getting the following error: {{{ InterfaceError at /feeds/latest_bpostcat/2/ Error binding parameter 0 - probably unsupported type. }}} I've looked over this quite a few times and can't figure out if the API has changed or if there was an omission. I've tr… nobody gtaylor@clemson.edu rss, syndication 0 0 0 0 0 0
16377 2011-06-29 22:41:43 2011-07-29 09:40:43 2022-03-06 04:03:03.882698 Ready for checkin closed Documentation Cleanup/optimization Normal 1.3 fixed "Conditionally disabling actions" documentation needs updating The docs in question are: https://docs.djangoproject.com/en/1.3/ref/contrib/admin/actions/#conditionally-enabling-or-disabling-actions The suggestion is to use `del actions['delete_selected']`, which worked fine in Django 1.2. However, because of changes made to `django.contrib.admin.options.get_actions`, in the case that `IS_POPUP_VAR == True`, this del statement will result in an exception. Need a try/except or something. nobody pgullekson@baycitizen.org   1 1 0 0 0 0
28351 2017-06-30 13:02:55 2017-08-13 01:00:32 2022-03-06 04:48:31.134834 Accepted closed Migrations Bug Normal 1.11 needsinfo "Conflicting migrations detected" CommandError due to replacement Migration being removed I am getting the following error: {{{ CommandError: Conflicting migrations detected; multiple leaf nodes in the migration graph: (0002_initial_models, 0XXX_merge_20170628_1435 in myapp). To fix them run 'python manage.py makemigrations --merge' }}} Running the command results in `No conflicts detected to merge.` however. `0002_initial_models` is not actually a leaf node, but `0003_initial_data` depends on it. `0003_initial_data` however is removed, since it replaces `0XXX_merge_20170628_1435`, which is not applied yet and therefore also does not show up in `showmigrations`?! (it gets removed in https://github.com/django/django/blob/a6756195c1a11eee10c16c96fe95d52e22e1d9ba/django/db/migrations/graph.py#L252) I think `0003_initial_data` should still show up in `showmigrations`, but with some indication that it replaces other migrations. That would happen in case it wasn't removed as a leaf node in https://github.com/django/django/blob/a6756195c1a11eee10c16c96fe95d52e22e1d9ba/django/core/management/commands/showmigrations.py#L82-L83. Windsooon blueyed   0 0 0 0 0 0
25047 2015-07-02 12:20:04 2015-08-24 12:01:43 2022-03-06 04:39:52.166118 Ready for checkin closed Migrations Cleanup/optimization Normal 1.8 fixed "Conflicting migrations detected" error in makemigrations is rather unhelpful If you run makemigrations and have more than one migration which no other migration depend upon (a leaf in the dependency graph), you will get the following error {{{ Conflicting migrations detected [0001_migration_a, 0002_migration_b]. To fix them run python manage.py makemigrations --merge }}} I believe that it is hard to find the cause of this error without looking at the implementation of the checker (https://github.com/django/django/blob/bc77eb6d0858652e197c08c299efaeb06c51efee/django/db/migrations/loader.py#L325). I suggest that we change "Conflicting migrations detected" to something like "There can only be one migration which are not depended upon by another migration". I would be happy to submit a PR. mossplix nip3o   1 1 0 0 0 0
22280 2014-03-16 23:26:36 2014-10-20 14:13:27 2022-03-06 04:18:36.679452 Accepted closed Testing framework Bug Normal dev worksforme "Conflicting models in application" RuntimeError for same model with different paths When I run tests using `manage.py test`, the test file `project/app/tests.py` is used/imported with `__name__ = "project.project.app.test"`. When using a relative import in tests.py then, the model appears to get registered as `project.project.app.model`. After the database for the tests is being setup, I get the following error: > RuntimeError: Conflicting 'model' models in application 'app': <class 'app.models.Model'> and <class 'project.project.app.models.Model'>. It refers to the same Model, but with different class paths. This is triggered by / caused when using an relative import from the tests.py file: `from .models import Model`. I am running manage.py from the first "project" directory. `sys.path` contains the directory `.../project/project` and not the directory where `project.project.app` would be rooted. With Django 1.6 the `__name__` of tests.py during the import is the same, but there's no error, since there is no apploader that verifies uniqueness using the labels/names. I could not reproduce it with a simple new project/app in Django 1.7. {{{ ERROR: project.project.app.tests (unittest.loader.ModuleImportFailure) ---------------------------------------------------------------------- ImportError: Failed to import test module: project.project.app.tests Traceback (most recent call last): File "/usr/lib/python2.7/unittest/loader.py", line 254, in _find_tests module = self._get_module_from_name(name) File "/usr/lib/python2.7/unittest/loader.py", line 232, in _get_module_from_name __import__(name) File "…/project/app/tests.py", line 23, in <module> from .views import HomePageView File "…/project/app/views.py", line 6, in <module> from .models import Movie, Collection File "…/project/app/models.py", line 51, in <module> class Person(models.Model): File "…/django-master/django/db/models/base.py", line 299, in __new__ new_class._meta.apps.register_model(new_class._meta.app_label, new_class) File "…/django-master/django/apps… nobody blueyed   0 0 0 0 0 0
15496 2011-02-25 04:40:33 2012-02-18 10:11:17 2022-03-06 04:00:42.566828 Ready for checkin closed HTTP handling Bug Normal dev fixed "Content-Transfer-Encoding: base64" not honored when uploading files When the client POST-s a file in base64 encoding, Django does not decode the file correctly. == How to Repeat == Upload a file to a Django view in an HTML form with method="POST" and enctype="multipart/form-data"; inside the MIME part for the file, encode the body in base64 and indicate the encoding in the Content-Transfer-Encoding: header. == Expected Result == The uploaded file, when examined on disk, is decoded (by Django). == Actual Result == The uploaded file, when examined on disk, is still base64-encoded. == Analysis == In module {{{django.http.multipartparser}}}, {{{MultiPartParser.parse()}}} iterates over each part as returned by a {{{Parser}}} object. The {{{Parser}}} object yields a header dictionary, which {{{MultiPartParser.parse()}}} captures in {{{meta_data}}}. {{{parse()}}} then fetches the Content-Transfer-Encoding header from {{{meta_data}}} into {{{transfer_encoding}}}. {{{transfer_encoding}}}, as returned by {{{meta_data.get()}}}, is not simply a string such as {{{'base64'}}} but really a 2-tuple (value, params). Also, the header value (the first element of the returned tuple) is not whitespace-trimmed. As a result, if the part contained {{{'Content-Transfer-Encoding: base64'}}}, {{{meta_data.get('Content-Transfer-Encoding')}}} does not return just {{{'base64'}}} but a 2-tuple {{{(' base64', {})}}}: * The header has no parameters, hence an empty parameter dictionary; * The value portion retains the leading space, right after the colon (:) in the raw header. {{{parse()}}} needs the whitespace-trimmed version of the first element of the tuple; the attached patch converts the returned tuple into the string. nobody gene@nttmcl.com base64 file upload 0 1 0 0 0 0
8731 2008-08-31 16:13:58 2011-09-28 16:12:17 2022-03-06 03:43:01.553935 Ready for checkin closed Translations     dev fixed "Days" translation in french could be better The "days" translation in french is "journées", so when using the timesince tag it gives something like "1 mois, 2 journées", instead of "1 mois, 2 jours". The attached patch simply replaces the translation "day" => "journée" into "day" => "jour" (same thing for the plural form) for the fr locale. nobody Sephi fr, french, days, journées, jours, i18n, locale 0 1 0 0 0 0
11172 2009-05-21 18:08:20 2009-05-22 02:02:30 2022-03-06 03:49:17.502905 Unreviewed closed Documentation     dev duplicate "Decoupling the URLconfs" isn't exactly true http://docs.djangoproject.com/en/dev/intro/tutorial03/#intro-tutorial03 - the part about decoupling is not entirely right. During previous steps user put templates for polls app into global template directory. To make sure polls is fully decoupled, we should have put the templates in app's template directory. nobody yacoob   0 0 0 0 0 0
21365 2013-11-02 00:36:21 2013-11-02 01:33:38 2022-03-06 04:16:17.014980 Unreviewed closed Documentation Cleanup/optimization Normal dev fixed "Dependent" is misspelled in i18n/translation In the "Note on performance" section of the JavaScript i18n engine documentation, "version-dependent" is misspelled as "version-dependant". nobody awilcox@wilcox-tech.com   0 1 0 0 0 0
16740 2011-09-01 14:24:40 2011-09-28 16:12:30 2022-03-06 04:04:01.061849 Unreviewed closed Database layer (models, ORM) New feature Normal 1.3 invalid "Derived Class" A feature you can create derived classes. For example: {{{ Class ClassA(models.Model): name = models.CharField() age = models.IntergerField() class ClassB(models.Model): serial = models.CharField() class DerivedClass(models.Model): class Meta: derived = (ClassA, ClassB) name = models.CharField(derived = ClassA, attr = name) serial = models.CharField(derived = ClassB, attr = serial) }}} nobody anonymous Derived class, models 0 0 0 0 0 0
15072 2011-01-13 14:22:21 2011-01-13 15:30:39 2022-03-06 03:59:33.232871 Unreviewed closed Uncategorized     1.2 duplicate "Displaying a form using a template" section should containt {% csrf_token %} since the form posting fails lacking this template tag... http://docs.djangoproject.com/en/1.2/topics/forms/#displaying-a-form-using-a-template nobody starenka   0 0 0 0 0 0
4627 2007-06-20 03:04:23 2011-10-09 12:44:57 2022-03-06 03:31:58.743373 Ready for checkin closed Documentation     dev fixed "Distributions" page should mention MacPorts Possibly Fink too, though I don't use that so I don't have the specifics handy. jacob Paul Bx <pb@e-scribe.com>   0 1 0 0 0 0
17095 2011-10-24 02:55:57 2011-10-24 03:16:36 2022-03-06 04:04:59.552177 Unreviewed closed Documentation Bug Normal 1.3 duplicate "Dive Into Python's explanation" hyperlink is bad. The "Dive Into Python's explanation" hyperlink does not work anymore. This is in the URL Dispatcher documentation page under the Notes of the first Example. nobody JRemedios@gmail.com   0 0 0 0 0 0
782 2005-11-13 20:49:03 2006-10-22 15:51:55 2022-03-06 03:21:39.173515 Unreviewed closed *.djangoproject.com defect normal   fixed "Django at a glance" has wrong download link The page http://www.djangoproject.com/documentation/overview/, titled "Django at a glance", has a link at the bottom that should link to the Django download page. Instead, it links to the Documentation page. It's in the following HTML snippet: {{{ <p>The next obvious steps are for you to <a class="reference" href="http://www.djangoproject.com/documentation/">download Django</a>, ... }}} jacob frederik@pandora.be   0 0 0 0 0 0
8513 2008-08-24 07:01:19 2008-08-24 07:33:38 2022-03-06 03:42:28.163812 Unreviewed closed Documentation     dev duplicate "Django at a glance" references old style contrib.admin: "class Admin: pass" http://docs.djangoproject.com/en/dev/intro/overview/#a-dynamic-admin-interface-it-s-not-just-scaffolding-it-s-the-whole-house nobody peterp   0 0 0 0 0 0
24671 2015-04-20 15:29:50 2015-04-20 15:37:37 2022-03-06 04:28:55.771111 Unreviewed closed Documentation Uncategorized Normal dev worksforme "Django deprecation timeline" page contains no timeline https://docs.djangoproject.com/en/dev/internals/deprecation/ despite having "timeline" in the name contains no dates. Really uncomfortable as it's the first one in search results. nobody int-ua   1 0 0 0 0 0
8604 2008-08-27 12:27:23 2011-09-28 16:12:17 2022-03-06 03:42:41.746311 Accepted closed Documentation     dev fixed "Documentation" link on djangoproject.com should be changed Just to not forget about that: The new documentation system has been/will be shortly announced, and release notes refering to the new comments system are on its way, hence the Documentation link on djangoproject.com should point to the new documentation (which has the documentation for the new comments, and the latest relase notes). So, don't forget ;) jacob telenieko   0 0 0 0 0 0
24190 2015-01-20 15:17:42 2015-01-24 15:16:46 2022-03-06 04:26:49.873193 Ready for checkin closed Documentation Cleanup/optimization Normal dev fixed "Don’t use len() on QuerySets" is too strong. I've seen people write code like: {{{ qs = Model.objects.filter(a=b) if qs.count() >= 1: for q in qs: # do something with q }}} They think the that ".count()" call is more efficient, but it actually makes it slower. I asked the person about it they said: "the docs say don't use len() on querysets". nobody collinanderson   0 1 0 0 0 0
4285 2007-05-12 22:54:24 2007-05-14 03:27:08 2022-03-06 03:31:00.660017 Ready for checkin closed Documentation     dev fixed "E-mail services" heading in testing documentation has too short underline Underline for "E-mail services" heading in testing documentation is too short, what generates ReST warning: {{{ System Message: WARNING/2 (<string>, line 506) Title underline too short. }}} I attached a patch against revision 5213 (current trunk), which fixes this. jacob Michał Kwiatkowski <constant.beta@gmail.com>   0 1 0 0 0 0
28500 2017-08-16 00:55:28 2017-09-04 00:37:19 2022-03-06 04:48:51.723582 Accepted closed Core (Cache system) Bug Normal 1.11 fixed "EOFError: Ran out of input" from Django file cache when file is empty When using Django file cache, if a cache file ends up empty for some reason (yes, this actually happened in the wild), an `EOFError` is thrown. Steps to reproduce: Cache must be set to `django.core.cache.backends.filebased.FileBasedCache`. {{{ >>> from django.core.cache import cache >>> cache.set('testing' 'test') }}} In a shell {{{ > cache_dir/file_that_got_created.djcache }}} Back in the REPL {{{ >>> cache.get('testing') Traceback (most recent call last): File "/usr/local/lib/python3.6/code.py", line 91, in runcode exec(code, self.locals) File "<console>", line 1, in <module> File "/usr/local/lib/python3.6/site-packages/django/core/cache/backends/filebased.py", line 40, in get if not self._is_expired(f): File "/usr/local/lib/python3.6/site-packages/django/core/cache/backends/filebased.py", line 137, in _is_expired exp = pickle.load(f) EOFError: Ran out of input }}} As to how these files would end up empty to begin with, I would hazard to guess that it is caused by a rare race condition in the file moving process: https://github.com/django/django/blob/master/django/core/files/move.py#L59 Whereby if this process is interrupted by a system shutdown, the file is created in the appropriate location but is empty. Desired behavior would be that in this situation, an exception would not be thrown. Rather, `None` (or default) would be returned. I am planning on working on a patch towards this, but wanted to log the ticket first. caleblogan mrname   0 0 0 0 0 0
16171 2011-06-07 22:11:06 2012-02-18 10:55:07 2022-03-06 04:02:28.483595 Ready for checkin closed *.djangoproject.com Bug Normal 1.3 fixed "Easy pickings unset" is confusing lots of people People keep getting the message "Easy pickings unset" after making a change on a ticket, and then they get confused, and sometimes they come back and 'revert' e.g. https://code.djangoproject.com/ticket/7028#comment:58 Can someone with server access run a query to set all the NULLs for that flag to 0 or whatever the value should be? (It is possible to do it with the batch modify interface and a query like this: https://code.djangoproject.com/query?status=!closed&easy=!1&easy=!0 But then my name will be on 1296 open tickets, which is a pain because, although I read django-updates anyway, getting e-mail personally about every ticket will break the email filters I have which currently can distinguish between django-updates and the tickets that I've actually been involved in). nobody lukeplant   0 0 0 0 0 0
7938 2008-07-24 17:13:25 2013-04-02 11:09:51 2022-03-06 03:40:58.977791 Accepted closed contrib.admin Uncategorized Normal dev invalid "Editable = False" + "Edit Inline" in new forms admin An error involved which now seems realted to the editable = false + edit inline {{{ class HandleOption(models.Model): handle_option_id = models.PositiveIntegerField(primary_key=True, editable = false) name = models.CharField(max_length=100) class Product(models.Model): product_id = models.PositiveIntegerField(primary_key=True, editable = false) name = models.CharField(max_length=100) class ProductHandling(models.Model): product_handling_id = models.PositiveIntegerField(primary_key=True, editable = false) product = models.ForeignKey(Product) handle_option = models.ForeignKey(HandleOption, core = True) # Admin bits class ProductHandling_Inline(admin.StackedInline): model = ProductHandling class ProductOptions(admin.ModelAdmin): inlines = [ProductHandling_Inline] }}} The form renders properly, However on 'Save' we get a trace back {{{ Traceback: File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/core/handlers/base.py" in get_response 87. response = callback(request, *callback_args, **callback_kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/sites.py" in root 155. return self.model_page(request, *url.split('/', 2)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/sites.py" in model_page 172. return admin_obj(request, rest_of_url) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/options.py" in __call__ 251. return self.change_view(request, unquote(url)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/django/contrib/admin/options.py" in change_view 550. return self.save_change(request, form, inline_f… brosner magneto newforms-admin 0 0 0 1 1 0
20818 2013-07-29 07:55:12 2013-07-30 01:15:54 2022-03-06 04:14:52.238425 Unreviewed closed Translations Bug Normal 1.5 invalid "Enter a valid email address." the msgid was changed on stable/1.5.x which caused its msgstr empty. I have to post the bug here since Transifex didn't resolve it. File: django/conf/locale/zh_CN/LC_MESSAGES/django.po The msgid was "Enter a valid e-mail address." in stable/1.4.x. And now: {{{ #: core/validators.py:104 forms/fields.py:464 msgid "Enter a valid email address." msgstr "" }}} On branch: stable/1.5.x and master The msgstr is missing. Please make up the string: "输入一个有效的 Email 地址。" Thanks. nobody gzerone@gmail.com zh_CN translation email field 1 0 0 0 0 1
9011 2008-09-10 12:38:01 2008-11-06 11:27:36 2022-03-06 03:43:46.387128 Unreviewed closed Core (Other)     1.0 fixed "File format may be invalid" bug in management.commands.loaddata If you try to load more than one fixture, one without any object, the output maybe wrong. Eg. account with zero object, and blog with any number of objects. {{{ >>> from django.core import management >>> management.call_command('loaddata', *['account', 'blog'], verbosity=0) No fixture data found for 'blog'. (File format may be invalid.) }}} nobody jlrivitti@gmail.com   0 1 0 0 0 0
9035 2008-09-11 15:00:51 2008-09-16 05:58:54 2022-03-06 03:43:50.349514 Unreviewed closed Documentation     1.0 fixed "File uploads" link mistaken on documentation page On the doc page, in http://docs.djangoproject.com/en/dev/#and-more the "File uploads" link does not point to file uploads information. It points to file information. nobody JimH10   0 0 0 0 0 0
15588 2011-03-10 03:38:05 2011-05-10 00:20:21 2022-03-06 04:00:55.871877 Ready for checkin closed Documentation Bug Normal 1.3-beta fixed "FileField no longer deletes files" unclear The new model <-> FileField behavior documentation is unclear. The way it's currently written leads one to believe that FileFields' {{{delete}}} method doesn't do anything on the disk. But if you call {{{m.file.delete()}}} the file is deleted from disk. Attached a patch with some suggested wording. nobody philipn   0 1 0 0 0 0
13314 2010-04-09 21:42:24 2017-06-08 16:42:08 2022-03-06 03:54:51.209869 Accepted new Forms Bug Normal 1.1   "FileField" validation does not account for "upload_to" when counting characters I have a model with a FileField object: {{{ def set_file (instance, filename): return os.path.join("uploaded_files/my_obj_%d" % instance.my_obj_id, os.path.basename(filename)) class MyModel(models.Model): my_file = models.FileField(upload_to=set_file, null=True) }}} And I have a view that receives the POST and handles it to a trivial forms.ModelForm object. In that view I check for .is_valid(). Since the FileField creates a 100-char column at the database, any filename greater than 100 chars will be rejected, and the form instance will have a nice error message talking about this. However, this comparison is broken, because the actual data stored at the database won't be the filename, but instead the return value of the "upload_to" callable. This returned value, in my case, has more characters than the actual filename. Thus, in this case, filenames between 75 and 100 characters will be accepted by the form validation, but will be rejected by the database when the actual .save() occurs. I'm not very sure about what is the best solution, but the forms.fields.FileField shouldn't rely just on the max_length parameter when validating the input. nobody denilsonsa   0 0 0 0 0 0
5645 2007-09-30 22:58:48 2007-12-01 19:26:52 2022-03-06 03:34:56.600862 Unreviewed closed Documentation     dev wontfix "First App" is Way Too Complex - Some Suggestions For a novice, or PHP convert, or even a Rails convert (I'm versed in PHP and Rails), the "Your First App" is way,way too complex. The important thing here is too remember the 80/20 rule - that users are going to use 20% of the features 80% of the time - so in the "First App" you just want to highlight the 20%. All the rest of the documentation should go into a Users Guide. I'm happy to modify/submit changes to "Your First App" documentation as we build our first Django App. What is really the best way to do this ? Should we download a section, send in our modifications ? Or just give a section by section change here (which means someone else does the actual page changes (feel free to email me). Also a testing section is really needed - testing should be both demonstrated as part of the initial stages as well as encouraged. I've written up a section on testing (but I used James Bennett's to do list example). I'll put that on a separate ticket. One big decision is whether or not a user wants to use the Admin or their own CRUD via NewForms. I think it's important to include a paragraph (see below) to let users decide which they want to use to add/edit/delete their data and then direct them to the appropriate section. We would rather use NewForms but not sure if we are majority, minority or even split. == '''Add, Edit, Delete Your Data''' == Once you have a model described, the next function is to provide for adding, editing, or deleting your data. Django offers 2 primary ways to do this: Admin and NewForms. [perhaps you just want to use "Forms" instead of "New Forms" since people reading this are new users and not used to the old forms]. '''Admin''' First, you can use the Admin library. This library automatically provides a built-in system for managing data, arranging data fields in a tabular form. [merge in all the admin stuff] New Forms You may wish to custom design your data forms like the way it's done with most other web development packages such as PHP and Rails. Django a… nobody john.staff2222@gmail.com   0 0 0 0 0 0
6311 2008-01-04 16:04:41 2008-01-04 22:15:32 2022-03-06 03:36:48.170937 Unreviewed closed Internationalization     dev duplicate "First name" and "Last name" in user model is too bad The user model has fields for "first name" and "last name". In many non-English speaking countries, people are not named this way, which can lead to several problems. See: http://rishida.net/blog/?p=100 nobody Alexandre <amartani@gmail.com> first last name user model 0 0 0 0 0 0
28390 2017-07-12 12:19:43 2017-07-12 14:07:06 2022-03-06 04:48:36.218167 Unreviewed closed Documentation Bug Normal 1.8 needsinfo "Fixing UnicodeEncodeError for file uploads" instructions don't work on CentOS 7 From [https://docs.djangoproject.com/en/1.8/howto/deployment/wsgi/modwsgi/] the suggested hints within "Fixing UnicodeEncodeError for file uploads" don't overcome the issue with UnicodeEncodeError on CentOS 7. Configuration is: {{{ [OS] CentOS Linux release 7.3.1611 (Core) [Apache] Name : httpd Arch : x86_64 Version : 2.4.6 Release : 45.el7.centos.4 [Mod_wsgi] Name : mod_wsgi Arch : x86_64 Version : 3.4 Release : 12.el7_0 }}} Setting those variables into /etc/sysconfig/httpd {{{ export LANG="en_US.UTF-8" export LC_ALL="en_US.UTF-8" }}} doesn't affect the result of {{{ import sys sys.getdefaultencoding() 'ascii' }}} and the traceback is {{{ Traceback: File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 132. response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/usr/lib/python2.7/site-packages/django/contrib/auth/decorators.py" in _wrapped_view 22. return view_func(request, *args, **kwargs) File "/home/geonode/geonode/geonode/layers/views.py" in layer_upload 174. out['errors'] = str(error) Exception Type: UnicodeEncodeError at /layers/upload Exception Value: 'ascii' codec can't encode character u'\xe8' in position 3: ordinal not in range(128) Request information: GET: No GET data POST: charset = u'UTF-8' }}} nobody francbartoli   0 0 0 0 0 0
7959 2008-07-25 14:18:59 2011-09-28 16:12:17 2022-03-06 03:41:02.267072 Ready for checkin closed Translations     1.0-alpha fixed "Free comment" is translated as "fomentário" in pt_BR locale Just what is wrote in summary :) anonymous marinho   0 1 0 0 0 0
103 2005-07-20 03:37:24 2007-07-03 23:06:11 2022-03-06 03:19:45.513585 Design decision needed closed *.djangoproject.com defect normal   fixed "Get current version: 1.0" is misleading The front page link to the download page says "Get current version: 1.0". This is misleading - there is no version 1.0 yet. The text should read "Get development version" or something similar which reinforces the fact that Django has not yet made it to a marked version. I would also argue that going straight to 1.0 isn't necessarily a good idea. If you look at Rails, they spent months and months rolling through the 0.9 etc releases before everything was considered stable enough for a 1.0. This seems like a smart model to follow. jacob Simon Willison   0 0 0 0 0 0
19828 2013-02-15 05:01:01 2013-02-15 17:30:35 2022-03-06 04:12:22.511084 Unreviewed closed *.djangoproject.com Bug Normal 1.4 fixed "How to contribute to Django" points to a removed page "How to contribute to Django" points to https://www.djangoproject.com/documentation/contributing/ when it should point to https://docs.djangoproject.com/en/1.4/internals/contributing/ nobody jonathanl   1 0 0 0 0 0
2963 2006-10-27 23:31:27 2006-10-30 20:52:03 2022-03-06 03:27:25.694158 Unreviewed closed Documentation defect normal   fixed "How to serve static files" doc contains invalid example On http://www.djangoproject.com/documentation/static_files/ it shows the usage of django.views.static.serve as: {{{ (r'^site_media/(.*)$', 'django.views.static.serve', {'document_root': '/path/to/media'}), }}} But this is invalid. It should be: {{{ (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/media'}), }}} The directory index example has the same problem: {{{ (r'^site_media/(.*)$', 'django.views.static.serve', {'document_root': '/path/to/media', 'show_indexes': True}), }}} should be: {{{ (r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': '/path/to/media', 'show_indexes': True}), }}} jacob Collin Grady <cgrady@the-magi.us>   0 0 0 0 0 0
24359 2015-02-17 21:18:55 2016-06-22 17:14:57 2022-03-06 04:27:27.499241 Accepted closed Documentation Bug Normal 1.8alpha1 fixed "Http exceptions are provided in django.http" links to a page that does not list or link to HTTP exceptions Finding the list of HTTP exceptions via the documentation on any version of the Django documentation appears to be challenging. References: * https://docs.djangoproject.com/en/1.8/ref/exceptions/#http-exceptions (location of problematic statement) * https://docs.djangoproject.com/search/?q=http+exception&release=11 * https://docs.djangoproject.com/search/?q=http+error&release=11 nobody pydanny   0 1 0 0 0 0
12457 2009-12-28 21:16:37 2009-12-28 21:44:46 2022-03-06 03:52:36.564858 Unreviewed closed Database layer (models, ORM)     1.0 duplicate "IOError: Too many open files" when pulling height and width values from a long list of ImageField containing Model objects. It appears as if !ImageField.width and !ImageField.height both open the referenced image file without closing it, resulting in the above mentioned IOError. The behavior is induced as follows: I have a long list of objects, and I am trying to pull out the size of the images that they reference. After a certain point is reached, the IOError is raised when model_object.image_field.width is accessed and assigned. This is taking place in OSX Server Leopard running fastcgi and apache, but I am sure that it would occur in other configurations as well. I determined the nature of the problem by stepping through the code using pdb. In fastcgi the exeption is caught and obfuscated. Instead of the IOError being displayed, the following message is printed out directly by fastcgi, without any further information: "An unhandled exception was thrown by the application." nobody legutierr "Too many open files" 0 0 0 0 0 0
13919 2010-07-10 14:43:59 2013-02-26 05:16:27 2022-03-06 03:56:31.498371 Unreviewed closed Uncategorized Uncategorized Normal 1.2 invalid "Incorrect string value" warning when saving some unicode characters to MySQL How to reproduce this bug, step-by-step: 1. Create a new project. 2. Create the database for this project in MySQL. Make sure the database has 'utf8' as its collation. 3. Create a new app inside your project (here I'm calling it 'testapp'). Remember to add it to settings.py. 4. At the models, create a simple one (I've named it TestModel) with just a CharField and/or a TextField. 5. ./manage.py syncdb 6. ./manage.py shell 7. from testapp.models import TestModel 8. Create a new instance of your model and set its attribute to u"Su\u1296it\U000f2a61\r\n" 9. Call .save() Boom! MySQLdb throws: {{{ Warning: Incorrect string value: '\xF3\xB2\xA9\xA1\x0D\x0A' for column 'cf' at row 1 }}} Please note that other unicode strings (like u'Bh\u0101skara\n') do work correctly, thus the MySQL database was set up correctly. However, that string above makes MySQLdb throw an exception. Does the string above make any sense? I don't know, it was a piece of text copied-and-pasted by the user. Versions: * Django 1.1.2 * MySQL 5.0.90 * mysql-python (MySQLdb) 1.2.3_rc1 * Python 2.6.5 nobody denilsonsa   0 0 0 0 0 0
4538 2007-06-11 17:43:05 2011-10-09 12:44:57 2022-03-06 03:31:44.019966 Ready for checkin closed Documentation     dev fixed "Installing the official version" should be broken into 2 parts http://www.djangoproject.com/documentation/install/ "Installing the official version" currenty: {{{ 1. Check the distribution specific notes to see if your platform/distribution provides official Django packages/installers. Distribution-provided packages will typically allow for automatic installation of dependancies and easy upgrade paths. 2. Download the latest release from our download page. 3. Untar the downloaded file (e.g. tar xzvf Django-NNN.tar.gz). 4. Change into the downloaded directory (e.g. cd Django-NNN). 5. Run sudo python setup.py install. }}} suggested: {{{ Use either A or B: A. Package 1. Check the distribution specific notes to see if your platform/distribution provides official Django packages/installers. Distribution-provided packages will typically allow for automatic installation of dependancies and easy upgrade paths. B. Tarbal 1. Download the latest release from our download page. 2. Untar the downloaded file (e.g. tar xzvf Django-NNN.tar.gz). 3. Change into the downloaded directory (e.g. cd Django-NNN). 4. Run sudo python setup.py install. }}} Might also want to add "C. using ez_install" jacob Carl Karsten <carl@personnelware.com>   0 1 0 0 0 0
26403 2016-03-24 10:37:58 2016-04-09 13:39:23 2022-03-06 04:43:48.511353 Accepted closed Template system Cleanup/optimization Normal 1.8 fixed "Invalid block tag" message is English except for one word The `invalid_block_tag()` function of template `Parser` makes use of the `django.utils.text.get_text_list()` function to generate the list of expected block tags. The only caveat is that `get_text_list()` takes a concatenation parameter whose default value is the **translated** string `or`, while the rest of the error message is untranslated. This results in crazy messages such as Invalid block tag: 'qq', expected 'xx'，'yy' 或 'zz' (for 1.8 and earlier) Invalid block tag on line 234: 'qq', expected 'xx'，'yy' 或 'zz'. Did you forget to register or load this tag? (for 1.9 and later). Looks like the solution should be easy: pass the `'or'` concatenator to `get_text_list()` instead of relying on the default value. amureki interDist   1 1 0 0 0 1
5226 2007-08-21 20:07:53 2007-09-14 18:26:10 2022-03-06 03:33:51.717851 Unreviewed closed Database layer (models, ORM)     dev fixed "Invalid relational operator" against Oracle 9i backend Recent changes to support Django's regex and iregex operators in Oracle only work against Oracle Database Server 10g or later. Running the test suite against an Oracle 9i server leads to SQL Oracle won't recognize: "DatabaseError: ORA-00920: invalid relational operator". We previously claimed to support Oracle versions 9i and greater (11g is current) in the boulder-oracle-sprint branch. Oracle 9i is due to drop off their support matrix soon, if it hasn't already, but since things move deliberately in the enterprise world, 9i is still very common. Either we need to implement a fallback strategy when connecting to a 9i server, or drop 9i support officially. mboersma mboersma oracle regex iregex 0 0 0 0 0 0
9778 2008-12-09 04:20:50 2008-12-09 07:03:53 2022-03-06 03:45:39.921838 Unreviewed closed Database layer (models, ORM)     dev fixed "Join on Field 'xyz' no permitted" error can be misleading This error can be '''very''' frustrating for someone starting to get into django, as in some cases you did not mean to do a join, but mistyped a field lookup. (For example using "regexp" instead of "regex" if you're also doing raw SQL sometimes...). I suggest returning "Join on Field 'xyz' no permitted or mistyped field lookup 'abc'." Would ahve saved me a lot of annoyed wtf's... nobody belgabor   0 0 0 0 0 0
26740 2016-06-10 14:08:15 2016-06-10 15:10:26 2022-03-06 04:44:37.295757 Unreviewed closed Migrations Bug Normal dev duplicate "Key column doesn't exist in table" when adding an index field then renaming it in the same migration in MySQL/PostgreSQL From what I gathered, the index is created at the end of the migration, however the field no longer exists under the same name. To replicate: Configure MySQL in the settings. migrations: {{{ operations = [ migrations.CreateModel( name='TestModel', fields=[ ('id', models.AutoField(auto_created=True, primary_key=True, serialize=False, verbose_name='ID')), ], ), migrations.AddField('testmodel', 'field', models.CharField(db_index=True, default='', max_length=255)), migrations.RenameField('testmodel', 'field', 'field2'), ] }}} {{{ django.db.utils.OperationalError: (1072, "Key column 'field' doesn't exist in table") }}} nobody Gagaro   0 0 0 0 0 0
27168 2016-09-02 12:36:44 2016-09-06 14:57:15 2022-03-06 04:45:38.198990 Unreviewed closed Migrations Bug Normal 1.8 needsinfo "LookupError: App 'xxxxx' doesn't have a 'xxxxx' model" with custom table name Hi, I recently wrote a migration script in order to migrate some date and one of the model uses a custom table name using db_table (let's call it "myapp_my_custom_table") When I try to run the migration I got this error: LookupError: App 'myapp' doesn't have a 'mymodel' model After investigating, I found out that the model name MyModel (not the real one) is put in lower case then used as key to fetch the actual model class ( django.apps.config.AppConfig#get_model ) One of the item of the self.models is named after the db_table '''my_custom_table''', instead of the model name '''mymodel''' The solution I found is to pass the table name instead of the model name. Before: {{{ def migrate_data(apps, schema_editor): mymodel_model = apps.get_model( app_label='myapp', model_name='MyModel') }}} After: {{{ def migrate_data(apps, schema_editor): mymodel_model = apps.get_model( app_label='myapp', model_name='my_custom_table') }}} I don't know if it's the correct behaviour. Please advise. Thanks nobody chagh migration 0 0 0 0 0 0
23253 2014-08-07 09:13:16 2014-08-07 10:18:39 2022-03-06 04:22:37.061600 Unreviewed closed Core (Mail) Bug Normal 1.6 worksforme "MANAGERS" setting doesn't correctly process the value, if it is given as described in the documentation Django 1.6.5 According to the docs (https://docs.djangoproject.com/en/1.6/ref/settings/#managers) MANAGERS expects a tuple of the same format as for ADMINS, that is tuple of tuples. In the practice it crashes with an error: PATH_TO_MY_VIRTUAL_ENV/lib/python3.4/site-packages/django/core/mail/message.py", line 244, in message msg['To'] = self.extra_headers.get('To', ', '.join(self.to)) TypeError: sequence item 0: expected str instance, tuple found That is system currently expects it to be a tuple of strings, not other tuples. If given so, everything works fine. nobody angry.kustomer@gmail.com   0 0 0 0 0 0
5838 2007-10-30 17:31:13 2007-10-30 22:35:15 2022-03-06 03:35:31.248702 Unreviewed closed Documentation     dev fixed "MIMEBase" misspelled as "MIMBase" in "Sending e-mail" section In [http://www.djangoproject.com/documentation/email/#e-mail-messages Sending e-mail] under the description of "attach()" the following line has a typo: "You can pass it a single argument that is an email.'''MIMBase'''.MIMEBase instance. This will be inserted directly into the resulting message." "MIMBase" should be "MIMEBase". nobody huddlej@gmail.com   0 0 0 0 0 0
20183 2013-04-02 22:57:32 2013-05-19 15:34:40 2022-03-06 04:13:15.530559 Accepted closed Documentation Cleanup/optimization Normal dev fixed "Making Queries" documentation assumes an Entry instance has already been created. https://docs.djangoproject.com/en/1.5/topics/db/queries/#saving-foreignkey-and-manytomanyfield-fields {{{ >>> entry = Entry.objects.get(pk=1) }}} I couldn't find where the Entry object with pk=1 gets assigned, so I predictably get an error when trying to run this line of code. Tim Graham <timograham@gmail.com> Katya <internum.odium@gmail.com>   0 1 0 0 0 0
271 2005-08-04 16:51:25 2006-10-27 15:09:16 2022-03-06 03:20:15.478860 Unreviewed closed Documentation defect normal   fixed "ManyToOneField" seen in Model Reference should read "ForeignKey" Various references can be found to a non-existant "ManyToOneField" in the Model Reference describing the ManyToManyField. These should be replaced with "ForeignKey". adrian brantley (deadwisdom@gmail.com) documentation ManyToOneField 0 0 0 0 0 0
24162 2015-01-16 21:15:21 2015-12-08 19:12:42 2022-03-06 04:26:40.906409 Accepted new Documentation New feature Normal 1.7   "Method Flowchart" for all CB(G)V documentation pages First off, to whoever had the idea and put in the effort to add the "Method Flowchart" to some of the CBV and CBGV doc pages, thank you, thank you, thank you. So helpful. Example "Method Flowchart": ​https://docs.djangoproject.com/en/dev/ref/class-based-views/generic-display/#listview So naturally I would love to see the feature on all of the CB(G)V pages, particularly those with a form as they are more complicated. Why is this necessary? 1. To make the multiple branches of form view logic more explicit. What methods get called when there is a GET? What about a POST? 2. To gain all the advantages that the "Method Flow" chart has provided to the other views. For me it has been primarily helpful for understanding and figuring out how to avoid duplicate queries. Moved from comment on: ticket:20608 nobody ivanvenosdel CBV CBGV method flowchart 0 0 0 0 0 0
20791 2013-07-23 02:04:03 2013-07-23 20:19:44 2022-03-06 04:14:48.049466 Ready for checkin closed Database layer (models, ORM) Cleanup/optimization Normal 1.5 fixed "Model %(model)s with pk %(pk)r does not exist." I agree that this is nit-picky, but in `db/models/fields/related.py` (line 979 in version 1.5.1), Django issues the following message: "Model %(model)s with pk %(pk)r does not exist." This formulation is wrong. Not the model but a model *instance* is missing. So I suggest to change this message to: "%(model)s instance with pk %(pk)r does not exist." or just: "%(model)s with pk %(pk)r does not exist." nobody lsaffre   1 1 0 0 0 0
9503 2008-11-02 23:37:20 2012-01-09 09:36:50 2022-03-06 03:45:03.631227 Accepted closed Documentation Uncategorized Normal 1.0 fixed "Model instance reference" docs don't really discuss delete. [http://docs.djangoproject.com/en/dev/ref/models/instances/ Model Instance Reference] talks in detail about the save method, but only sort of implies that there is a delete method. I think it should be a bit more explicit... jacob Beetle_B   0 0 0 0 0 0
8038 2008-07-30 10:24:28 2008-08-04 19:44:57 2022-03-06 03:41:13.570418 Unreviewed closed Documentation     dev invalid "ModelAdmin" should be "ModelForm" in admin-documentation related to: http://www.djangoproject.com/documentation/admin/#form I think it should be "The value for form is inherited from ModelForm" instead of "The value for form is inherited from ModelAdmin". nobody flosch   0 0 0 0 0 0
26827 2016-07-01 17:25:46 2021-04-21 08:55:29 2022-03-06 04:44:50.590114 Accepted new Documentation Cleanup/optimization Normal dev   "ModelState.fields cannot refer to a model class ... Use a string reference instead." when using custom model field derived from ManyToMany I ended up in a weird situation (Django 1.9.7) where I couldn't make any additional migrations. So I reset my migrations thinking the problem was somehow in the migration scripts themselves: {{{ ValueError: ModelState.fields cannot refer to a model class - "runs.to" does. Use a string reference instead. }}} I still got the error after restarting migrations from scratch, so I determined it is about the migration looking at the currently declared models, not the historical model migration scripts. I have this (trimmed) code: {{{ class Run(models.Model): pass class _RunsField(models.ManyToManyField): def __init__(self, *args, **kwargs): super(_RunsField, self).__init__(Run, through='BaselineAssignment') class Baseline(models.Model): runs = _RunsField() class BaselineAssignment(models.Model): run = models.ForeignKey('Run', on_delete=models.CASCADE) baseline = models.ForeignKey('Baseline', on_delete=models.CASCADE) }}} If I change {{{Run}}} in the {{{__init__}}} in {{{_RunsField}}} to {{{'Run'}}} (quoted) the problem goes away. This seems like this is something that should have been handled by the underlying migration code, and even if it isn't, the error message is quite unhelpful.   rrauenza   0 0 0 0 0 0
21588 2013-12-10 10:50:12 2016-06-09 16:50:15 2022-03-06 04:16:54.132754 Accepted closed Documentation Cleanup/optimization Normal dev fixed "Modifying upload handlers on the fly" documentation doesn't replicate internal magic In the documentation for [https://docs.djangoproject.com/en/dev/topics/http/file-uploads/#modifying-upload-handlers-on-the-fly modifying upload handlers on a per-request basis], the examples given imply that simply instantiating a Handler onto the `upload_handlers` is equivalent to setting them globally via [https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-FILE_UPLOAD_HANDLERS FILE_UPLOAD_HANDLERS], however this isn't the case, because the `_initialize_handlers` method of `HttpRequest` passes `self` (ie: the `request` parameter in userland code) to the given handler. Thus copying or subclassing from one of the default handlers doesn't necessarily work as expected because `request` is always `None` - which is perfectly valid according to the arguments for, say, `FileUploadHandler`. It would be prudent to note that custom handlers, if they need arguments (including request), should do so at the time of instantiation onto the upload_handlers list berkerpeksag Keryn Knight <django@kerynknight.com>   0 1 1 0 0 0
22620 2014-05-13 02:06:45 2014-08-26 19:52:47 2022-03-06 04:19:33.336047 Accepted closed Documentation Cleanup/optimization Normal 1.6 fixed "Multiple databases" chapter of docs says 'default':{} can start DATABASES setting; Django says no Hi all. I refer to https://docs.djangoproject.com/en/1.5/topics/db/multi-db/ and I am using 1.5 but the later docs are the same. I quote from the docs: "If the concept of a default database doesn’t make sense in the context of your project, you need to be careful to always specify the database that you want to use. Django requires that a default database entry be defined, but the parameters dictionary can be left blank if it will not be used." So I did that and got the following: {{{ "Internal Server Error: /admin/ Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/core/handlers/base.py", line 115, in get_response response = callback(request, *callback_args, **callback_kwargs) File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 219, in wrapper return self.admin_view(view, cacheable)(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/decorators.py", line 91, in _wrapped_view response = view_func(request, *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/views/decorators/cache.py", line 89, in _wrapped_view_func response = view_func(request, *args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 196, in inner if not self.has_permission(request): File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/contrib/admin/sites.py", line 149, in has_permission return request.user.is_active and request.user.is_staff File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/functional.py", line 204, in inner self._setup() File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/utils/functional.py", line 270, in _setup self._wrapped = self._setupfunc() File "/usr/local/lib/python2.7/dist-packages/Django-1.5.4-py2.7.egg/django/c… nobody moc@mocpa.com multiple_databases 0 1 0 0 0 0
5596 2007-09-25 10:17:33 2007-12-17 11:46:49 2022-03-06 03:34:47.194876 Ready for checkin closed HTTP handling     dev fixed "No buffer space available" error when downloading file Development server with django.views.static.serve route, file has 235949884 bytes. When trying to access the file, I get the following error: {{{ Traceback (most recent call last): File "D:\Python25\lib\site-packages\django\core\servers\basehttp.py", line 279, in run self.finish_response() File "D:\Python25\lib\site-packages\django\core\servers\basehttp.py", line 318, in finish_response self.write(data) File "D:\Python25\lib\site-packages\django\core\servers\basehttp.py", line 402, in write self._write(data) File "D:\Python25\lib\socket.py", line 263, in write self.flush() File "D:\Python25\lib\socket.py", line 250, in flush self._sock.sendall(buffer) error: (10055, 'No buffer space available') }}} Django seems to be able to read and write the file. In flush() in socket.py the final buffer to flush has the correct size. Please tell me that this isn't a general Python error. It should be possible to write a 230MB file into a socket. Still, it might be better if serve() would *not* try to read in everything at once and then write everything but stream the file in smaller chunks. nobody anonymous   0 1 1 0 0 0
22902 2014-06-25 11:57:40 2014-06-26 19:50:40 2022-03-06 04:20:48.716599 Unreviewed closed Migrations New feature Normal dev needsinfo "No changes detected" with SQLite, wrong answer If you make any changes, that SQLite doesn't allow to change via ALTER sql statement, Django shouldn't say "No changes detected", but it should say "You're using a piece of chick, so we cannot ALTER your changes". nobody d.kzlv.ru@gmail.com   0 0 0 0 0 0
7266 2008-05-19 18:51:52 2008-08-01 15:59:11 2022-03-06 03:39:10.507347 Fixed on a branch closed contrib.admin     dev fixed "Not specified" states for BooleanField BooleanField needs additional states "Not specified" which means that field wasn't supplied by user when editing ForeignKey'ed model with core=True[[BR]] Following is an intentionally simplified (for the purpose of demonstration) version of models I need to use in my project: {{{ !#python class DataClass(models.Model): name = models.CharField(max_length=100) class Admin: pass class BooleanAttribute(models.Model): owner = models.ForeignKey(to=DataClass, core=True, edit_inline=models.TABULAR) class Admin: min_num_in_admin = 3 }}} When editing the DataClass model via Django's default admin interface it will (of course) display 3 (according to min_num_in_admin) BooleanAttibute models too. Submitting the form will cause all three BooleanAttributes to be added to the newly created DataClass instance. And there is no way to say how many of them really need to be saved. My proposition is too enhance BooleanField with optional second checkbox that will indicate whether value is given or not. And only if it is on then the actual value of BooleanField to be considered. I'd like to provide patch for this issue but have no idea of where to look at. Any help - hints, suggestions, etc - will be greatly appriciated. nobody Valera Grishin BooleanField NullBooleanField nfa-fixed 0 0 0 0 0 0
32985 2021-08-03 22:52:44 2021-08-04 05:15:48 2022-03-06 05:00:32.152413 Unreviewed closed Uncategorized Uncategorized Normal 3.1 invalid "O valor \"%(value)s\" tem um formato de data inválido. Deve ser no formato " "YYY-MM-DD." just a typo in the date format nobody alexlopesbr date, typo 0 0 0 0 0 0
1842 2006-05-11 21:15:35 2006-05-15 04:04:01 2022-03-06 03:24:26.765576 Unreviewed closed *.djangoproject.com defect normal   duplicate "OR lookups" page in on-line docs is outdated This page still shows examples in pre-magic-removal syntax: http://www.djangoproject.com/documentation/models/or_lookups/ It's linked from http://www.djangoproject.com/documentation/db_api/ which does use magic-removal syntax. The syntax is correct in the file {{{tests/modeltests/or_lookups/models.py}}} of current svn. jacob akaihola   0 0 0 0 0 0
14466 2010-10-14 09:26:31 2011-09-28 16:12:27 2022-03-06 03:57:57.307676 Unreviewed closed Database layer (models, ORM)     1.2 invalid "ORA-00918: column ambiguously defined error" has reappeared in 1.2.3 It seems that the ORA-00918 error, regarding identical column names in multiple tables (where aliases are necessary for instance in nested result sets like SELECT * FROM (SELECT .. FROM ...) ), somehow has been reintroduced into the code since its resolution in ticked #7057. The following patch has resolved the issue in 1.2.3 (solution based on ticked #7057). In /django/db/models/sql/compiler.py: {{{ --- 71,88 ---- result = ['SELECT'] if self.query.distinct: result.append('DISTINCT') + # Below is a patch to the 1.2.3 code that, at least with Oracle + # made selects with identical column names crash with a ambiguous + # column name error. This error was corrected in previous versions + # of Django, but seemed to be re-introduced with 1.2.3. + if ordering: + cols = [clause.split('.')[-1] for clause in out_cols] + for index, col in enumerate(cols): + if cols.count(col) > 1: + col = '%s%d' % (col.replace('"', ''), index) + cols[index] = col + out_cols[index] = '%s AS %s' % (out_cols[index], col) result.append(', '.join(out_cols + self.query.ordering_aliases)) result.append('FROM') result.extend(from_) params.extend(f_params) *************** }}} nobody biolsen Oracle, column ambiguously defined 0 1 0 1 0 0
12420 2009-12-21 20:38:32 2011-09-28 16:12:23 2022-03-06 03:52:30.145959 Ready for checkin closed Database layer (models, ORM)     dev fixed "OneToOneField doesn't allow assignment of None" In http://code.djangoproject.com/browser/django/trunk/django/forms/models.py (R:11874) line 53 it states: {{{ 53 # OneToOneField doesn't allow assignment of None. Guard against that 54 # instead of allowing it and throwing an error. 55 if isinstance(f, models.OneToOneField) and cleaned_data [f.name] is None: 56 continue }}} Further reading of the function SingleRelatedObjectDescriptor which seems to implement most of the OTOF functionality actually states: http://code.djangoproject.com/browser/django/trunk/django/db/models/fields/related.py (R:11878) {{{ 207 # If null=True, we can assign null here, but otherwise the value needs 208 # to be an instance of the related class. 209 if value is None and self.related.field.null == False: }}} It seems that when the code in models.py was written it was by someone who simply had null=False set, which meant that the OTOF (correctly) could not have a None value. I found the issue when trying to set a OTOF as null in an admin form it says "saved successfully" but never changes the value. andrewsk kbrownlees   0 1 0 0 0 0
30896 2019-10-21 13:49:06 2019-10-22 05:56:41 2022-03-06 04:55:13.428430 Unreviewed closed Migrations Bug Normal dev needsinfo "OperationalError: (1054, "Unknown column ...)" error when running migrations on an empty MySQL database. I keep hitting this problem while trying to replay an entire database migrations on a new fresh DB (from MySQL to PostgreSQL to be precise). MySQL complains of a non existing column that was removed in a later stage of migrations. This column doesn't exist in MySQL anymore as it is up to date with the newest migration. So it's only natural that the column cannot be found. The question is: why is `migrate` looking for this column at this stage? It can only be found in the target new DB. I'm not including any code at this stage but I guess I can probably find a way to share the whole migrations if this doesn't sound like an already addressed problem. nobody nodje   0 0 0 0 0 0
9409 2008-10-21 10:56:41 2011-09-28 16:12:21 2022-03-06 03:44:49.767041 Accepted closed Documentation     1.0 fixed "OperationalError: database is locked" with Python 2.6 multiprocessing and SQLite backend Running the attached test cases in Ubuntu Hardy with Python 2.6, saving models to database fails with {{{ Process ConcurrentAccess-79: Traceback (most recent call last): File "/usr/local/lib/python2.6/multiprocessing/process.py", line 231, in _bootstrap self.run() File "./db_locked_error.py", line 18, in run f.save() File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/base.py", line 307, in save self.save_base(force_insert=force_insert, force_update=force_update) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/base.py", line 379, in save_base result = manager._insert(values, return_id=update_pk) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/manager.py", line 138, in _insert return insert_query(self.model, values, **kwargs) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/query.py", line 888, in insert_query return query.execute_sql(return_id) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/sql/subqueries.py", line 308, in execute_sql cursor = super(InsertQuery, self).execute_sql(None) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/models/sql/query.py", line 1700, in execute_sql cursor.execute(sql, params) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/backends/util.py", line 19, in execute return self.cursor.execute(sql, params) File "/usr/local/lib/python2.6/site-packages/Django-1.0_final-py2.6.egg/django/db/backends/sqlite3/base.py", line 167, in execute return Database.Cursor.execute(self, query, params) OperationalError: database is locked }}} jacob mrts   0 1 0 0 0 0
30264 2019-03-18 14:22:56 2019-03-20 12:47:50 2022-03-06 04:53:29.230055 Ready for checkin closed Core (Other) Bug Release blocker 2.2 fixed "OverflowError: timestamp out of range for platform time_t" test failure on 32-bit platforms In Debian we are seeing the following test failure on 32-bit platforms (not on 64-bit): {{{ ====================================================================== ERROR: test_parsing_year_less_than_70 (utils_tests.test_http.HttpDateProcessingTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python3.7/unittest/case.py", line 59, in testPartExecutor yield File "/usr/lib/python3.7/unittest/case.py", line 615, in run testMethod() File "/build/python-django-2.2~beta1/tests/utils_tests/test_http.py", line 301, in test_parsing_year_less_than_70 self.assertEqual(datetime.utcfromtimestamp(parsed), datetime(2050, 11, 6, 8, 49, 37)) OverflowError: timestamp out of range for platform time_t }}} This affects (at least) 2.2 beta 1 and was added in https://github.com/django/django/commit/6b7f1c2530784ed6c6c1826688faaa08e3f786d9. Original filed by Andreas Beckmann at https://bugs.debian.org/924784 felixxm lamby overflow 0 1 0 0 0 0
12338 2009-12-08 14:12:19 2009-12-14 23:59:53 2022-03-06 03:52:15.083927 Unreviewed closed Documentation     dev invalid "Overriding predefined model methods": use *args, **kwargs in code sample The "Overriding predefined model methods" section in the models doc provides sample code to override save, and I think that the code should use "*args, **kwargs" so that your own implementation is future proof. I'm attaching a patch for docs/topics/db/models.txt nobody blueyed   0 1 0 0 0 0
13269 2010-04-03 13:47:57 2011-09-28 16:12:23 2022-03-06 03:54:43.669220 Ready for checkin closed Documentation     1.2-beta fixed "Overriding the default widgets" docs missing import statement Hi. I'm new to django and am using the development version from SVN v1.2.0 beta.1 (rev 12909) I am unsure of whether there is a problem in the code, docs or my own app. I'm providing this as a solution to a problem I faced, based on information found in the docs. The first example given in the following section of the docs would not work for me... http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-the-default-field-types-or-widgets {{{ class AuthorForm(ModelForm): class Meta: model = Author fields = ['name', 'title', 'birth_date'] widgets = { 'name': Textarea(attrs={'cols': 80, 'rows': 20}), } }}} From reading through the docs, I presume that the only import required is: {{{ from django.forms import ModelForm }}} When I attempted to run the development server, I receive the following error message: {{{ NameError: name 'Textarea' is not defined }}} My solution was the following: {{{ from django import forms class AuthorForm(forms.ModelForm): class Meta: model = Author fields = ['name', 'title', 'birth_date'] widgets = { 'name': forms.Textarea(attrs={'cols': 80, 'rows': 20}), } }}} In summary, I made the following changes: {{{ Line 1 - from django import forms Line 3 - class AuthorForm(forms.ModelForm): Line 8 - 'name': forms.Textarea(...), }}} I hope this is of some help. gabrielhurley mattrowbum widgets, form field types 0 1 0 0 0 0
5024 2007-07-31 05:25:41 2007-09-15 05:00:21 2022-03-06 03:33:20.848699 Ready for checkin closed Documentation     dev fixed "Passwd" is invalid option in MySQL option file; must use "Password" I followed the instructions in the tutorial and at http://www.djangoproject.com/documentation/databases/ for configuring MySQL to work with Django using an option file. When trying to start the server with 'python manage.py runserver', the server threw an exception. The root exception was: {{{ _mysql_exceptions.OperationalError: (1045, "Access denied for user 'root'@'localhost' (using password: NO)") }}} When I changed the password line in my option file from "passwd = XXX" to "password = XXX", the error disappeared and I was able to start the server. This was strange, because when running the mysql client from the shell I can use either option "passwd" or "password" to login. I've pasted the config files below with the passwords blanked out. Software versions below config files. {{{ #settings.py ... DATABASE_ENGINE = 'mysql' DATABASE_OPTIONS = { "init_command": "SET storage_engine=INNODB", 'read_default_file': '/home/ispivey/Code/django/mysql.cnf' } ... }}} {{{ #mysql.cnf [client] database = testdb user = root passwd = XXXXX default-character-set = utf8 }}} Using:[[BR]] django trunk from svn on Jul 31st[[BR]] Ubuntu Feisty Fawn[[BR]] mysql-server 5.0.38-0[[BR]] mysqldb 1.2.1-p2-4[[BR]] nobody ispivey@gmail.com mysql database sprintsept14 0 1 0 0 0 0
29981 2018-11-23 13:06:36 2019-01-01 16:02:25 2022-03-06 04:52:43.175537 Accepted closed contrib.admin Bug Normal 2.1 fixed "Please correct the error below." (with no errors displayed) when changing an inline that has a one-to-one relation to the parent that uses to_field **Code sample:** models.py: {{{ from django.db import models class Entry(models.Model): slug = models.SlugField(max_length=80, unique=True) title = models.CharField(max_length=255, blank=True, null=True) class EntryDetail(models.Model): entry = models.OneToOneField( Entry, to_field='slug', primary_key=True, on_delete=models.CASCADE ) description = models.TextField(blank=True, null=True) }}} admin.py {{{ from django.contrib import admin from .models import Entry, EntryDetail class EntryDetailInline(admin.StackedInline): model = EntryDetail @admin.register(Entry) class EntryAdmin(admin.ModelAdmin): inlines = [EntryDetailInline] def get_readonly_fields(self, request, obj=None): # Even with EntryDetail.entry_id ON UPDATE: CASCADE set on DB-level # changing Entry.slug through the admin-change-form with EntryDetail-inline fails. # Set slug readonly as workaround. Don't know if this is worth fixing. readonly_fields = super().get_readonly_fields(request, obj) if hasattr(obj, 'entrydetail') and 'slug' not in readonly_fields: readonly_fields += ('slug',) return readonly_fields }}} **Steps to reproduce the bug:** In the admin: * add an Entry * fill slug, title, and "Entry detail" description * save and continue editing * change "Entry detail" description * save * Error message in admin: "Please correct the error below." (with no errors listed). `formset[0].errors` is `[{'entry': ['The inline value did not match the parent instance.']}]` which comes from `InlineForeignKeyField` value is `aaa` and `orig` is `1`. **Workaround:** in models.py replace {{{ class EntryDetailInline(admin.StackedInline): model = EntryDetail }}} with: {{{ from django.forms import BaseInlineFormSet class EntryDetailFormSet(BaseInlineFormSet): def add_fields(self, form, index): super().add_fields(form, index) related… patriksletmo bitroost   0 1 0 0 0 0

Next page

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE tickets (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );