29,846 rows sorted by summary

View and edit SQL

These facets timed out: changetime

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 2019-06-24 00:27:11.667218 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 2019-06-24 01:59:37.343472 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 2019-06-24 02:52:51.375472 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 2019-06-24 04:47:32.500521 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
22992 2014-07-10 14:37:49 2014-07-14 17:07:08 2019-06-24 04:24:27.977409 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 2019-06-24 04:24:29.250909 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 2019-06-24 04:49:36.260450 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 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 2019-06-24 02:38:15.260725 Accepted closed contrib.admin     master 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 2019-06-24 05:50:59.675882 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 2019-06-24 04:41:02.600357 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 2019-06-24 05:02:41.312050 Ready for checkin closed Migrations Bug Release blocker master 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 2019-06-24 00:21:16.776581 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 2019-06-24 00:15:29.178930 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 2019-06-24 02:43:18.171560 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 2019-06-24 04:56:11.743861 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
20262 2013-04-15 11:40:20 2013-04-15 20:29:59 2019-06-24 03:54:54.876311 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 2019-06-24 03:48:38.201334 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
25424 2015-09-18 00:29:17 2015-09-19 13:02:04 2019-06-24 04:51:01.423834 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 2019-06-24 02:45:52.226787 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 2019-06-24 06:03:26.286061 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
11359 2009-06-24 00:36:07 2009-09-12 23:06:24 2019-06-24 02:18:26.377614 Ready for checkin closed Documentation     master 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 2019-06-24 03:30:10.338432 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 2019-06-24 05:45:21.528109 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 2019-06-24 01:51:19.943364 Unreviewed closed Documentation     master fixed "Changed|New in Django development version" and version*:: 1.0 fixes See atacjed patch nobody ramiro   0 1 0 0 0 0
679 2005-10-22 03:54:32 2006-10-07 21:56:27 2019-06-24 00:22:30.381783 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 2019-06-24 01:25:17.709806 Unreviewed closed contrib.syndication     master 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 2019-06-24 03:13:01.403629 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 2019-06-24 05:23:02.966666 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 2019-06-24 04:46:57.048153 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 2019-06-24 04:16:46.771182 Accepted closed Testing framework Bug Normal master 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 2019-06-24 03:03:22.414279 Ready for checkin closed HTTP handling Bug Normal master 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 2019-06-24 01:50:02.816842 Ready for checkin closed Translations     master 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 2019-06-24 02:16:26.792155 Unreviewed closed Documentation     master 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 2019-06-24 04:06:50.184484 Unreviewed closed Documentation Cleanup/optimization Normal master 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 2019-06-24 03:16:55.298469 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 2019-06-24 02:58:46.217938 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 2019-06-24 01:04:24.792085 Ready for checkin closed Documentation     master 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 2019-06-24 03:20:50.170026 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 2019-06-24 00:23:36.009700 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 2019-06-24 01:47:39.957947 Unreviewed closed Documentation     master 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 2019-06-24 04:42:48.040082 Unreviewed closed Documentation Uncategorized Normal master 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 2019-06-24 01:48:38.806299 Accepted closed Documentation     master 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 2019-06-24 04:37:33.385964 Ready for checkin closed Documentation Cleanup/optimization Normal master 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 2019-06-24 01:00:44.837825 Ready for checkin closed Documentation     master 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 2019-06-24 05:41:39.395527 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 2019-06-24 03:10:47.000956 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 2019-06-24 01:40:27.254022 Accepted closed contrib.admin Uncategorized Normal master 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 2019-06-24 04:00:54.200165 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 2019-06-24 01:53:02.344240 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 2019-06-24 01:53:17.558869 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 2019-06-24 03:04:21.553256 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 2019-06-24 02:39:46.013776 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 2019-06-24 01:15:39.008150 Unreviewed closed Documentation     master 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 2019-06-24 01:22:49.269069 Unreviewed closed Internationalization     master 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 2019-06-24 05:40:28.373450 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 2019-06-24 01:40:40.828045 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 2019-06-24 00:16:22.510345 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 2019-06-24 03:50:15.958476 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 2019-06-24 00:46:44.573898 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 2019-06-24 04:39:22.717986 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 2019-06-24 02:30:19.522085 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 2019-06-24 02:46:22.795710 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 2019-06-24 01:03:27.445356 Ready for checkin closed Documentation     master 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 2019-06-24 05:01:42.168668 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 2019-06-24 01:10:52.634560 Unreviewed closed Database layer (models, ORM)     master 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 2019-06-24 02:01:17.612005 Unreviewed closed Database layer (models, ORM)     master 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 2019-06-24 05:05:25.342909 Unreviewed closed Migrations Bug Normal master 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 2019-06-24 05:10:03.757660 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 2019-06-24 04:27:17.381496 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 2019-06-24 01:17:44.148214 Unreviewed closed Documentation     master 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 2019-06-24 03:54:03.654667 Accepted closed Documentation Cleanup/optimization Normal master 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 2019-06-24 00:18:08.628581 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 2019-06-24 04:37:15.473686 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 2019-06-24 04:00:36.717773 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 2019-06-24 01:58:18.400700 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 2019-06-24 01:41:35.754858 Unreviewed closed Documentation     master 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 2016-07-02 13:36:18 2019-06-24 05:06:21.882195 Accepted assigned Documentation Cleanup/optimization Normal master   "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. Zaheers rrauenza   0 1 1 0 1 0
21588 2013-12-10 10:50:12 2016-06-09 16:50:15 2019-06-24 04:09:15.059880 Accepted closed Documentation Cleanup/optimization Normal master 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 2019-06-24 04:20:27.166809 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 2019-06-24 01:15:07.431790 Ready for checkin closed HTTP handling     master 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 2019-06-24 04:23:29.715336 Unreviewed closed Migrations New feature Normal master 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 2019-06-24 01:33:14.133118 Fixed on a branch closed contrib.admin     master 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
1842 2006-05-11 21:15:35 2006-05-15 04:04:01 2019-06-24 00:34:50.709007 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 2019-06-24 02:52:15.922562 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 2019-06-24 02:29:55.725118 Ready for checkin closed Database layer (models, ORM)     master 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
9409 2008-10-21 10:56:41 2011-09-28 16:12:21 2019-06-24 01:57:17.913276 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 2019-06-24 06:00:57.851219 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 2019-06-24 02:29:01.809770 Unreviewed closed Documentation     master 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 2019-06-24 02:39:16.849639 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 2019-06-24 01:08:40.275507 Ready for checkin closed Documentation     master 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 2019-06-24 05:57:48.442630 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
2169 2006-06-16 05:31:04 2012-09-25 16:52:12 2019-06-24 00:38:19.077725 Unreviewed closed contrib.admin defect normal master fixed "Please correct the error below." With No Shown Errors When a class has a field that isn't shown in the admin interface but must not be blank, it's impossible to add a new one. You get a cryptic "Please correct the error below." message with no shown errors. The error message should probably say something about a hidden field. Here's a sample model to reproduce this bug: {{{ class Foo(models.Model): title = models.CharField(maxlength=100) url = models.URLField() class Admin: fields = ( (None, {'fields': ('title',)}), ) }}} anonymous tyson@fallingbullets.com   0 0 0 0 0 0
12749 2010-02-01 16:58:01 2011-09-28 16:12:23 2019-06-24 02:33:27.333972 Accepted closed contrib.admin Uncategorized Normal master fixed "Please correct the error below." when saving add model form with inline formset and no auto primary key. When a Model has a field with primary_key=True and the Admin has an Inline ManyToMany, trying to save will result in "Please correct the error below." with no errors shown. This has been introduced in [12206]. Just the changes in django/contrib/admin/options.py to be precise. I expected reverting the patch would result in failing tests. But no tests failed. So either [12206] contained noise code that was doing nothing or it needed better tests. I've written a test for my usecase that was broken by [12206] and I suggest that someone that knows the purpose of [http://code.djangoproject.com/changeset/12206#file0 the options.py part of 12206] expresses that purpose in a test. I'll add both my test and a patch containing part of the faulty changeset, but triagers, this ticket might need a better patch. jkocherhans Chris.Wesseling@cwi.nl   0 1 1 0 0 0
29647 2018-08-07 10:49:36 2018-08-09 07:24:23 2019-06-24 05:54:13.239284 Unreviewed closed contrib.admin Bug Normal 2.1 invalid "Please correct the error below." when saving edit model form with inline formset and space at the end of primary key value I have an Attribute instance in DB with name 'Motor type ' (space in the end). Also, I have AttributeValueInlineAdmin as inline for AttributeAdmin. When I try to change field display_name for that instance in Django admin I get an error "Please correct the error below." with no errors shown. The reason for that error is the space at the end of the primary key. nobody uralov   0 0 0 0 0 0
24725 2015-04-29 13:26:44 2015-04-30 11:49:15 2019-06-24 04:43:23.129502 Ready for checkin closed Migrations Bug Release blocker 1.8 fixed "ProgrammingError: relation does not exist" when renaming many-to-many target model To demonstrate this bug, I created a Github repository: https://github.com/dbrgn/django18-migration-bug You can see each step in the commit log. When I run the migrations for that project in a clean Postgres database, I get an exception. You can run "reproduce.sh" to reproduce (d'oh!). {{{ $ dropdb dj18 $ createdb dj18 $ ./manage.py migrate Operations to perform: Synchronize unmigrated apps: staticfiles, messages Apply all migrations: admin, debug, contenttypes, auth, sessions Synchronizing apps without migrations: Creating tables... Running deferred SQL... Installing custom SQL... Running migrations: Rendering model states... DONE Applying contenttypes.0001_initial... OK Applying auth.0001_initial... OK Applying admin.0001_initial... OK Applying contenttypes.0002_remove_content_type_name... OK Applying auth.0002_alter_permission_name_max_length... OK Applying auth.0003_alter_user_email_max_length... OK Applying auth.0004_alter_user_username_opts... OK Applying auth.0005_alter_user_last_login_null... OK Applying auth.0006_require_contenttypes_0002... OK Applying debug.0001_initial... OK Applying debug.0002_auto_20150429_1317...Traceback (most recent call last): File "./manage.py", line 10, in <module> execute_from_command_line(sys.argv) File "/home/danilo/.virtualenvs/django18-migration-bug/lib/python2.7/site-packages/django/core/management/__init__.py", line 338, in execute_from_command_line utility.execute() File "/home/danilo/.virtualenvs/django18-migration-bug/lib/python2.7/site-packages/django/core/management/__init__.py", line 330, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/home/danilo/.virtualenvs/django18-migration-bug/lib/python2.7/site-packages/django/core/management/base.py", line 390, in run_from_argv self.execute(*args, **cmd_options) File "/home/danilo/.virtualenvs/django18-migration-bug/lib/python2.7/site-packages/django/core/management/base.py", line 441, in execute … MarkusH dbrgn migrations 0 1 0 0 0 0
4012 2007-04-11 17:35:33 2007-04-12 12:45:42 2019-06-24 00:57:51.945632 Unreviewed closed Core (Serialization)     master duplicate "ProgrammingError: syntax error" when loading (JSON) serialized data I'm using rev. 4993. My model is: (testproj.testapp) {{{ from django.db import models class TestModel(models.Model): name = models.CharField(maxlength=10) }}} Then: {{{ $ ./manage.py shell Python 2.5.1c1 (release25-maint, Apr 6 2007, 22:02:36) [GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from testproj.testapp. models import TestModel >>> test_obj = TestModel(name="Foo") >>> test_obj.save() >>> }}} ...And: {{{ $ ./manage.py dumpdata testapp [{"pk": "1", "model": "testapp.testmodel", "fields": {"name": "Foo"}}] }}} OK it is there. Lets get it back: {{{ $ ./manage.py dumpdata testapp > test.json $ ./manage.py loaddata test.json Loading 'test' fixtures... Installing json fixture 'test' from absolute path. Installed 1 object(s) from 1 fixture(s) Traceback (most recent call last): File "./manage.py", line 11, in <module> execute_manager(settings) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1669, in execute_manager execute_from_command_line(action_mapping, argv) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1583, in execute_from_command_line action_mapping[action](args[1:], int(options.verbosity)) File "/usr/lib/python2.5/site-packages/django/core/management.py", line 1413, in load_data cursor.execute(line) File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line 12, in execute return self.cursor.execute(sql, params) psycopg2.ProgrammingError: syntax error at or near " }}} On "screen -U" (unicode), the error message ends on the '''"'''. I have to type Enter to get my shell back. Without screen: {{{ [...] psycopg2.ProgrammingError: syntax error at or near " INE 1: SELECT setval('testapp_testmodel_id_seq'... ^ }}} jacob eduardo.padoan@gmail.com JSON 0 0 0 0 0 0
3392 2007-01-29 18:59:48 2007-01-30 12:11:39 2019-06-24 00:51:22.475690 Unreviewed closed *.djangoproject.com     0.95 duplicate "Recent code changes" link on /documentation/ in TicketModule This is the full URL: http://code.djangoproject.com/timeline?daysback=90&max=50&wiki=on&ticket=on&changeset=on&milestone=on&format=rss I'm sure someone else has reported this or that you already know in some other way, but here's the error message: Ticket changes, Ticket details event provider (TicketModule) failed: AttributeError: 'NoneType' object has no attribute 'lower' jacob hwinther@wshosting.org timeline,rss 0 0 0 0 0 0
15692 2011-03-26 00:11:27 2011-03-26 00:18:48 2019-06-24 03:05:31.861166 Unreviewed closed Core (Other)     master duplicate "Referenced before assignment" in WSGIHandler This happens when WSGIHandler is not able to decode request data (stupid flash don't know how to encode urls). {{{ Traceback (most recent call last): File "/home/sayane/.buildout/parts/django/django/core/servers/basehttp.py", line 283, in run self.result = application(self.environ, self.start_response) File "/home/sayane/.buildout/parts/django/django/contrib/staticfiles/handlers.py", line 68, in __call__ return self.application(environ, start_response) File "/home/sayane/.buildout/parts/django/django/core/handlers/wsgi.py", line 264, in __call__ logger.warning('Bad Request (UnicodeDecodeError): %s' % request.path, UnboundLocalError: local variable 'request' referenced before assignment }}} nobody sayane   0 0 0 0 0 0
14756 2010-11-22 22:09:48 2011-09-28 16:12:27 2019-06-24 02:55:20.873209 Accepted closed Documentation     1.3-alpha fixed "Related objects reference" documentation needs copy-edit On http://docs.djangoproject.com/en/dev/ref/models/relations/, we find (and in the v1.2 docs): "A “related manager” is a on managers used in a one-to-many or many-to-many related context." I suggest s/is a on managers/is a manager . elbarto deisner easy-pickings 0 1 0 0 0 0
9043 2008-09-11 20:42:44 2011-09-28 16:12:21 2019-06-24 01:53:22.489252 Accepted closed Documentation     master fixed "Related objects reference" ignores relations other than ForeignKey The documentation at http://docs.djangoproject.com/en/dev/ref/models/relations/ discusses methods available "on managers when used in a ForeignKey context", but it wasn't at clear that these methods would be available to me on a ManyToManyField. Also, that page seems to be missing any mention of ManyRelatedManager.update(). This page seems like an appropriate place to mention that method as well. jacob wam-djangobug@wamber.net   0 0 0 0 0 0

Next page

Advanced export

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

CSV options:

CREATE TABLE "tickets_full" (
        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