tickets
23 rows where "created" is on date 2008-08-09 sorted by stage
This data as json, CSV (advanced)
Suggested facets: component, resolution, owner, needs_better_patch, last_pulled_from_trac (date)
stage 3 ✖
- Accepted 12
- Unreviewed 8
- Ready for checkin 3
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 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
8176 | 2008-08-09 01:04:22 | 2011-09-28 16:12:17 | 2022-03-06 03:41:33.750216 | Accepted | closed | Translations | dev | fixed | New django.po for Japanese language. | I translated django.po against svn rev 8255. | nobody | Takashi Matsuo <matsuo.takashi@gmail.com> | 0 | 0 | 0 | 0 | 0 | 0 | |||
8177 | 2008-08-09 01:31:38 | 2011-09-28 16:12:17 | 2022-03-06 03:41:33.946180 | Accepted | closed | Core (Other) | dev | fixed | reverse() should report the reverse lookup that fails. | Now that {% url foo %} does not fail silently any more, it's really important to report which reverse lookup failed. Compare: {{{ Before the attached patch: -------------------------- Django version 1.0-alpha_2-SVN-8255, using settings 'trunk.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Traceback (most recent call last): ... File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py", line 291, in reverse raise NoReverseMatch NoReverseMatch After the attached patch: -------------------------- Django version 1.0-alpha_2-SVN-8255, using settings 'trunk.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Traceback (most recent call last): ... File "/usr/lib/python2.5/site-packages/django/core/urlresolvers.py", line 291, in reverse raise NoReverseMatch("Reverse for '%s' not found." % lookup_view) NoReverseMatch: Reverse for 'foo-bar' not found. }}} Run a `rgrep foo-bar .` and you find the offending place easily. | nobody | mrts | reverse | 0 | 1 | 0 | 0 | 0 | 0 | ||
8179 | 2008-08-09 03:26:20 | 2008-09-09 11:29:30 | 2022-03-06 03:41:34.249089 | Accepted | closed | Documentation | dev | fixed | most cross-references in sphinx-generated HTML are wrong | to reproduce (an example) * generate the sphinx html documentation using make html in the django_trunk/docs directory * (eg) open {{{_build/html/install.html}}} in a browser. The link 'How to use Django with mod_python' (in the ''Install Apache and mod_python'' section) points to a modpython '''directory''' in the directory '''above''' the original directory, instead of modpython'''.html''' at the same level as the original file The reason is that the references are not in the form suggested by the sphinx documentation (http://sphinx.pocoo.org/markup/inline.html#cross-referencing-syntax). A quick grep indicates there are about 320 instances of the wrong links across 56 of the .txt files. I'd be happy to claim this ticket, but it seems like there's be a great option for merge conflicts with that many files. Any suggestions? feel free to contact me at nic \at\ tymar \dot\ com if there's an easy way of avoiding conflicts | nobody | niccl | 0 | 0 | 0 | 0 | 0 | 0 | |||
8181 | 2008-08-09 06:33:39 | 2011-09-28 16:12:17 | 2022-03-06 03:41:34.553760 | Accepted | closed | Documentation | dev | duplicate | Documentation error leads to 'model already registered exceptions' | The documentation says to add admin model registration to the end of the models.py file. Because this file may be imported more than once, this causes a 'model _____ already registered exception'. The solution is to use autodiscover (as suggested in the documentation) but to place the model registration in the file admin.py. See http://groups.google.com/group/django-users/browse_thread/thread/8af97d45102ee2f2 . | nobody | Marc | 0 | 0 | 0 | 0 | |||||
8184 | 2008-08-09 10:38:24 | 2008-10-06 08:47:01 | 2022-03-06 03:41:35.039350 | Accepted | closed | Documentation | dev | fixed | urlresolver doc | I think this nice comment from the mailing list should be added to the reverse() function doc The urlresolvers.reverse function throws an exception if *any* of your URLs anywhere in the project have a bad view and not necessarily the one you are trying to reverse map. So, check that you don't have any URL mappings with undefined view functions (or views with syntax errors). | nobody | hvendelbo | 0 | 0 | 0 | 0 | 0 | 0 | |||
8190 | 2008-08-09 16:14:36 | 2011-09-28 16:12:30 | 2022-03-06 03:41:36.120121 | Accepted | closed | contrib.admin | New feature | Normal | dev | fixed | Utilise help_text for TabularInline in Admin | When using !TabularInline in the automatic admin interface the help_text for fields is not displayed anywhere. I suggest that the information could be displayed as a tooltip on the column heading, like so: {{{ <th {% if forloop.first %}colspan="2"{% endif %}>{{ field.label|capfirst|escape }}</th> }}} becomes {{{ <th {% if forloop.first %}colspan="2"{% endif %}> {{ field.label|capfirst|escape }} {% if field.help_text %}<abbr class="help-text-tooltip" title="{{ field.help_text|striptags }}">?</abbr>{% endif %} </th> }}} and then in the CSS: {{{ .help-text-tooltip { cursor: help; } }}} | dArignac | glenjamin | 0 | 1 | 1 | 0 | 0 | 1 | |
8191 | 2008-08-09 16:16:52 | 2011-09-28 16:12:17 | 2022-03-06 03:41:36.320809 | Accepted | closed | Database layer (models, ORM) | dev | fixed | Queryset improvements for extra() calls | There are a few related problems in calling the `extra()` on querysets related to it handles parameters for the `extra_select` parameter. Currently they * don't merge correctly * aren't removed correctly * don't handle updates correctly. All of these involve the same dozen lines of code, so I'm making this the tracking ticket for the three problems. I'm working on patch that incorporates mullendr's diagnoses and ideas from #7957 and #7961. It doesn't quite work to address them individually at the moment. | mtredinnick | mtredinnick | 0 | 0 | 0 | 0 | 0 | 0 | |||
8193 | 2008-08-09 19:11:08 | 2011-09-28 16:12:21 | 2022-03-06 03:41:36.700006 | Accepted | closed | Uncategorized | dev | fixed | `__import__(mod, {}, {}, [''])` causes double import of modules ('module' and 'module' + '.') | As discussed at http://groups.google.com/group/django-developers/browse_thread/thread/d27261561bc36d96 and http://bugs.python.org/issue2090, dynamically loaded modules with `fromlist=['']` are initialized twice (as `'module'` and `'module.'`). | jacob | i_i | import | 0 | 1 | 0 | 0 | 0 | 0 | ||
8194 | 2008-08-09 19:46:11 | 2011-09-28 16:12:17 | 2022-03-06 03:41:36.889018 | Accepted | closed | contrib.admin | dev | fixed | Admin form keyboard focus does not respect fields or fieldsets options | When you re-order the fields in an admin add form using the `fields` or `fieldsets` options in your `ModelAdmin` class, the initial keyboard focus in the admin add/change form does not respect it. The keyboard focus is set by a !JavaScript call to `document.getElementById("id_foo").focus()`, where the ID is specified in the `change_form.html` template as `{{adminform.first_field.auto_id}}`. So an underlying issue is that `AdminForm.first_field()` (in `contrib/admin/options.py`) does not respect the re-ordering. I am experiencing this using the current Subversion HEAD, revision 8272. For example, consider this simple model in `models.py`: {{{ class MyModel(models.Model): foo = models.CharField(max_length=255) bar = models.CharField(max_length=255) }}} and this simple admin configuration in `admin.py`: {{{ class MyModelAdmin(admin.ModelAdmin): fields = ('bar', 'foo') admin.site.register(MyModel,MyModelAdmin) }}} Then try to add a new !MyModel object using the admin interface, and notice that they keyboard focus starts out at the bottom rather than the top of the form. | nobody | mdhancher | newforms-admin | 0 | 1 | 1 | 0 | 0 | 0 | ||
8196 | 2008-08-09 20:36:27 | 2008-09-02 03:07:27 | 2022-03-06 03:41:37.241084 | Accepted | closed | Testing framework | dev | fixed | modeltests/model_forms tests fail on a system without PIL installed | This is the output (Linux + Python 2.4.4): {{{ ====================================================================== FAIL: Doctest: modeltests.model_forms.models.__test__.API_TESTS ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/ramiro/hg-repos/django/trunk/django/test/_doctest.py", line 2180, in runTest raise self.failureException(self.format_failure(new.getvalue())) AssertionError: Failed doctest test for modeltests.model_forms.models.__test__.API_TESTS File "/home/ramiro/hg-repos/django/trunk/tests/modeltests/model_forms/models.py", line unknown line number, in API_TESTS ---------------------------------------------------------------------- File "/home/ramiro/hg-repos/django/trunk/tests/modeltests/model_forms/models.py", line ?, in modeltests.model_forms.models.__test__.API_TESTS Failed example: instance.image Expected: <ImageFieldFile: tests/test.png> Got: <FieldFile: tests/test.png> ---------------------------------------------------------------------- File "/home/ramiro/hg-repos/django/trunk/tests/modeltests/model_forms/models.py", line ?, in modeltests.model_forms.models.__test__.API_TESTS Failed example: instance.image Expected: <ImageFieldFile: tests/test.png> Got: <FieldFile: tests/test.png> ---------------------------------------------------------------------- File "/home/ramiro/hg-repos/django/trunk/tests/modeltests/model_forms/models.py", line ?, in modeltests.model_forms.models.__test__.API_TESTS Failed example: f.cleaned_data['image'] Expected: <ImageFieldFile: tests/test.png> Got: <FieldFile: tests/test.png> ---------------------------------------------------------------------- File "/home/ramiro/hg-repos/django/trunk/tests/modeltests/model_forms/models.py", line ?, in modeltests.model_forms.models.__test__.API_TESTS Failed example: instance.image Expected: <ImageFieldFile: tests/test.png> Got: <FieldFile: tests/test.png> -----… | Gulopine | ramiro | 0 | 1 | 0 | 0 | 0 | 0 | |||
8197 | 2008-08-09 21:40:03 | 2008-08-24 17:02:27 | 2022-03-06 03:41:37.404193 | Accepted | closed | contrib.localflavor | dev | wontfix | Update Polish administrative entites | Attached file contains a list of Polish administrative entites from a [http://isip.sejm.gov.pl/servlet/Search?todo=open&id=WDU19981571031 official government source]. | nobody | Piotr Lewandowski <django@icomputing.pl> | 0 | 0 | 0 | 0 | 0 | 0 | |||
8198 | 2008-08-09 22:35:20 | 2011-09-28 16:12:17 | 2022-03-06 03:41:37.570396 | Accepted | closed | Core (Other) | dev | duplicate | Append slash broken when SCRIPT_NAME is present | Since updating to trunk (r8273), the "append slash to url" functionality of CommonMiddleware no longer works. | nobody | brooks.travis@gmail.com | middleware | 0 | 1 | 1 | 0 | 0 | 0 | ||
8178 | 2008-08-09 02:47:11 | 2011-09-28 16:12:17 | 2022-03-06 03:41:34.113947 | Ready for checkin | closed | Uncategorized | dev | fixed | Insert linebreaks in debug summary | When exceptions are raised, in particular in templates (e.g. with URL tag not matching a view), you get a big chunk of traceback info in the debug summary which is hard to read. Inserting linebreaks helps a lot. Patch attached. Before: {{{ Caught an exception while rendering: Original Traceback (most recent call last): File "E:\Software\workspace\django\django\template\debug.py", line 71, in render_node result = node.render(context) File "E:\Software\workspace\django-treemenus\trunk\treemenus\templatetags\tree_menu_tags.py", line 46, in render return urlNode.render(context) File "E:\Software\workspace\django\django\template\defaulttags.py", line 369, in render args=args, kwargs=kwargs) File "E:\Software\workspace\django\django\core\urlresolvers.py", line 307, in reverse *args, **kwargs))) File "E:\Software\workspace\django\django\core\urlresolvers.py", line 291, in reverse raise NoReverseMatch NoReverseMatch }}} After: {{{ Caught an exception while rendering: Original Traceback (most recent call last): File "E:\Software\workspace\django\django\template\debug.py", line 71, in render_node result = node.render(context) File "E:\Software\workspace\django-treemenus\trunk\treemenus\templatetags\tree_menu_tags.py", line 46, in render return urlNode.render(context) File "E:\Software\workspace\django\django\template\defaulttags.py", line 369, in render args=args, kwargs=kwargs) File "E:\Software\workspace\django\django\core\urlresolvers.py", line 307, in reverse *args, **kwargs))) File "E:\Software\workspace\django\django\core\urlresolvers.py", line 291, in reverse raise NoReverseMatch NoReverseMatch }}} | nobody | julien | 0 | 1 | 0 | 0 | 0 | 0 | |||
8186 | 2008-08-09 13:00:50 | 2011-09-28 16:12:17 | 2022-03-06 03:41:35.326267 | Ready for checkin | closed | Translations | dev | fixed | Updated German translation | Some improvements to the German translations. | jezdez | benjixx | 0 | 1 | 0 | 0 | 0 | 0 | |||
8189 | 2008-08-09 15:09:13 | 2011-09-28 16:12:17 | 2022-03-06 03:41:35.915106 | Ready for checkin | closed | Documentation | dev | fixed | FileField documentation still mentions get_<fieldname>_url | model-api.txt still reads: {{{ All that will be stored in your database is a path to the file (relative to MEDIA_ROOT). You’ll most likely want to use the convenience get_<fieldname>_url function provided by Django. For example, if your ImageField is called mug_shot, you can get the absolute URL to your image in a template with {{ object.get_mug_shot_url }}. }}} where it should mentions object.<fieldname>.url | jacob | gogna | 0 | 1 | 0 | 0 | 0 | 0 | |||
8180 | 2008-08-09 06:17:44 | 2008-08-09 14:17:55 | 2022-03-06 03:41:34.396113 | Unreviewed | closed | Documentation | dev | fixed | Typo in docs/files.txt | The new file storage docs contain a typo. When explaining the default file storage class it mentions that 'location' is the argument that determines where the files will actually end up, while in the code example it uses 'base_url' argument. | nobody | johann | 0 | 1 | 0 | 0 | 0 | 0 | |||
8182 | 2008-08-09 07:33:40 | 2011-09-28 16:12:16 | 2022-03-06 03:41:34.691349 | Unreviewed | closed | contrib.auth | dev | fixed | infinite loop iterating over context_processors.PermWrapper | The template code below will cause an infinite memory-eating loop if context_processors.auth is enabled. My main issue with that is that it was incredibly hard to debug for me, when I passed my own 'perms' queryset to a template. So here's a (temporary) patch, to make it at least immediately fail. {{{ {% for perm in perms %} {% endfor %} }}} | Uz | 0 | 1 | 0 | 0 | 0 | 0 | ||||
8183 | 2008-08-09 08:32:50 | 2008-08-09 14:15:18 | 2022-03-06 03:41:34.838928 | Unreviewed | closed | Uncategorized | dev | fixed | Main Documention page have no link to new page "files/" | When I read the 1.0 alpha 2 release notes I noticed that[[BR]] the referenced doc page in "Pluggable file storage" section[[BR]] didn't existed on main Documention page.[[BR]] No refences to: http://www.djangoproject.com/documentation/files/ [[BR]] in: http://www.djangoproject.com/documentation/ | nobody | ClaesBas | 0 | 0 | 0 | 0 | 0 | 0 | |||
8185 | 2008-08-09 12:49:05 | 2008-08-09 13:36:01 | 2022-03-06 03:41:35.169659 | Unreviewed | closed | Documentation | dev | duplicate | A picture in documentation is in wrong format | In the tutorial, "Writing your first Django app, part 2" (http://www.djangoproject.com/documentation/tutorial02/), the picture of the Django admin login screen (http://media.djangoproject.com/img/doc/tutorial-trunk/admin01.png) is in the PSD or PS format while it should be PNG. | nobody | katremer | 0 | 0 | 0 | 0 | 0 | 0 | |||
8187 | 2008-08-09 13:44:44 | 2008-11-03 08:01:53 | 2022-03-06 03:41:35.518577 | Unreviewed | closed | Uncategorized | dev | fixed | Import PIL consistently and with exception handling, list as optional dependency in INSTALL | Some projects import PIL, some Imaging intending to reach the same code depending on how PIL was installed. Django appears to use the second form in at least one spot. Some imports handle ImportError exceptions, some don't. PIL is not mentioned in the INSTALL document. {{{ $ ack -B 4 -A 4 'PIL|Imaging' django/forms/fields.py 472- 473- def clean(self, data, initial=None): 474- """ 475- Checks that the file-upload field data contains a valid image (GIF, JPG, 476: PNG, possibly others -- whatever the Python Imaging Library supports). 477- """ 478- f = super(ImageField, self).clean(data, initial) 479- if f is None: 480- return None 481- elif not data and initial: 482- return initial 483: from PIL import Image 484- 485: # We need to get a file object for PIL. We might have a path or we might 486- # have to read the data into memory. 487- if hasattr(data, 'temporary_file_path'): 488- file = data.temporary_file_path() 489- else: -- 507- # but it must be called immediately after the constructor 508- trial_image = Image.open(file) 509- trial_image.verify() 510- except ImportError: 511: # Under PyPy, it is possible to import PIL. However, the underlying 512- # _imaging C module isn't available, so an ImportError will be 513- # raised. Catch and re-raise. 514- raise 515: except Exception: # Python Imaging Library doesn't recognize it as an image 516- raise ValidationError(self.error_messages['invalid_image']) 517- if hasattr(f, 'seek') and callable(f.seek): 518- f.seek(0) 519- return f django/core/files/images.py 1-""" 2-Utility functions for handling images. 3- 4:Requires PIL, as you might imagine. 5-""" 6- 7-from django.core.files import File 8- -- 25- return self._dimensions_cache 26- 27-def get_image_dimensions(… | nobody | jfkw | PIL imaging easy_install | 0 | 0 | 0 | 0 | 0 | 0 | ||
8188 | 2008-08-09 14:44:30 | 2011-09-28 16:12:16 | 2022-03-06 03:41:35.685367 | Unreviewed | closed | Uncategorized | dev | fixed | file_move_safe not imported in storage.py | Uploading a File larger than FILE_UPLOAD_MAX_MEMORY_SIZE raises a !NameError in storage.py {{{ Exception Type: NameError Exception Value: global name 'file_move_safe' is not defined Exception Location: /Library/Python/2.5/site-packages/django/core/files/storage.py in _save, line 153 }}} Adding {{{ from django.core.files.move import file_move_safe }}} fixes the problem. | nobody | arne | upload, filestorage | 0 | 1 | 0 | 0 | 0 | 0 | ||
8192 | 2008-08-09 16:42:41 | 2008-08-09 16:52:20 | 2022-03-06 03:41:36.508451 | Unreviewed | closed | Core (Other) | 1.0-alpha | invalid | django.VERSION missing in alpha-2 | Hello. The django.VERSION is missing on alpha-2: {{{ exedev@messir ~ $ python Python 2.5.2 (r252, Aug 3 2008, 14:11:25) [GCC 3.4.6 (Gentoo 3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import django >>> django.VERSION Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'module' object has no attribute 'VERSION' >>> }}} | nobody | anonymous | 0 | 0 | 0 | 0 | 0 | 0 | |||
8195 | 2008-08-09 20:07:51 | 2008-08-12 17:21:15 | 2022-03-06 03:41:37.079110 | Unreviewed | closed | Database layer (models, ORM) | dev | worksforme | Importing models from same directory throws unhelpful exception (trying to get app_label) | Before: {{{ In [1]: import models --------------------------------------------------------------------------- <type 'exceptions.IndexError'> Traceback (most recent call last) (strip my stuff) ...django/db/models/base.py in __new__(cls, name, bases, attrs) 54 # For 'django.contrib.sites.models', this would be 'sites'. 55 model_module = sys.modules[new_class.__module__] ---> 56 kwargs = {"app_label": model_module.__name__.split('.')[-2]} 57 else: 58 kwargs = {} }}} After attached patch, the relative import succeeds. | nobody | kcarnold | 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 );