tickets
52 rows where "changetime" is on date 2013-02-08
This data as json, CSV (advanced)
Suggested facets: changetime, stage, component, type, severity, version, resolution, owner, easy, has_patch, needs_better_patch, needs_tests, needs_docs, created (date), last_pulled_from_trac (date)
id ▼ | created | changetime | last_pulled_from_trac | stage | status | component | type | severity | version | resolution | summary | description | owner | reporter | keywords | easy | has_patch | needs_better_patch | needs_tests | needs_docs | ui_ux |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
10239 | 2009-02-11 19:25:56 | 2013-02-08 08:22:59 | 2022-03-06 03:46:47.651230 | Ready for checkin | closed | Documentation | New feature | Normal | dev | fixed | Document modelform_factory | [http://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L332 modelform_factory] is not documented in [http://docs.djangoproject.com/en/dev/topics/forms/modelforms/] | timo | ingenieroariel | dceu2011 | 0 | 1 | 0 | 0 | 0 | 0 |
13533 | 2010-05-14 01:44:03 | 2013-02-08 19:37:55 | 2022-03-06 03:55:28.210695 | Accepted | closed | Database layer (models, ORM) | Bug | Normal | 1.2-beta | duplicate | queries test fails under MySQL InnoDB | As of 1.2RC1, the queries test fails under MySQL InnoDB fails at the following test: {{{ Failed example: Tag.objects.exclude(children=None) Expected: [<Tag: t1>, <Tag: t3>] Got: [<Tag: t1>, <Tag: t3>, <Tag: t4>] }}} This is at line 1150 (as of r13252). This test passes as is under SQLite, Postgres, and MySQL MyISAM. Even more weird - if you dig into the database at the time the test runs, the query is the same, and the contents of the table is the same. The issue appears to be entirely related to a query cache somewhere in the MySQLdb infrastructure, but only under InnoDB. You can make the test pass by inserting: {{{ >>> connection.close() }}} just before the failing test. You can also make the test pass by manually issuing the same query twice, and only checking the test result on the second execution -- i.e., if you modify the test to the following: {{{ >>> r = list(Tag.objects.exclude(children=None)) >>> Tag.objects.exclude(children=None) [<Tag: t1>, <Tag: t3>] }}} The test will pass. | nobody | russellm | innodb mysql | 0 | 0 | 0 | 0 | 0 | 0 |
15506 | 2011-02-25 23:28:42 | 2013-02-08 20:03:06 | 2022-03-06 04:00:44.006702 | Accepted | closed | Database layer (models, ORM) | New feature | Normal | 1.2 | duplicate | Savepoint support for sqlite3 backend | We can enable savepoints on sqlite if the user has set `isolation_level=None` in their OPTIONS dict (or they have otherwise set the `isolation_level` to `None`) on the `django.db.connections.connection` sqlite instance. The default is `''` (empty string). Patch attached. | nobody | lamby | 0 | 1 | 1 | 0 | 0 | 0 | |
16218 | 2011-06-10 12:06:30 | 2013-02-08 08:23:10 | 2022-03-06 04:02:35.375187 | Accepted | closed | Generic views | Bug | Normal | dev | fixed | Class-based month archive doesn't behave like previous generic view | While converting some of the regression tests for generic views to class-based views, I've noticed that the class-based month archive doesn't behave like the previous generic views. Applying the attached patch breaks the tests: {{{ FAIL: test_archive_month_date_list (regressiontests.views.tests.generic.date_based.MonthArchiveTest) ... AssertionError: datetime.datetime(2010, 1, 2, 0, 0) != datetime.datetime(2010, 1, 1, 0, 0) FAIL: test_archive_month_includes_only_month (regressiontests.views.tests.generic.date_based.MonthArchiveTest) Regression for #3031: Archives around Feburary include only one month ... AssertionError: None != datetime.date(2004, 3, 1) }}} | aaugustin | nnrcschmdt | 0 | 1 | 0 | 0 | 0 | 0 | |
17228 | 2011-11-14 14:30:58 | 2013-02-08 08:23:09 | 2022-03-06 04:05:18.910008 | Accepted | closed | Generic views | Cleanup/optimization | Normal | dev | fixed | params context variable from TemplateView is inconsistent with other get_context_data implementations | The general pattern of get_context_data is to return a context dictionary where the kwargs passed to the method are used to update the context. This pattern is true for all classes that implement get_context_data except for TemplateView, which adds all the kwargs as a 'params' item. This is as documented but is inconsistent and makes it trickier to finish up work on #16074 which requires that all implementations of get_context_data call super. The cleanest design would be a pattern of: {{{ def get_context_data(self, **kwargs): context = super(.... )(kwargs) # class specific stuff here return context }}} I propose that the use of a params item be deprecated, removed from the docs, and preserved through deprecation by both updating the context with kwargs, and defining the explicit 'params' item in TemplateView. | nobody | ptone | 0 | 0 | 0 | 0 | 0 | 0 | |
17763 | 2012-02-24 16:58:17 | 2013-02-08 18:05:27 | 2022-03-06 04:06:43.435155 | Accepted | closed | contrib.auth | Bug | Normal | 1.0 | duplicate | Problem with auth_permission name length | Django automatically generates a name that is longer than what the default field length can hold. {{{INSERT INTO "auth_permission" ("name", "content_type_id", "codename") VALUES (%s, %s, %s) (u'Can add study plan practice assessment tutorial question', 52, u'add_studyplanpracticeassessmenttutorialquestion')}}} This will fail with a error about it not being able to fit in a varchar(50) {{{ Table "public.auth_permission" Column | Type | Modifiers -----------------+------------------------+-------------------------------------------------------------- id | integer | not null default nextval('auth_permission_id_seq'::regclass) name | character varying(50 ) | not null content_type_id | integer | not null codename | character varying(100) | not null }}} This was under PostgreSQL and after modifying the field to have a length of 200, I was able to perform the insert. | anonymous | stenius@gmail.com | 1 | 0 | 0 | 0 | 0 | 0 | |
18026 | 2012-03-30 19:42:11 | 2013-02-08 08:23:00 | 2022-03-06 04:07:27.834842 | Accepted | closed | contrib.formtools | Bug | Normal | 1.4 | fixed | can't update extra_data in process_step of form wizard | The [https://docs.djangoproject.com/en/dev/ref/contrib/formtools/form-wizard/#django.contrib.formtools.wizard.views.WizardView.process_step WizardView.process_step] documentation indicates that it is possible to set storage extra data but this appears not to be the case. It seems the problem lies with the getter for extra_data when it finds an empty dict for extra_data it returns an anonymous dict instead of self.data[self.extra_data_key]. This is a one line change at https://code.djangoproject.com/browser/django/trunk/django/contrib/formtools/wizard/storage/base.py#L40 or there abouts. def _get_extra_data(self): return self.data[self.extra_data_key] or {} ...changes to... def _get_extra_data(self): return self.data[self.extra_data_key] Credit to [https://github.com/stephrdev/django-formwizard/pull/33 Ryan Show] who identified the problem. I just wanted to get it into the tracker here as I've run into the problem myself. Toodle-looooooooo........ creecode | steph | creecode | form wizard extra_data process_step can't update | 0 | 0 | 0 | 0 | 0 | 0 |
18906 | 2012-09-05 13:01:23 | 2013-02-08 20:35:49 | 2022-03-06 04:09:55.144902 | Accepted | closed | Forms | Bug | Normal | 1.4 | fixed | BaseModelFormSet.validate_unique should ignore forms marked for deletion | is_valid() returns false for a formset where uniquness is violated even if one of the forms where the violation occurs has DELETE set to true in cleaned data so maybe line 521 in django/forms/models.py which is currently if not hasattr(form, "cleaned_data"): continue should read something like, so it will ignore forms that are getting deleted anyway if not hasattr(form, "cleaned_data") or form.cleaned_data.get('DELETE', True): continue unless of course I have completely missed the point Cheers Charlie | nobody | c.pollock@bangor.ac.uk | 0 | 1 | 0 | 0 | 0 | 0 | |
19024 | 2012-09-25 15:25:45 | 2013-02-08 08:23:02 | 2022-03-06 04:10:13.169066 | Ready for checkin | closed | contrib.formtools | Cleanup/optimization | Normal | dev | fixed | FormWizard WizardView.get_form_prefix form argument is unused | The documentation shows WizardView.get_for_prefix(step). Actual definition is `def get_form_prefix(self, step=None, form=None):` In practice, the form argument is passed. | steph | kenth | 1 | 1 | 0 | 0 | 0 | 0 | |
19076 | 2012-10-05 18:07:14 | 2013-02-08 08:23:08 | 2022-03-06 04:10:21.406818 | Accepted | closed | Generic views | Bug | Normal | dev | fixed | TemplateView does not support setting mime type, like views.generic.simple.direct_to_template did | I use `direct_to_template` to serve my robots.txt, like this: {{{ urlpatterns = patterns('', url('^robots.txt$', TemplateView.as_view(template_name='robots.txt', content_type='text/plain')), ... }}} In Django 1.5 this is no longer possible, because the function-based generic views are removed, and TemplateView does not have a mime/content type argument. I think that a `content_type` argument should be added to TemplateView to add the same functionality that was in the function-based view. Patch to come. | nobody | gwahl@fusionbox.com | 0 | 1 | 0 | 0 | 0 | 0 | |
19092 | 2012-10-09 13:05:35 | 2013-02-08 08:23:01 | 2022-03-06 04:10:23.834039 | Accepted | closed | Translations | Bug | Normal | 1.4 | fixed | formats.py for Lithuanian language | Current formats.py for Lithuanian (lt) doesn't adhere to official formats used in language. Provided is a patch to fix this. Note that in DATE_FORMAT and DATETIME_FORMAT "E" is used (alternative month translation in translation files), however current Lithuanian translations for alternative month names are incorrect (e.g. "January" should be "Sausio" instead of "Sausis" when used in long date format). I intend to fix that through Transifex as soon as I get confirmed as team member. | nobody | skirsdeda | 0 | 1 | 0 | 0 | 0 | 0 | |
19333 | 2012-11-21 15:38:28 | 2013-02-08 08:23:12 | 2022-03-06 04:11:02.767466 | Ready for checkin | closed | contrib.admin | Bug | Normal | 1.4 | fixed | Collect static copies a .py file | When you run a collectstatic the file compress.py gets copied to the static directory, and that doesn't seem right. I have created a pull request because this was generating PEP8 warnings for a project, but looking at the comments i agree this file shouldn't be copied. https://github.com/django/django/pull/474 Maybe some can tweak the collectstatic command so it ignores .py files. | nobody | camilonova | 0 | 1 | 0 | 0 | 0 | 0 | |
19437 | 2012-12-06 19:02:29 | 2013-02-08 08:22:59 | 2022-03-06 04:11:19.389314 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.4 | fixed | improved documentation for django installation | Documentation "topics/install" reads: '''sudo pip install -e django-trunk/''' In the newer installation instructions from code.djangoproject.com/ticket/19349: '''pip install -e /path/to/your/local/clone/django/''' The newer version properly explains that this is the path/to/django, but also that the last element is /django/ which reflects the proper subdirectory to be referenced with the pip command. | dodger | dodger | documentation | 1 | 0 | 0 | 0 | 0 | 0 |
19441 | 2012-12-07 10:16:11 | 2013-02-08 08:22:55 | 2022-03-06 04:11:20.002941 | Ready for checkin | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | No Postgres _like index when unique=True | {{{ class Species(models.Model): scientific_name = models.CharField(max_length=200, db_index=True) }}} Generates 2 indexes: {{{ BEGIN; CREATE INDEX "species_species_scientific_name" ON "species_species" ("scientific_name"); CREATE INDEX "species_species_scientific_name_like" ON "species_species" ("scientific_name" varchar_pattern_ops); COMMIT; }}} {{{ class Species(models.Model): scientific_name = models.CharField(max_length=200, unique=True, db_index=True) }}} ...does not create any indexes, because it depends on UNIQUE, but it SHOULD generate the index: {{{CREATE INDEX "species_species_scientific_name_like" ON "species_species" ("scientific_name" varchar_pattern_ops);}}} to make sure Postgres is optimized for LIKE operator. | nobody | dyve | postgresql | 0 | 1 | 0 | 0 | 0 | 0 |
19477 | 2012-12-14 20:25:45 | 2013-02-08 08:23:05 | 2022-03-06 04:11:25.299846 | Accepted | closed | Documentation | Bug | Normal | dev | fixed | Docs needed for generic_inlineformset_factory | Unless I missed it I couldn't find any docs for `django.contrib.contenttypes.generic.generic_inlineformset_factory`. | nobody | epicserve | 0 | 1 | 0 | 0 | 0 | 0 | |
19488 | 2012-12-17 10:23:40 | 2013-02-08 08:23:00 | 2022-03-06 04:11:26.602721 | Accepted | closed | Core (Other) | Bug | Normal | 1.4 | fixed | Locale middleware with settings.APPEND_SLASH enabled is buggy (doesn't redirect) with valid URLs not ending with slash | Hello, the locale middleware does not handle the case when settings.APPEND_SLASH is enabled and a valid URL that doesn't end with slash is accessed. Example: {{{ i18n url pattern ^sitemap\.xml$ }}} I access domain.tld/sitemap.xml The middleware checks if settings.APPEND_SLASH and not language_path.endswith('/') and in that case appends '/' to the url, so we get something like language_path=u'/en/sitemap.xml/'. That in turn does not match any of the urls because our regexp doesn't allow slash at the end for sitemap.xml and we get 404 instead of redirect to /en/sitemap.xml. My pull request is at https://github.com/django/django/pull/591 | nobody | danger@rulez.sk | redirect, i18n, locale middleware | 0 | 1 | 0 | 0 | 0 | 0 |
19546 | 2013-01-01 17:05:39 | 2013-02-08 08:22:57 | 2022-03-06 04:11:34.848571 | Ready for checkin | closed | Testing framework | Cleanup/optimization | Release blocker | dev | fixed | Add logging configuration to test_sqlite.py | I am not able to see deprecation warnings while running tests with python 2.7. Adding -Wd and -Wall parameters has no effect either. And only after adding `py.warnings` logger i finally got my warnings. So i'm proposing to add this logger into 'default' django test config [https://github.com/bak1an/django/commit/63c31f70913d692ae458193806732796b33c0ce0 like that]. It may help to prevent commits like [https://github.com/django/django/commit/a4a4b139cd1b2e5dd7a05f195c8990f4d94e882d this one]. | nobody | bak1an | 0 | 1 | 0 | 0 | 0 | 0 | |
19555 | 2013-01-02 20:16:42 | 2013-02-08 08:22:56 | 2022-03-06 04:11:36.069466 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | tutorial pt 1 - update year for examples to work | last part executes: >>> Choice.objects.filter(poll__pub_date__year=2012) and now we're in 2013 :) happy new year! salú rela. | nobody | rodrigorosa.lg@gmail.com | year | 1 | 1 | 0 | 0 | 0 | 0 |
19562 | 2013-01-03 21:05:56 | 2013-02-08 08:22:54 | 2022-03-06 04:11:37.152615 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | Documentation: How Django stores passwords out of date | In "Password management in Django" documentation page https://docs.djangoproject.com/en/1.5/topics/auth/passwords/ , section "How Django stores passwords" it says: "The password attribute of a User object is a string in this format: algorithm$hash" This is out of date (since v1.4?) It should say something like: "The password attribute of a User object is a string in this format: algorithm$iterations$salt$hash" , where iterations is the work factor. Thanks | ptone | startup.canada@gmail.com | 0 | 0 | 0 | 0 | 0 | 0 | |
19571 | 2013-01-06 21:18:34 | 2013-02-08 08:22:56 | 2022-03-06 04:11:38.564455 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.5-beta-1 | fixed | Django 1.5 Tutorial Need to update Version on First page | https://docs.djangoproject.com/en/1.5/intro/tutorial01/#the-development-server it says: Validating models... 0 errors found. Django version 1.4, using settings 'mysite.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. It should say version 1.5 instead of 1.4 | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |
19573 | 2013-01-07 21:22:31 | 2013-02-08 08:22:58 | 2022-03-06 04:11:38.876448 | Accepted | closed | contrib.auth | Cleanup/optimization | Release blocker | 1.5-beta-1 | fixed | It is not possible to overwrite field label in AuthenticationForm | If I inherit "django.contrib.auth.forms.AuthenticationForm" and specify my custom "username" field {{{ username = forms.CharField(label=_("Name"), max_length=75) }}} it ignores my label. The reason is the last line of the init method, which set the label. https://github.com/django/django/commit/70a0de37d132e5f1514fb939875f69649f103124#L10R164 There could be an if statement: {{{ if not self.fields['username'].label: self.fields['username'].label = capfirst(self.username_field.verbose_name) }}} | slurms | jan.munclinger@gmail.com | 0 | 1 | 0 | 0 | 0 | 0 | |
19576 | 2013-01-08 04:39:36 | 2013-02-08 08:22:56 | 2022-03-06 04:11:39.335369 | Ready for checkin | closed | Python 3 | Cleanup/optimization | Normal | dev | fixed | Use `six.with_metaclass` uniformously accross code base | Sometimes `object` is inherited twice when it's not needed. Simple patch that passes on Python 2.7.3 and 3.2 with SQlite to be uploaded. | nobody | charettes | six | 0 | 1 | 0 | 0 | 0 | 0 |
19577 | 2013-01-08 13:50:31 | 2013-02-08 08:23:07 | 2022-03-06 04:11:39.503065 | Ready for checkin | closed | Documentation | Bug | Normal | 1.4 | fixed | admin doc may encourage bad practices | On https://docs.djangoproject.com/en/1.4/ref/contrib/admin/ two places example code demonstrate allow_tags=True in order to return HTML fragments containing <span> tags. Inside these tags data (self.first_name and self.last_name) is not escaped/quoted. As such example code often is copy/pasted it probably should reflect "best practices"? | nobody | foo@pogostick.net | 0 | 1 | 0 | 0 | 0 | 0 | |
19585 | 2013-01-09 16:58:56 | 2013-02-08 08:22:59 | 2022-03-06 04:11:40.765340 | Ready for checkin | closed | HTTP handling | Bug | Release blocker | dev | fixed | Unable to load cookie values as a dict | Starting from the `unicode_literals` patch, we lost the possibility to load a cookie value by passing a dict to the `load()` method, as allowed by the Python docs (http://docs.python.org/2/library/cookie.html#Cookie.BaseCookie.load). We shouldn't inconditionally transform the `rawdata` parameter in a string. | nobody | claudep | regression | 0 | 1 | 0 | 0 | 0 | 0 |
19586 | 2013-01-09 17:45:23 | 2013-02-08 08:22:58 | 2022-03-06 04:11:40.915947 | Unreviewed | closed | Documentation | Bug | Normal | dev | fixed | URL_VALIDATOR_USER_AGENT is said to be deprecated, but has actually been removed | The docs (https://docs.djangoproject.com/en/dev/ref/settings/#url-validator-user-agent) say that URL_VALIDATOR_USER_AGENT has been deprecated, but it's actually been removed. There's at least two instances where that caused trouble; it was mentioned once ([https://docs.djangoproject.com/en/dev/ref/settings/#url-validator-user-agent]) on the django-users mailing list. I stumbled upon it trying to setup django-oscar (http://oscarcommerce.com/), a shop solution for Django. It fails trying to import the setting. My preferred way of fixing it would be a DeprecationMessage, but I assume due to the looming release deadline, an update to the docs is more appropriate. | nobody | m@maikhoepfel.de | 1 | 0 | 0 | 0 | 0 | 0 | |
19588 | 2013-01-10 09:22:20 | 2013-02-08 08:22:58 | 2022-03-06 04:11:41.221185 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | UserManager documentation is missing create_superuser | the method '''create_superuser''' is missing from '''UserManager''' documentation. [https://docs.djangoproject.com/en/dev/ref/contrib/auth/#manager-methods here-1] instead there is '''make_random_password''' which comes from '''BaseUserManager''' (and is already documented there - [https://docs.djangoproject.com/en/dev/topics/auth/customizing/#django.contrib.auth.models.BaseUserManager here-2]) here-1: https://docs.djangoproject.com/en/dev/ref/contrib/auth/#manager-methods here-2: https://docs.djangoproject.com/en/dev/topics/auth/customizing/#django.contrib.auth.models.BaseUserManager | nobody | minddust | 1 | 1 | 0 | 0 | 0 | 0 | |
19596 | 2013-01-11 12:26:24 | 2013-02-08 08:23:05 | 2022-03-06 04:11:42.463333 | Ready for checkin | closed | contrib.auth | Bug | Release blocker | 1.5-beta-1 | fixed | Django admin should use "_default_manager" not "objects" on csutom auth model class. | My case: I created custom users model "MyUser" and set it as auth model in settings file. class MyUser(MyAbstractBaseModel, AbstractBaseUser, PermissionsMixin): ... my_objects = UserManager() After login to Admin Panel I've got an error: "type object 'MyUser' has no attribute 'objects'" Moreover "_default_manager" is pointing to "UserManager" in MyAbstractBaseModel. So, in my opinion Admin Panel should use _default_manager, not "objects". Regards. | nobody | anonymous | auth, objects | 0 | 1 | 0 | 0 | 0 | 0 |
19597 | 2013-01-11 13:31:21 | 2013-02-08 08:23:03 | 2022-03-06 04:11:42.616864 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | jquery.js recommendations; minified jQuery not documented | The admin docs could be clearer about loading jquery.js. Also, https://github.com/django/django/blob/master/django/contrib/admin/options.py#L401 isn't documented. Pull request addressing both: https://github.com/django/django/pull/639 | nobody | EvilDMP | 0 | 1 | 0 | 0 | 0 | 0 | |
19605 | 2013-01-13 10:44:41 | 2013-02-08 08:23:02 | 2022-03-06 04:11:43.860982 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.5-beta-1 | fixed | Unnecessary import in code examples from the docs | The next sample fragment has unnecessary imports of 'url' and 'include': {{{ from django.conf.urls import patterns, url, include urlpatterns = patterns('', (r'^articles/2003/$', 'news.views.special_case_2003'), (r'^articles/(\d{4})/$', 'news.views.year_archive'), (r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'), (r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'), ) }}} The link: https://docs.djangoproject.com/en/1.5/topics/http/urls/#example | nobody | sergzach | 1 | 0 | 0 | 0 | 0 | 0 | |
19610 | 2013-01-14 17:04:52 | 2013-02-08 08:23:06 | 2022-03-06 04:11:44.676732 | Ready for checkin | closed | Documentation | Cleanup/optimization | Normal | 1.4 | fixed | Include enctype in example forms | On this page: https://docs.djangoproject.com/en/dev/topics/forms/ It took me ages to figure out the reason files weren't uploading was because I'd left out enctype="multipart/form-data" from my <form> tag in my template. I suggest changing the template examples from: {{{ <form action="/contact/" method="post">{% csrf_token %} {{ form.as_p }} <input type="submit" value="Submit" /> </form> }}} to: {{{ <form action="/contact/" method="post" enctype="multipart/form-data">{% csrf_token %} {{ form.as_p }} <input type="submit" value="Submit" /> </form> }}} | nobody | will@swproductions.co.uk | 1 | 1 | 0 | 0 | 0 | 0 | |
19614 | 2013-01-15 13:06:41 | 2013-02-08 08:23:03 | 2022-03-06 04:11:45.287496 | Accepted | closed | Documentation | Bug | Normal | 1.5-beta-1 | fixed | Error in docs example | Small error in example about limiting access to logged-in users by the raw way from Django Docs (https://docs.djangoproject.com/en/1.5/topics/auth/default/#the-raw-way): {{{ from django.shortcuts import render def my_view(request): if not request.user.is_authenticated(): return render('myapp/login_error.html') }}} The render function require Request argument: https://docs.djangoproject.com/en/1.5/topics/http/shortcuts/#render | aaugustin | Dima Pravdin | 0 | 0 | 0 | 0 | 0 | 0 | |
19628 | 2013-01-18 07:00:37 | 2013-02-08 08:23:04 | 2022-03-06 04:11:47.466203 | Unreviewed | closed | Documentation | Uncategorized | Normal | 1.5-beta-1 | fixed | Add to the documentation note about AUTH_USER_MODEL | It's problem, that if I write the User model striсtly for documentation, I will get a validation error: {{{ auth.user: Model has been swapped out for 'myapp.MyUser' which has not been installed or is abstract. }}} It's not enough just to set {{{ AUTH_USER_MODEL = 'myapp.MyUser' }}} Beside that it's necessary add the 'myapp' in INSTALLED_APPS, but it's not specified in the documentation. Sorry, if it's specified but I didn't find it :) | nobody | dpravdin | 1 | 0 | 0 | 0 | 0 | 0 | |
19632 | 2013-01-18 18:20:57 | 2013-02-08 08:23:04 | 2022-03-06 04:11:48.103631 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.4 | fixed | Sample code is wrong in page: "Using the Django authentication system" | In https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests {{{ from django.contrib.auth.decorators import user_passes_test def email_check(user): return '@example.com' in request.user.email @user_passes_test(email_check) def my_view(request): ... }}} should read {{{ from django.contrib.auth.decorators import user_passes_test def email_check(request): return '@example.com' in request.user.email @user_passes_test(email_check) def my_view(request): ... }}} | charettes | grossmanandy@bfusa.com | 1 | 1 | 0 | 0 | 1 | 0 | |
19633 | 2013-01-19 10:08:56 | 2013-02-08 08:23:06 | 2022-03-06 04:11:48.269554 | Accepted | closed | Documentation | Bug | Normal | dev | fixed | Docs should discourage using gunicorn's Django integration | Since 1.4 introduced the new project layout, Django is a good WSGI citizen, and is best deployed as a WSGI app (gunicorn's default mode). Quoting [http://docs.gunicorn.org/en/latest/run.html#gunicorn-django gunicorn's docs]: > If you run Django 1.4 or newer, it’s highly recommended to simply run your application with the WSGI interface using the gunicorn command. [https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/gunicorn/#using-gunicorn-s-django-integration Django's docs] should be updated to reflect this. | nobody | aaugustin | 0 | 1 | 0 | 0 | 0 | 0 | |
19639 | 2013-01-20 07:28:56 | 2013-02-08 08:23:07 | 2022-03-06 04:11:49.301449 | Accepted | closed | Documentation | Uncategorized | Normal | dev | fixed | Choices in model fields best practices consistency | As reported [https://code.djangoproject.com/ticket/18062#comment:9 here], [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/#model-style models coding style] concerning choices is not consistent with the best practices introduced by #18062. | nobody | charettes | 1 | 0 | 0 | 0 | 0 | 0 | |
19640 | 2013-01-20 18:35:28 | 2013-02-08 08:23:05 | 2022-03-06 04:11:49.456562 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | inlineformset_factory is not documented well like other formset_factories | inlineformset_factory is poorly documented. https://docs.djangoproject.com/en/dev/ref/forms/models/#django.forms.models.modelformset_factory lists modelform_factory and modelformset_factory, but not inlineformset_factory. We should probably add something in the line of: inlineformset_factory(parent_model, model, form=ModelForm, formfield_callback=None, formset=BaseInlineFormSet, fk_name=None, extra=3, can_delete=True, can_order=False, max_num=None, fields=None, exclude=None) Note that inlineformset_factory uses modelformset_factory() and marks can_delete=True, extra=3. In addition, it uses BaseInlineFormSet by default. If your model has more than one ForeignKey to the parent_model, you must specify a fk_name. | nobody | wim@go2people.nl | inlineformset_factory documentation | 1 | 1 | 0 | 0 | 0 | 0 |
19662 | 2013-01-24 17:16:36 | 2013-02-08 08:23:15 | 2022-03-06 04:11:53.066085 | Accepted | closed | contrib.auth | Bug | Release blocker | 1.5-beta-1 | fixed | Explain correct `authenticate` usage with custom user model. | If using a custom user model, with eg `USERNAME_FIELD='email'`, then it is non-obvious if the correct usage is `authenticate(username=..., password=...)` or `authenticate(email=..., password=...)` Bit of an easy stumbling point, and it won't be obvious to the developer why login is failing, so we should really note the usage here. This was the best phrasing I could come up with, but happy to take other suggestions. Marking as a bug, because I'd consider this a documentation bug, until resolved. | nobody | tomchristie | 0 | 1 | 0 | 0 | 0 | 0 | |
19683 | 2013-01-28 15:19:27 | 2013-02-08 08:23:08 | 2022-03-06 04:11:56.382951 | Accepted | closed | Documentation | Bug | Normal | 1.4 | fixed | A minor mistake? | https://docs.djangoproject.com/en/1.4/topics/signing/ In this page, which is about signing, enumerates several examples about how to use it. When it comes to that handling Exception, to be specific, {{{ >>> value += 'm' >>> try: ... original = signer.unsign(value) ... except signing.BadSignature: ... print "Tampering detected!" }}} I found that these lines failed, the error shows signing.BadSignature is not defined, I tested a while, and then I knew, {{{ from django.core import signing }}} is required. The example miss that. I don't know if that count as a mistake. Besides, the information about previous line is so scarce in reference, do I need to check the source code? | nobody | sunsongxp@gmail.com | signing | 0 | 0 | 0 | 0 | 0 | 0 |
19690 | 2013-01-29 13:55:51 | 2013-02-08 08:23:10 | 2022-03-06 04:11:57.464427 | Ready for checkin | closed | Documentation | Bug | Normal | dev | fixed | Class in ajax example doesn't inherit from imported SingleObjectTemplateResponseMixin | The code sample found here https://docs.djangoproject.com/en/dev/topics/class-based-views/generic-editing/#ajax-example displays the issue. Basically, SingleObjectTemplateResponseMixin is imported but AjaxableResponseMixin doesn't inherit from it. | lucianu | lucianu | 0 | 0 | 0 | 0 | 0 | 0 | |
19692 | 2013-01-29 18:04:44 | 2013-02-08 08:23:09 | 2022-03-06 04:11:57.782054 | Accepted | closed | Documentation | Cleanup/optimization | Release blocker | dev | fixed | Replace HttpResponse.mimetype (deprecated) with content_type in doc examples | I'm assuming we're also deprecating the `mimetype` argument on `TemplateResponse` and `SimpleTemplateResponse`? Alternatively, we'd have to add a shim to continue supporting `mimetype` for these classes once `mimetype` is removed from `HttpResponse.__init__`. | aaugustin | timo | 0 | 1 | 0 | 0 | 0 | 0 | |
19700 | 2013-01-30 15:31:32 | 2013-02-08 08:23:11 | 2022-03-06 04:11:59.070412 | Unreviewed | closed | Documentation | New feature | Normal | 1.4 | fixed | BoundField documentation: original field | Please add in the documentation a mention on how to get the original field of a BoundField. Locations: https://docs.djangoproject.com/en/dev/topics/forms/#looping-over-the-form-s-fields https://docs.djangoproject.com/en/dev/ref/forms/api/#django.forms.BoundField In these two locations it would be very useful to have a mention like: -- '''{{ field.field }}''' The original field instance, as added to the form object, e.g. a forms.CharField instance. -- Details: When adding field programatically to a form, it comes naturally to want to add extra fields to that object and then read them back in the template. However, as the docs clearly state, iterating over a (bound) form returns BoundFields instead of the original Field objects put into the form. There is no mention in the docs how to get to the original field instance in the template. Cheers! | nobody | tga | 1 | 0 | 0 | 0 | 0 | 0 | |
19706 | 2013-01-31 00:47:49 | 2013-02-08 08:23:14 | 2022-03-06 04:11:59.993374 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.5-beta-1 | fixed | Tutorial amendments | I've worked through the first four tutorials again, and made some suggestions. https://github.com/django/django/pull/688/files | timo | EvilDMP | 0 | 1 | 1 | 0 | 0 | 0 | |
19708 | 2013-01-31 13:49:51 | 2013-02-08 08:23:09 | 2022-03-06 04:12:00.305394 | Accepted | closed | Uncategorized | Bug | Normal | 1.4 | fixed | django.utils.timezone.override helper may raise AttributeError | Here's a simple test case: {{{ >>> from django.utils import timezone >>> timezone.deactivate() >>> with timezone.override(None): ... pass ... Traceback (most recent call last): File "<console>", line 2, in <module> File "/django/django/utils/timezone.py", line 204, in __exit__ del _active.value AttributeError: value }}} This happens in {{{__exit__()}}} method of override helper when current timezone is deactivated and we try to use override with None argument (which is valid - it means that we want to deactivate current timezone). | aaugustin | rafales | timezone utils | 0 | 0 | 0 | 0 | 0 | 0 |
19714 | 2013-02-01 05:27:44 | 2013-02-08 08:23:09 | 2022-03-06 04:12:01.158345 | Accepted | closed | Documentation | Bug | Release blocker | 1.5-beta-1 | fixed | Documentation for TemplateView incorrectly refers to "params" context variable. | The documentation for TemplateView at [https://github.com/django/django/blob/master/docs/ref/class-based-views/base.txt docs/ref/class-based-views/base.txt] states that TemplateView provides a "params" context variable, which is a dictionary of the URL matched groups. However, since [https://github.com/django/django/commit/f04bb6d798b07aa5e7c1d99d700fa6ddc7d39e62 commit f04bb6d], TemplateView no longer creates a "params" variable, instead passing the matched groups directly, e.g. for the URL pattern `r'/(?<slug>[^\]+/'`, the template receives `{{ email }}` instead of `{{ params.email }}`, as suggested by the documentation. | claudep | Aramgutang | TemplateView params | 1 | 0 | 0 | 0 | 0 | 0 |
19725 | 2013-02-02 04:38:10 | 2013-02-08 08:23:12 | 2022-03-06 04:12:02.900101 | Accepted | closed | contrib.auth | Bug | Release blocker | 1.5-beta-1 | fixed | `createsuperuser` command fails with custom User model | If using a custom User model with non-ascii field label, then `createsuperuser` command fails. {{{ class MyUser(AbstractBaseUser): email = models.EmailField( u'メールアドレス', max_length=255, unique=True, db_index=True) # ... }}} {{{ $ python manage.py createsuperuser UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-6: ordinal not in range(128) }}} | nobody | michisu | 1 | 0 | 0 | 0 | 0 | 0 | |
19734 | 2013-02-04 16:24:49 | 2013-02-08 08:23:13 | 2022-03-06 04:12:04.261603 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | missing values in DATETIME_INPUT_FORMATS docs | here [https://docs.djangoproject.com/en/dev/ref/settings/#datetime-input-formats 1] are some values missing. current code: {{{#!python DATETIME_INPUT_FORMATS = ( '%Y-%m-%d %H:%M:%S', # '2006-10-25 14:30:59' '%Y-%m-%d %H:%M:%S.%f', # '2006-10-25 14:30:59.000200' '%Y-%m-%d %H:%M', # '2006-10-25 14:30' '%Y-%m-%d', # '2006-10-25' '%m/%d/%Y %H:%M:%S', # '10/25/2006 14:30:59' '%m/%d/%Y %H:%M:%S.%f', # '10/25/2006 14:30:59.000200' '%m/%d/%Y %H:%M', # '10/25/2006 14:30' '%m/%d/%Y', # '10/25/2006' '%m/%d/%y %H:%M:%S', # '10/25/06 14:30:59' '%m/%d/%y %H:%M:%S.%f', # '10/25/06 14:30:59.000200' '%m/%d/%y %H:%M', # '10/25/06 14:30' '%m/%d/%y', # '10/25/06' ) }}} current doc: {{{#!python DATETIME_INPUT_FORMATS = ( '%Y-%m-%d %H:%M:%S', '%Y-%m-%d %H:%M', '%Y-%m-%d', '%m/%d/%Y %H:%M:%S', '%m/%d/%Y %H:%M', '%m/%d/%Y', '%m/%d/%y %H:%M:%S', '%m/%d/%y %H:%M', '%m/%d/%y' ) }}} 1: [https://docs.djangoproject.com/en/dev/ref/settings/#datetime-input-formats] | charettes | minddust | 1 | 0 | 0 | 0 | 0 | 0 | |
19743 | 2013-02-04 22:04:44 | 2013-02-08 08:23:13 | 2022-03-06 04:12:05.906661 | Ready for checkin | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | Document limitations of django.contrib.auth | django.contrib.auth aims to be very generic and doesn't provide some features commonly found in web authentication systems: - password strength checking: requirements depend very much on the context. - throttling of login attempts: possible with a custom auth backend, for example https://github.com/brutasse/django-ratelimit-backend (I haven't audited that code) - external auth providers: possible with a custom auth backend, there are several third-party apps providing this feature. The documentation should point out that these features aren't implemented to raise awareness. | nobody | aaugustin | 0 | 1 | 0 | 0 | 0 | 0 | |
19745 | 2013-02-05 11:00:14 | 2013-02-08 08:23:13 | 2022-03-06 04:12:06.225824 | Ready for checkin | closed | contrib.auth | Bug | Release blocker | 1.5-beta-1 | fixed | Wrong prompt for `createuser` management command (<django.utils.functional.__proxy__ object at ...>) | Using a fresh checkout, I created a new project, using all the default settings (except for DATABASES). When running `syncdb` for the first time (or running `createsuperuser` anytime), the prompts are wrong. Here's what it looks like with python 2.7: {{{ $ python manage.py createsuperuser <django.utils.functional.__proxy__ object at 0x7fe4c341a850> (leave blank to use 'bmispelon'): newuser <django.utils.functional.__proxy__ object at 0x29d8c10>: foo@example.com Password: Password (again): Superuser created successfully. $ python manage.py createsuperuser <django.utils.functional.__proxy__ object at 0x7f7717aed850> (leave blank to use 'bmispelon'): newuser Error: That <django.utils.functional.__proxy__ object at 0x1d45ad0> is already taken. <django.utils.functional.__proxy__ object at 0x7f7717aed850> (leave blank to use 'bmispelon'): ^C Operation cancelled. }}} By comparison, here is what it looks like using python 3.2 (correct output): {{{ $ python3 manage.py createsuperuser Username (leave blank to use 'bmispelon'): newuser2 Email address: foo@example.com Password: Password (again): Superuser created successfully. $ python3 manage.py createsuperuser Username (leave blank to use 'bmispelon'): newuser2 Error: That username is already taken. Username (leave blank to use 'bmispelon'): ^C Operation cancelled. }}} There are three issues here: 1) The name of the username field is displayed wrong 2) The name of the email field is displayed wrong 3) The error message when using an existing username is wrong. The code in question is located in `django/contrib/auth/management/commands/createsuperuser.py`. The first two were introduced by commit 55c585f1c7a9c91308193f0648caf36203174564 while the third one was introduced with an older one: b3b3db3d954a5226f870a0b4403343c78efae8dc The issue can be fixed by wrapping the strings being formatted with six.u, like so: {{{ from django.utils.six import u # ... input_msg = u("%s (leave blank to use '%s')") % … | nobody | bmispelon | createuser repr py3 | 0 | 1 | 0 | 1 | 0 | 0 |
19756 | 2013-02-06 17:38:13 | 2013-02-08 08:23:14 | 2022-03-06 04:12:08.164254 | Unreviewed | closed | Documentation | Uncategorized | Normal | 1.4 | fixed | .add or .create on ManyToManyField doc page | https://docs.djangoproject.com/en/1.4/topics/db/examples/many_to_many/ "Add a Publication directly via publications.add by using keyword arguments: >>> new_publication = a2.publications.create(title='Highlights for Children')" Which is it, .add or .create? | nobody | anonymous | 1 | 0 | 0 | 0 | 0 | 0 | |
19776 | 2013-02-08 01:22:09 | 2013-02-08 08:30:17 | 2022-03-06 04:12:13.565482 | Unreviewed | closed | Testing framework | Uncategorized | Normal | 1.5-beta-1 | fixed | test fails in git stable/1.5.x branch | This test wasn't failing just the other day, so probably only just introduced. ERROR: test_authenticate (django.contrib.auth.tests.auth_backends.CustomUserModelBackendAuthenticateTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/rob/Projects/django15-env/eve/venv/local/lib/python2.7/site-packages/django/contrib/auth/tests/auth_backends.py", line 205, in test_authenticate authenticated_user = authenticate(email='test@example.com', password='test') NameError: global name 'authenticate' is not defined | nobody | robvdl | 0 | 0 | 0 | 0 | 0 | 0 | |
19777 | 2013-02-08 01:52:04 | 2013-02-08 02:46:56 | 2022-03-06 04:12:13.734616 | Unreviewed | closed | Core (Other) | Bug | Normal | dev | wontfix | Casting a SimpleLazyObject to an int fails | Should be pretty self explanatory. We noticed the bug when passing `request.user` into a filter like: {{{ Model.objects.filter(user=request.user) }}} Since Django is attempting to coerce the object to an int, it fails on the SimpleLazyObject yielding: {{{ TypeError: int() argument must be a string or a number, not 'SimpleLazyObject' }}} The error can be reproduced simple by doing: {{{ class Foo(object): __int__ = lambda self: 1 int(SimpleLazyObject(Foo))) }}} See https://github.com/django/django/pull/706 for a patch. | nobody | mattrobenolt | functional simplelazyobject | 0 | 1 | 0 | 0 | 0 | 0 |
19779 | 2013-02-08 10:21:58 | 2013-02-08 15:37:45 | 2022-03-06 04:12:14.134185 | Ready for checkin | closed | contrib.redirects | Bug | Release blocker | 1.5-rc-1 | fixed | Regression in redirects middleware | After upgrading docs.djangoproject.com to 1.5 rc 1 static files fail to load. {{{ Environment: Request Method: GET Request URL: http://localhost:8000/s/css/base.css/ Django Version: 1.5c1 Python Version: 2.7.2 Installed Applications: ['docs', 'haystack'] Installed Middleware: ['djangosecure.middleware.SecurityMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.common.CommonMiddleware', 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware', 'django.contrib.redirects.middleware.RedirectFallbackMiddleware'] Traceback: File "/Users/myk/.virtualenvs/dp.com/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response 187. response = middleware_method(request, response) File "/Users/myk/.virtualenvs/dp.com/lib/python2.7/site-packages/django/contrib/redirects/middleware.py" in process_response 13. r = Redirect.objects.get(site__id__exact=current_site.id, old_path=path) Exception Type: AttributeError at /s/css/base.css/ Exception Value: 'RequestSite' object has no attribute 'id' }}} This regression was introduced in 6c2faaceb0482267cec19da0ff432984028f9d0c. I'm not sure it's a good idea to use `get_current_site()`, which can return a `RequestSite`, in code that obviously needs a `Site`. Possible solutions: - rollback the change in the redirect middleware - give `RequestSite` `pk` and `id` attributes returning `settings.SITE_ID` | nobody | aaugustin | 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 );