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