tickets
45 rows where "created" is on date 2008-09-01
This data as json, CSV (advanced)
Suggested facets: changetime, stage, component, type, version, resolution, owner, has_patch, needs_tests, needs_docs, changetime (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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8741 | 2008-09-01 02:30:13 | 2011-09-28 16:12:17 | 2022-03-06 03:43:03.156317 | Unreviewed | closed | Uncategorized | dev | fixed | backwards-incompatible: urlresolvers.reverse no longer silently accepts unused args | Pre-[8760], urlresolvers.reverse would silently accept "extra" args and return a matched URL that didn't need the arg. Post-[8760], all args must be matched in the URL pattern. The newer behavior is probably more correct, but this is a backwards-incompatible change for anyone who was relying on the prior behavior. If the correct thing here is to document this on the BackwardsIncompatibleChanges page, I'm happy to do so - just checking to be sure this isn't a bug, since the [8760] rewrite was advertised as "fully backwards-compatible." | mtredinnick | carljm | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8742 | 2008-09-01 02:56:08 | 2009-02-25 21:25:55 | 2022-03-06 03:43:03.317645 | Unreviewed | closed | Uncategorized | dev | invalid | Windows support of FastCGI feature | Django FastCGI cannot be used on Windows, and possibly other non-Unix environments. Currently the FastCGI feature of Django (manage.py runfcgi) relies on the Python library 'flup', which relies on Unix-only socket functions (socket.socketpair(), socket.fromfd(), etc.) making it impossible to use the FastCGI feature of Django on non-Unix envs like Windows, and hence, making it impossible to serve Django with non-Apache (non-mod_python) httpds like lighttpd on non-Unix envs. Possible solutions: The function socketpair() is unofficially implemented on Windows by a recipe. (http://code.activestate.com/recipes/525487/) Committing this patch to the flup project is not a hard work. However, the function fromfd() has nothing like that. There is a patch enabling its Windows use (http://bugs.python.org/issue1378) but the patch is not yet applied on the Windows release, even on Python 2.6b2. Rewriting the FastCGI feature with python-fastcgi (http://pypi.python.org/pypi/python-fastcgi) could be a more work than flup, but then the feature can support Windows. Unix environments, especially GNU/Linux, is of course better than Windows to be used as a web server, but there are some situations where Windows and FastCGI have to be used. It would be good to have Django FastCGI available on Windows. | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8743 | 2008-09-01 04:51:00 | 2011-09-28 16:12:17 | 2022-03-06 03:43:03.469062 | Unreviewed | closed | Translations | dev | fixed | Tiny patch for Brazilian localization of djangjs.po | The patch improves the header and fix one string. | nobody | Guilherme M. Gondim <semente@taurinus.org> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8744 | 2008-09-01 05:38:34 | 2011-09-28 16:12:17 | 2022-03-06 03:43:03.608957 | Accepted | closed | Forms | dev | duplicate | __init__() got an unexpected keyword argument 'min_value' | I updated to [8373] and got this error. It went away when I commented out {{{admin.autodiscover}}}, but I'm sure it's not just that that's affected. Brian Rosner mentioned that it might have to do with some changes that Jacob had made earlier today. Here's my traceback. {{{ Traceback: File "/usr/lib/python2.5/site-packages/django/core/handlers/base.py" in get_response 77. request.path_info) File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py" in resolve 178. for pattern in self.urlconf_module.urlpatterns: File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py" in _get_urlconf_module 197. self._urlconf_module = __import__(self.urlconf_name, {}, {}, ['']) File "/var/www/projectrenova/../projectrenova/urls.py" in <module> 11. admin.autodiscover() File "/usr/lib/python2.5/site-packages/django/contrib/admin/__init__.py" in autodiscover 40. __import__("%s.admin" % app) File "/var/www/projectrenova/applications/blog/admin.py" in <module> 19. admin.site.register(Entry, EntryAdmin) File "/usr/lib/python2.5/site-packages/django/contrib/admin/sites.py" in register 91. validate(admin_class, model) File "/usr/lib/python2.5/site-packages/django/contrib/admin/validation.py" in validate 25. validate_base(cls, model) File "/usr/lib/python2.5/site-packages/django/contrib/admin/validation.py" in validate_base 180. check_formfield(cls, model, opts, "fieldsets[%d][1]['fields']" % idx, field) File "/usr/lib/python2.5/site-packages/django/contrib/admin/validation.py" in check_formfield 261. fields = fields_for_model(model) File "/usr/lib/python2.5/site-packages/django/forms/models.py" in fields_for_model 145. formfield = formfield_callback(f) File "/usr/lib/python2.5/site-packages/django/forms/models.py" in <lambda> 124. def fields_for_model(model, fields=None, exclude=None, formfield_callback=lambda f: f.formfield()): File "/usr/lib/python2.5/site-packages/djang… | jacob | bryanveloso | admin, TypeError, 1.0-blocker | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8745 | 2008-09-01 05:47:03 | 2008-09-01 13:24:59 | 2022-03-06 03:43:03.768046 | Unreviewed | closed | Translations | dev | fixed | czech translation update | There were some new strings in the last few days. This patch should translate them. | nobody | Petr Marhoun <petr.marhoun@gmail.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8746 | 2008-09-01 06:21:41 | 2011-09-28 16:12:21 | 2022-03-06 03:43:03.914319 | Ready for checkin | closed | contrib.admin | dev | fixed | Data entered in raw_id_fields needs better checking | I stumbled across this while trying to verify the patch for #8648. If you have a !ForeignKey listed in raw_id_fields and enter an incorrect value in it, the admin code will likely thrown an exception. In the case I ran across in #8648 the incorrect value is an integer with no associated related object. The admin code attempts to re-display the form with an error message about the value being invalid, but the raw id widget in an attempt to be helpful and display the printable representation of the object referred to in the form generates an exception when it assumes it can get the associated object. A 2nd way to cause a (different) exception is to enter something that isn't an integer at all. In this case I got: {{{ Environment: Request Method: POST Request URL: http://lbox:8000/admin/crossword/clues/2518/ Django Version: 1.0-beta_2-SVN-8769 Python Version: 2.5.1 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.admin', 'django.contrib.sites', 'django.contrib.humanize', 'xword.crossword'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware') Traceback: File "/home/kmt/tmp/django/trunk/django/core/handlers/base.py" in get_response 86. response = callback(request, *callback_args, **callback_kwargs) File "/home/kmt/tmp/django/trunk/django/contrib/admin/sites.py" in root 173. return self.model_page(request, *url.split('/', 2)) File "/home/kmt/tmp/django/trunk/django/views/decorators/cache.py" in _wrapped_view_func 44. response = view_func(request, *args, **kwargs) File "/home/kmt/tmp/django/trunk/django/contrib/admin/sites.py" in model_page 192. return admin_obj(request, rest_of_url) File "/home/kmt/tmp/django/trunk/django/contrib/admin/options.py" in __call__ 196. … | nobody | kmtracey | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8747 | 2008-09-01 06:29:23 | 2009-05-07 14:22:10 | 2022-03-06 03:43:04.069180 | Accepted | closed | Database layer (models, ORM) | dev | fixed | Importing models from within `__init__.py` prevents syncdb from creating tables | I have a very simple app with this structure: {{{ myapp/ __init__.py models.py }}} That app wouldn't create its tables when running `syncdb`. After poking around I realised that it was because within the `__init__.py` I was importing the models: {{{ # __init__.py from models import * ... }}} So, my question: is that a case of "don't do that", and if so is that worth specifying in the documentation? It took me quite a while to debug that, and I found nothing obvious in the docs to help me (if there is, please point me to it). | nobody | julien | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8748 | 2008-09-01 07:44:17 | 2009-03-31 23:20:52 | 2022-03-06 03:43:04.217273 | Accepted | closed | contrib.admin | dev | fixed | Problems in admin/form with primary keys in an abstract superclass | My models.py has an abstract superclass, which defines (beside other things) the primary key (as a UID): {{{ class StdHeader(models.Model): """ Standard header. Each database relation starts with these attributes. """ pkey = models.CharField(max_length=40, primary_key=True, editable=True) # primary key; an UID def save(self): """update of all std header attributes""" #... if self.pkey == None or len(self.pkey)==0: self.pkey = uids.uid(self.__class__.__name__) super(StdHeader,self).save() class Meta: abstract = True }}} Now: in later SVN versions (specifically in SVN 8785) there are "KeyErrors" in dependend Models: I.E: {{{ class Person(StdHeader): familyname = models.CharField(_('Familyname'),max_length=30) #... class Address(StdHeader): person = models.ForeignKey(Person, null=True, to_field="pkey") street = models.CharField(max_length=40, blank=True) #... }}} Adding a record to Person results in: {{{ File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/loader_tags.py", line 123, in render return t.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 176, in render return self.nodelist.render(context) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/__init__.py", line 768, in render bits.append(self.render_node(node, context)) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/debug.py", line 81, in render_node raise wrapped TemplateSyntaxError: Caught an exception while rendering: "Key 'pkey' not found in Form" Original Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/template/d… | nobody | trott@meditec-gmbh.com | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8749 | 2008-09-01 08:52:36 | 2011-09-28 16:12:21 | 2022-03-06 03:43:04.370678 | Ready for checkin | closed | contrib.admin | dev | fixed | contrib.auth admin change password template breadcrumb differs | Clicking the change password link from a page with a breadcrumb like: {{{ Home › Auth › Users › chris }}} ...leads to a breadcrumb looking like: {{{ Home › Users › chris › Change password }}} Easy fix... | kkubasik | SmileyChris | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8750 | 2008-09-01 08:55:15 | 2011-09-28 16:12:17 | 2022-03-06 03:43:04.531207 | Unreviewed | closed | Translations | dev | fixed | Last update for Dutch Django 1.0 translations | Translated the last few strings that where recently added after string freeze. | nobody | Rudolph | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8751 | 2008-09-01 09:48:37 | 2011-09-28 16:12:17 | 2022-03-06 03:43:04.687210 | Accepted | closed | Translations | dev | fixed | Simplified Chinese django.po updated | Please check it as attached. | nobody | hutuworm | 0 | 1 | 1 | 0 | 0 | 0 | |||
| 8752 | 2008-09-01 09:49:57 | 2011-09-28 16:12:21 | 2022-03-06 03:43:04.841645 | Accepted | closed | Contrib apps | dev | fixed | auth password tests fail on non-english sites | The password tests in the contrib.auth app rely on a specific string to be in the output, but if the LANGUAGE_CODE setting is not english, those strings will appear translated in the output, causing the tests to fail. | nobody | Koen Biermans <koen.biermans@werk.belgie.be> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8753 | 2008-09-01 09:55:49 | 2011-09-28 16:12:17 | 2022-03-06 03:43:04.999613 | Accepted | closed | Documentation | dev | fixed | Change "New in ... version" to ".. version[added|changed]" | This is just a reminder that the "New in .... version" notices in docs/ should be replaced by ".. version[added|changed]:: 1.0" directives. Fixing patch is on my docs-1.0 branch [http://www.marcfargas.com/gitweb/?p=django.git;a=commitdiff;h=docs-1.0;hp=master colorful diff] and [http://www.marcfargas.com/gitweb/?p=django.git;a=commitdiff_plain;h=docs-1.0;hp=master raw diff] . Don't forget! ;) | telenieko | telenieko | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8754 | 2008-09-01 10:00:11 | 2015-01-07 18:31:40 | 2022-03-06 03:43:05.186755 | Accepted | closed | Testing framework | Bug | Normal | dev | wontfix | PYTHONPATH not passed through to regressiontests/admin_scripts/AdminScriptTestCase.run_test() | In my set up, on shared hosting, Django depends on various packages in my ~/site-python directory, which I include in my PYTHONPATH When regressiontests/admin_scripts starts a subprocess with AdminScriptTestCase.run_test(), it doesn't pass PYTHONPATH through, so those subprocesses fail when they hit one of these Django dependencies (e.g. psycopg2). I attach a patch which passes PYTHONPATH through correctly. | nobody | Richard Davies <richard.davies@elastichosts.com> | 0 | 1 | 1 | 0 | 0 | 0 | |
| 8755 | 2008-09-01 10:50:20 | 2011-09-28 16:12:17 | 2022-03-06 03:43:05.314032 | Unreviewed | closed | Translations | dev | fixed | Updates for Turkish translation | Please see the file attached for updated Turkish translation files. | nobody | amiroff | turkish | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8756 | 2008-09-01 11:42:54 | 2008-09-06 07:50:47 | 2022-03-06 03:43:05.466653 | Unreviewed | closed | Documentation | dev | fixed | Markup error on Custom Template Tags and Filters page | There is a markup error on the following page: http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#inclusion-tags It is just after the line "Then, any time you want to use that custom tag, load its library and call it without any arguments, like so:" where ".. code-block:: html+django" appears in a code block and the content that is meant to be in the code block ( "{% jump_link %}" )follows on the line immediatly following the code block. | nobody | Haegin | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8757 | 2008-09-01 11:58:45 | 2011-09-28 16:12:17 | 2022-03-06 03:43:05.621496 | Accepted | closed | Documentation | dev | fixed | Typo in custom templatetags docs | At the end of the [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#inclusion-tags inclusion tags section] there is a short line that isn't styled as template code: {{{ Then, any time you want to use that custom tag, load its library and call it without any arguments, like so: .. code-block:: html+django {% jump_link %} }}} I include a patch with the probable solution, but please review as I couldn't test it. | nobody | framos | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8758 | 2008-09-01 12:09:24 | 2010-01-28 13:59:58 | 2022-03-06 03:43:05.780167 | Accepted | closed | contrib.syndication | 1.0 | fixed | get_tag_uri in /django/utils/feedgenerator.py breaks with port numbers | The following function: {{{ def get_tag_uri(url, date): "Creates a TagURI. See http://diveintomark.org/archives/2004/05/28/howto-atom-id" tag = re.sub('^http://', '', url) if date is not None: tag = re.sub('/', ',%s:/' % date.strftime('%Y-%m-%d'), tag, 1) tag = re.sub('#', '/', tag) return u'tag:' + tag }} - http://code.djangoproject.com/browser/django/trunk/django/utils/feedgenerator.py#L48 ... breaks for domain names with a port number, such as http://example.org:8080/ as this produces the following TAG value: {{{ tag:example.org:8080,2007-09-21:/ }}} From http://feedvalidator.org/docs/error/InvalidTAG.html and http://tools.ietf.org/html/rfc4151#section-2.1 you can see that the TAG URI should not contain the port number. The following patch should be able to extract the domain name from the link: {{{ - tag = re.sub('^http://', '', url) + tag = str(urllib.splitport(urllib.splithost(urllib.splittype(url)[1])[0])[0]) }}} | arthurk | nslater | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8759 | 2008-09-01 12:09:53 | 2011-09-28 16:12:17 | 2022-03-06 03:43:05.917379 | Accepted | closed | Documentation | dev | fixed | typo 'inset' for 'insert' in overriding-predefined-model-methods | In the code samples at http://docs.djangoproject.com/en/dev/topics/db/models/#overriding-predefined-model-methods, 'inset' is used instead of 'insert' in two places. | nobody | jtauber | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8760 | 2008-09-01 12:49:54 | 2021-01-14 19:12:16 | 2022-03-06 03:43:06.063336 | Ready for checkin | closed | Forms | Cleanup/optimization | Normal | dev | fixed | forms.ModelMultipleChoiceField should use "invalid_list" as error message key | The MultipleChoiceField uses "invalid_list", but ModelMultipleChoiceField uses "list" as the key for the similar error message. | smithdc1 | durdinator | forms | 0 | 1 | 0 | 0 | 0 | 0 |
| 8761 | 2008-09-01 13:32:27 | 2009-02-25 21:33:50 | 2022-03-06 03:43:06.216439 | Unreviewed | closed | contrib.admin | dev | wontfix | Permissions bug in Admin area | If a user is given add/edit/delete permissions to user objects, the user is then able to create other users with greater permissions than itself, even promoting others to superuser status. Furthermore that user could also turn itself super by editing profile. Running off latest SVN version. | nobody | caphun | admin, interface, permissions, users, groups, bug | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8762 | 2008-09-01 14:51:37 | 2011-09-28 16:12:17 | 2022-03-06 03:43:06.357899 | Unreviewed | closed | contrib.comments | dev | fixed | regressiontests/comment_tests fail with postgreSQL (and likely other transactional backends) | A clean checkout of r8798 (current head) fails the comments_test regression test when run against postgresql (but not against sqlite): {{{ $ ./runtests.py --settings=SETT_sqlite comment_tests ---------------------------------------------------------------------- Ran 64 tests in 4.348s OK }}} vs. {{{ $ ./runtests.py --settings=SETT_postgresql_psycopg2 comment_tests Error: Database test_test couldn't be flushed. Possible reasons: * The database isn't running or isn't configured correctly. * At least one of the expected database tables doesn't exist. * The SQL was invalid. Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL this command wasn't able to run. The full error: current transaction is aborted, commands ignored until end of transaction block }}} I'm confident this isn't simply database misconfiguration, since other tests do work with postgreSQL. | nobody | Richard Davies <richard.davies@elastichosts.com> | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8763 | 2008-09-01 15:55:48 | 2011-09-28 16:12:17 | 2022-03-06 03:43:06.517387 | Accepted | closed | Testing framework | dev | fixed | modeltests/generic_relations may fail since TaggedItem ordering is not completely specified | modeltests/generic_relations fails on one of my systems, while it works on others. The reason is that there is a test on TaggedItem.objects.all(), and the order of the items returned by all() may vary. I attach a very simple patch to guarantee that the ordering is as expected by the test case. The error: {{{ $ ./runtests.py --settings=SETT_postgresql_psycopg2 generic_relations ====================================================================== FAIL: Doctest: modeltests.generic_relations.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/elastic/django-dev/trunk/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for modeltests.generic_relations.models.__test__.API_TESTS File "/home/elastic/django-dev/trunk/tests/modeltests/generic_relations/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/elastic/django-dev/trunk/tests/modeltests/generic_relations/models.py", line ?, in modeltests.generic_relations.models.__test__.API_TESTS Failed example: [(t.tag, t.content_type, t.object_id) for t in TaggedItem.objects.all()] Expected: [(u'clearish', <ContentType: mineral>, 1), (u'fatty', <ContentType: vegetable>, 2), (u'fatty', <ContentType: animal>, 1), (u'hairy', <ContentType: animal>, 2), (u'salty', <ContentType: vegetable>, 2), (u'shiny', <ContentType: animal>, 1), (u'yellow', <ContentType: animal>, 2)] Got: [(u'clearish', <ContentType: mineral>, 1), (u'fatty', <ContentType: animal>, 1), (u'fatty', <ContentType: vegetable>, 2), (u'hairy', <ContentType: animal>, 2), (u'salty', <ContentType: vegetable>, 2), (u'shiny', <ContentType: animal>, 1), (u'yellow', <ContentType: animal>, 2)] ---------------------------------------------------------------------- File "/home/elastic/django-dev/trunk/tests/modeltes… | nobody | Richard Davies <richard.davies@elastichosts.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8764 | 2008-09-01 16:23:50 | 2010-03-08 02:07:07 | 2022-03-06 03:43:06.671815 | Accepted | closed | Documentation | dev | duplicate | Documentation should explain you can't mix args and **kwargs in reverse() | Changeset [8760] introduced this exception: "Don't mix *args and **kwargs in call to reverse()!" {{{ django/trunk/django/core/urlresolvers.py def reverse(self, lookup_view, *args, **kwargs): if args and kwargs: raise ValueError("Don't mix *args and **kwargs in call to reverse()!") }}} [8760] was suppose to be backwards compatible but is not. My question is: Why is not possible to mis args and kwargs? I don't understand the reason, and all of my reverse funcions will fail because of this. I'll write an example of the problem. All my urls are prepared following the best SEO rules, so in many places I have urls like: `(r'^(.*)-f(?P<id>\d+)\.html$','view_photo') ` this would make the url: `my-photo-f2.html` I get the url using: {{{ reverse('app.views.view_photo', args=[slugify(photo.title)], kwargs={'id':id}) }}} (Note: I don't want to use a slug field.) Now this won't work. Well, IMHO this is a bug. I don't see any reason why the reverse function shouldn't work the same way as it did before. Aplying a patch and make the funcion so limited is not appropiated. | nobody | tolano | reverse function exception | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8765 | 2008-09-01 16:41:34 | 2010-09-11 03:25:44 | 2022-03-06 03:43:06.820600 | Ready for checkin | closed | HTTP handling | dev | fixed | mod_python handler requires explicit str() cast for HttpResponse(mimetype=...) | mod_python assumes content_type to be an ASCII string, while django uses unicode strings everywhere. For example, the following code: {{{ #!python att = Attachment.objects.get() return HttpResponse(content=att.file, mimetype=att.content_type) }}} works in django dev server, but crashes in mod_python: {{{ Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/usr/lib/python2.5/site-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/usr/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 210, in handler return ModPythonHandler()(req) File "/usr/lib/python2.5/site-packages/django/core/handlers/modpython.py", line 193, in __call__ req.content_type = response['Content-Type'] TypeError: content_type must be a string }}} so the only way to make it work is to cast explicitely: {{{ #!python return HttpResponse(content=att.file, mimetype=str(att.content_type)) }}} The str() cast needs to be moved into core/handlers/modpython.py, which already applies it for all headers except Content-Type (since it's handled separately). | nobody | semenov | mod_python content-type mimetype | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8766 | 2008-09-01 17:58:09 | 2008-09-02 09:50:56 | 2022-03-06 03:43:06.977523 | Accepted | closed | *.djangoproject.com | dev | worksforme | Images missing from new documentation | Images are missing from the new documentation - see for example [http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-tutorial02 Writing your first Django app, part 2], none of the admin site screenshots are there. '''Note''': when I build the documentation locally the images are there, this suggests to me that the problem is with the configuration of the production website??? | nobody | richardb | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8767 | 2008-09-01 18:09:14 | 2009-10-31 16:52:15 | 2022-03-06 03:43:07.119613 | Design decision needed | closed | Documentation | dev | duplicate | Should user profile docs mention OneToOne fields? | In [http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users auth docs], it was said that {{{UserProfile}}} should be a {{{ForeignKey}}} to {{{User}}} model. ¿should mention one to one relationship? | nobody | msaelices | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8768 | 2008-09-01 18:11:07 | 2009-08-09 12:25:20 | 2022-03-06 03:43:07.274228 | Unreviewed | closed | Documentation | dev | fixed | Document that ugettext_lazy returns `<django.utils.functional.__proxy__ object at 0x11b1310>` in non-unicode string context | Docs state that ''"... ugettext_lazy() stores a lazy reference to the string — not the actual translation. The translation itself will be done when the string is used in a string context, ..."'''. However, `ugettext_lazy("Foo")` does not actually provide the translation in string context: {{{ FOO = { 'a' : ugettext_lazy("Foo"), } def bar(): return "bar %s" % FOO['a'] }}} does not return the translation for `"Foo"` but the string rep `<django.utils.functional.__proxy__ object at 0x11b1310>` of the proxy object instead. {{{ return u"bar %s" % force_unicode(FOO['a']) }}} behaves as expected and should be documented near `ugettext_lazy`. | nobody | mrts | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8769 | 2008-09-01 19:19:14 | 2012-06-13 06:43:33 | 2022-03-06 03:43:07.426433 | Accepted | closed | Database layer (models, ORM) | Cleanup/optimization | Normal | dev | fixed | Slightly over-aggressive join promotion in SQL for ordering | Right now, we promote any table join used in the ordering portion to an outer join if it potentially contains NULL values (the corresponding Django field has `null=True`). There are some cases where this is unnecessary. If we already used that join in the filter statements and didn't make it an outer join at that point, it's because we are already filtering out the null values, so an inner join still won't lose any results in the ordering. Thus, we should only promote joins for ordering if we needed to add that join for the ordering (this means `self.alias_refcount[...] == 1`, or something else that's easily detectable). Noting this so I don't forget. Don't want to introduce new bugs at the moment and it's a bit of an edge case, so it can wait until post-1.0. | mtredinnick | mtredinnick | 0 | 0 | 0 | 0 | 0 | 0 | |
| 8770 | 2008-09-01 19:39:05 | 2011-09-28 16:12:17 | 2022-03-06 03:43:07.571497 | Ready for checkin | closed | Database layer (models, ORM) | dev | fixed | Under MySQL some tests fail due to BooleanField returning 1 and 0 | See title. | nobody | Alex | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8771 | 2008-09-01 19:49:16 | 2011-09-28 16:12:17 | 2022-03-06 03:43:07.717872 | Unreviewed | closed | Translations | dev | fixed | Django Hebrew Translation Update | Update new string from a recent checkin. | nobody | Alex | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8772 | 2008-09-01 21:20:34 | 2009-02-25 19:51:44 | 2022-03-06 03:43:07.886818 | Unreviewed | closed | Uncategorized | dev | wontfix | When a get_object_or_404 returns a 404, it'd be nice if it would return which query didn't provide an object (when DEBUG=True) | I recently had an error in a query in a context processor. When I tried to go to a certain page, I got the error: "No CollabProject matches the given query". And practically no other information. No trackbacks or anything. No indication of which file the error was in. Just that message and a 404. I kept checking and couldn't find any error in my view. I even confirmed that the view executed to the end. It was only by chance that I discovered the error in the context processor. Isn't there a way to have it such that if the error occurs in a context processor, it can point to the line in the context processor that had the bad query? BTW, by bad query I mean a valid query that doesn't return any objects in the database. I suspect this may be a problem with such a query in a middleware, but did not experiment. | nobody | Beetle_B | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8773 | 2008-09-01 21:37:27 | 2008-09-02 11:17:57 | 2022-03-06 03:43:08.036932 | Unreviewed | closed | Documentation | 1.0-alpha-2 | invalid | Context processors must be in context_processors.py | Documentation does not specify in which file to create context processor functions. They must be defined in context_processors.py , not in views.py. Otherwise the TEMPLATE_CONTEXT_PROCESSORS setting will fail to recognize them as context processors. This apparent requirement should be documented at: http://www.djangoproject.com/documentation/templates_python/#subclassing-context-requestcontext | nobody | shacker | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8774 | 2008-09-01 21:39:13 | 2011-09-28 16:12:17 | 2022-03-06 03:43:08.195397 | Unreviewed | closed | contrib.admin | dev | invalid | ImageField errors in admin inline editing | When trying to edit a model that has another model inlined in the admin the following error occurs. This doesn't occur when creating a new instance. The error was first sighted from an SVN version on Friday 28.8.2008 and is still present in rev 8814. ''[original html traceback removed -JKM]'' | nobody | ramin | imagefield admin inline | 0 | 0 | 0 | 0 | 0 | 0 | ||
| 8775 | 2008-09-01 21:48:36 | 2008-10-20 16:29:12 | 2022-03-06 03:43:08.342873 | Unreviewed | closed | Translations | dev | invalid | Change German translation of "E-mail address" to "E-Mail Adresse" | I think "E-Mail Adresse" is a better translation for "E-mail address" than "E-Mail-Adresse". | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8776 | 2008-09-01 22:11:17 | 2011-09-28 16:12:17 | 2022-03-06 03:43:08.465999 | Unreviewed | closed | Translations | dev | fixed | Updated Dutch translation | r8805 added another string to Django, so I translated it. Patch attached! | nobody | Rudolph | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8777 | 2008-09-01 22:12:05 | 2011-09-28 16:12:17 | 2022-03-06 03:43:08.603755 | Unreviewed | closed | Internationalization | dev | fixed | validate_unique - bad capitalization function | In the new function validate_unique from [8805] model_name is capitalized - but with title, not capfirst. * Bad (title): log entry -> Log Entry * Good (capfirst): log entry -> Log entry Attached patch could fix it. | nobody | Petr Marhoun <petr.marhoun@gmail.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8778 | 2008-09-01 22:18:38 | 2010-02-10 23:14:55 | 2022-03-06 03:43:08.768858 | Accepted | closed | Internationalization | dev | fixed | validate_unique - different phrases have the same translations | In the new function validate_unique from [8805] two new translations phrases are added. One for one field (unique), one for more fields (unique_together). There is a difference in code - in the first phrase "field_label" variable is used, in the second phrase "field_labels" variable is used. But in the translation strings only "field_label" is used. It means that for some languages (at least for mine) it is almost impossible to have nice translations of these strings. Could it be possible to change the second "field_label" to "field_labels"? | nobody | Petr Marhoun <petr.marhoun@gmail.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8779 | 2008-09-01 22:21:12 | 2011-09-28 16:12:17 | 2022-03-06 03:43:08.943874 | Unreviewed | closed | Translations | dev | fixed | czech translation update | This is translation for [8805] (validate_unique). But it quite depends on #8778 - without it not nice translation for unique_together validation is used. | nobody | Petr Marhoun <petr.marhoun@gmail.com> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8780 | 2008-09-01 22:29:05 | 2008-09-01 22:47:13 | 2022-03-06 03:43:09.065400 | Unreviewed | closed | Testing framework | dev | invalid | Various unicode unit tests may fail on MySQL, since test database may be created without utf-8 character set | The MySQL installation notes state that the database character set should be utf-8, specified by either "CREATE DATABASE <dbname> CHARACTER SET utf8;" or a database-wide default "mysqld -C utf8" or "default-character-set = utf8" runtests.py creates a new test database, but does not force the character set to utf8 when it does so. This means that users configured with a database-wide default of utf8 will find that runtests.py works fine. However, users who only set this for their working Django database, may find that the new test database has the wrong character set, in which case they will see several tests fail (one example below): {{{ $ ./runtests.py --settings=SETT_mysql basic ====================================================================== FAIL: Doctest: modeltests.basic.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/elastic/django-dev/trunk3/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for modeltests.basic.models.__test__.API_TESTS File "/home/elastic/django-dev/trunk3/tests/modeltests/basic/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/elastic/django-dev/trunk3/tests/modeltests/basic/models.py", line ?, in modeltests.basic.models.__test__.API_TESTS Failed example: Article.objects.get(pk=a.id).headline Expected: u'\u6797\u539f \u3081\u3050\u307f' Got: u'?? ???' ---------------------------------------------------------------------- Ran 1 test in 0.149s FAILED (failures=1) }}} The answer is probably for the test framework to force a complete "CREATE DATABASE <dbname> CHARACTER SET utf8;" when it creates the test database when run with the mysql backend. | nobody | Richard Davies <richard.davies@elastichosts.com> | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8781 | 2008-09-01 22:51:13 | 2011-09-28 16:12:17 | 2022-03-06 03:43:09.214036 | Unreviewed | closed | Translations | dev | fixed | Updated Arabic Translation | A new full Django translation and QA | nobody | okhayat | 0 | 0 | 0 | 0 | 0 | 0 | |||
| 8782 | 2008-09-01 22:51:56 | 2011-09-28 16:12:17 | 2022-03-06 03:43:09.366252 | Unreviewed | closed | Translations | dev | fixed | Updated Finnish translation | Yet one more update to Finnish translations. Added a couple of missing strings, a new string from r8805 and cleaned the translated strings in many places. Big thanks to Antti Kaihola for helping out with these. Hyvä Suomi! 1.0, here we come :) | nobody | Uninen | finnish, fi | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8783 | 2008-09-01 22:54:59 | 2011-09-28 16:12:17 | 2022-03-06 03:43:09.500621 | Unreviewed | closed | Translations | dev | fixed | updated macedonian translation | Please update the Macedonian translation. | nobody | Georgi | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8784 | 2008-09-01 23:09:01 | 2013-05-08 19:54:07 | 2022-03-06 03:43:09.682287 | Unreviewed | closed | Database layer (models, ORM) | Uncategorized | Normal | dev | wontfix | Add HAVING-clauses to QuerySets | We need some way to include HAVING clauses in QuerySets. The HAVING clause allows aliases to be used as operands in conditionals. The db.models.QuerySet.extra() looks like the best method to use for something like this, so I've added some code to db.models.QuerySet.extra() method and the corresponding db.models.sql.query.Query class. See patch. A use case: {{{ locations = Location.objects.extra( select={'distance': 'SQRT(POW(69.1 * (lattitude - %f), 2) + POW(69.1 * (longitude - %f) * COS(lattitude/57.3), 2))' % (lat, lng)} ) locations = locations.extra( having=['distance < %f' % maxdist] ) }}} | Johntron | Johntron | db query having clause extra database | 0 | 1 | 0 | 1 | 1 | 0 |
| 8785 | 2008-09-01 23:54:15 | 2011-09-28 16:12:17 | 2022-03-06 03:43:09.825318 | Unreviewed | closed | Translations | dev | fixed | Norwegian translation update | Added the new string commited in r8805. | nobody | jonklo | norwegian | 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
);