tickets
15 rows where "created" is on date 2008-09-08 and has_patch = 1 sorted by resolution
This data as json, CSV (advanced)
Suggested facets: changetime, status, component, type, resolution, owner, reporter, needs_better_patch, needs_docs, created (date), changetime (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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8972 | 2008-09-08 17:35:43 | 2011-04-22 06:13:28 | 2022-03-06 03:43:39.683720 | Accepted | assigned | GIS | New feature | Normal | 1.0 | Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interface | This feature has been needed for some time, and was recently requested. See: http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en I've started a basic patch that adds a javascript function to allow multiple features to be selected in the map interface, deleted from view, and removed from the save method. I've tested this so far when editing multipolygon data in the admin. A known issue I'm hoping others may have a solution to: Currently, an OL javascript error occurs on line 948 of OpenLayer.js after successfully deleting a feature. This do not seem to cause any problems in saving the correct geometry or in continuing to use the select control. This is the firebug output: {{{ object is undefined selectFeature()(undefined)OpenLayers.js (line 948) clearSelectedFeatures()()277 (line 327) javascript:geodjango_geometry.clearSelectedFeatures()()()javascri...eatures() (line 1) [Break on this error] this.feature=null;this.dragControl.deact...ply(this.selectControl,[this.feature]);} }}} | jbronn | springmeyer | OpenLayers, admin, vector editing | 0 | 1 | 0 | 1 | 0 | 0 | |
| 8936 | 2008-09-08 01:10:41 | 2018-08-17 15:37:27 | 2022-03-06 03:43:33.780505 | Ready for checkin | closed | contrib.admin | New feature | Normal | dev | fixed | Add view (read-only) permission to admin | Adrian and Jacob on stage at DjangoCon. | olivierdalang | simon | 0 | 1 | 0 | 0 | 0 | 0 | |
| 8957 | 2008-09-08 06:14:29 | 2008-09-15 11:12:02 | 2022-03-06 03:43:37.129534 | Unreviewed | closed | contrib.admin | dev | fixed | Typo in Admin validation exception message | If a prepopulated_fields value refers to a nonexistant field, the error message is in correct. So for: {{{ prepopulated_fields = {'slug': ['field_which_doesnt_exist']} }}} The error raised is: {{{ 'SomeAdmin.prepopulated_fields['field_which_doesnt_exist'][0]' refers to field 'field_which_doesnt_exist' that is missing from model 'Release'. }}} The expected error should finger 'slug' as the key with the offending source field: {{{ 'SomeAdmin.prepopulated_fields['slug'][0]' refers to field 'field_which_doesnt_exist' that is missing from model 'Release'. }}} This is a simple typo. Fix attached. | nobody | charmless | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8958 | 2008-09-08 06:56:00 | 2008-09-09 19:53:57 | 2022-03-06 03:43:37.294371 | Unreviewed | closed | Documentation | 1.0 | fixed | Typo in [8980] | In the cache documentation, the rewording got changed to ..that doesn't support the them.. I've removed 'the' | nobody | benwalton@gmail.com | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8959 | 2008-09-08 07:06:45 | 2009-02-25 19:51:44 | 2022-03-06 03:43:37.452292 | Accepted | closed | contrib.comments | dev | fixed | Remove calls to escape in new comments framework templates | As autoescaping is in place with current Django, escaping values in templates is not necessary. Attached patch fixes this. | adrian | zgoda | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8960 | 2008-09-08 07:33:52 | 2011-09-28 16:12:27 | 2022-03-06 03:43:37.639961 | Accepted | closed | Contrib apps | 1.1 | fixed | "View on site" does not work if contrib.sites is not installed | Code in django.conf.urls.defaults.shortcut expect that contrib.sites is installed and throws error "no such table: django_sites" otherwise. | adrian | bmihelac | 0 | 1 | 0 | 1 | 0 | 0 | |||
| 8962 | 2008-09-08 08:40:25 | 2012-01-09 09:29:07 | 2022-03-06 03:43:37.994120 | Accepted | closed | Forms | Uncategorized | Normal | dev | fixed | Make `input_formats` and `format` work consistently across `date`, `datetime`, and `time` fields and widgets. | Currently, there are some inconsistencies in what form fields and widgets we have available for `date`, `datetime`, and `time` data. There are also inconsistencies in how the `format` argument applies to the widgets, and the `input_formats` applies to the fields. 1. `DateTimeInput` and `TimeInput` exist, `DateInput` doesn't. 2. `DateTimeInput` accepts `format`, but `TimeInput` doesn't. 3. `SplitDateTimeField` doesn't use `SplitDateTimeWidget` by default. 4. `SplitDateTimeField` doesn't allow the user to specify `input_formats`. 5. `SplitDateTimeWidget` uses two `TextInput` widgets, instead of `TimeInput` and the missing `DateInput` (and thus doesn't allow the user to specify `formats`). 6. `django.contrib.localflavor.generic.forms` is missing `SplitDateTimeField`. 7. The documentation is sparse on detail for `SplitDateTimeField`, `DateTimeInput` and `TimeInput`. This patch: 1. Adds `DateInput`, which accepts `format`, and is used for `DateField` by default. 2. Adds `format` as an argument to `TimeInput`. 3. Uses `SplitDateTimeWidget` for `SplitDateTimeField` by default. 4. Adds `input_date_formats` and `input_time_formats` as arguments to `SplitDateTimeField`. 5. Uses `DateInput` and `TimeInput` for `SplitDateTimeWidget`, and passes through `date_format` and `time_format` through to `DateInput` and `TimeInput` as `format`, respectively. 6. Adds `SplitDateTimeField` to `django.contrib.localflavor.generic.forms`. 7. Adds documentation for all of these changes. 8. Adds tests for all of these changes. | kmtracey | mrmachine | datetime format widget i18n-rf | 0 | 1 | 0 | 0 | 0 | 0 |
| 8963 | 2008-09-08 09:06:13 | 2009-02-25 19:51:44 | 2022-03-06 03:43:38.159995 | Accepted | closed | contrib.comments | dev | fixed | Comments framework should use standard decorators where possible | Comments framework uses custom method for assuring proper HTTP method is used in view breaking DRY principle. Attached patch fixes this issuel | nobody | zgoda | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8966 | 2008-09-08 13:15:32 | 2008-10-28 19:05:00 | 2022-03-06 03:43:38.657645 | Ready for checkin | closed | Template system | dev | fixed | {% if "x"|length_is:n %} always evaluates True | {% if "x"|capfirst|length_is:n %} is always true. Example: {{{ In [1]: from django.template import Template, Context In [2]: Template('{% if "x"|capfirst|length_is:0 %}This is wrong{% endif %}').render(Context({})) Out[2]: u'This is wrong' }}} Using latest Django SVN. | carljm | Thomas Steinacher <tom@eggdrop.ch> | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8971 | 2008-09-08 16:34:53 | 2011-09-28 16:12:21 | 2022-03-06 03:43:39.505914 | Ready for checkin | closed | contrib.admin | dev | fixed | URL resolution for admindocs reST roles incorrect | The parse_rst method in admindocs/utils.py has a link_base argument set to "../.." — that works fine if the the link being created is in either the model_detail or view_detail view. But if the view is being created in the tag_index or detail_index the url does not resolve correctly. The attached patch is a solid solution, but possibly temporary. It simply has the tag_index and model_index views pass parse_rst a link_base kwarg set to the correct relative URL. I think a better solution would be to have the roles’ URLs use reverse() rather than be hard-coded. I tried to do that, but it is difficult as reverse() needs views.py to resolve the URL and views.py relies on utils.py. I am sure it can be done, but I couldn’t figure out how. | mitsuhiko | benspaulding | admindocs urls | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8973 | 2008-09-08 18:02:41 | 2008-09-09 16:07:14 | 2022-03-06 03:43:39.841466 | Accepted | closed | Translations | dev | fixed | Update the telugu translations. | Update the telugu translations as much as possible. Locale for telugu is te. | nobody | thejaswi_puthraya | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8975 | 2008-09-08 21:23:51 | 2011-09-28 16:12:27 | 2022-03-06 03:43:40.174507 | Accepted | closed | Documentation | dev | fixed | related order functions are not documented | The functions detailed in this blog post: http://james.wheare.org/notes/2007/11/ordering-related-objects-in-django.php aren't documented at all in the main Django documentation, for example: http://docs.djangoproject.com/en/dev/search/?cx=009763561546736975936%3Ae88ek0eurf4&cof=FORID%3A11&ie=UTF-8&hl=&q=get_previous_in_order&sa=Search&as_q=more%3Adev_docs#242 These are super useful functions and it would be great to have them be described in the docs. If they're meant to be private then should they be renamed to begin with an '_'? | dwillis | Leo | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8979 | 2008-09-08 23:57:09 | 2008-09-10 03:59:49 | 2022-03-06 03:43:40.996602 | Unreviewed | closed | Documentation | 1.0 | fixed | Documentation fixes | A few issues thata haven't already been reported in other Component:Documentation tickets: reST fixes, addition of Pygmentation to some files, typos. | nobody | ramiro | 0 | 1 | 0 | 0 | 0 | 0 | |||
| 8980 | 2008-09-08 23:57:35 | 2011-09-28 16:12:21 | 2022-03-06 03:43:41.182691 | Accepted | closed | Documentation | 1.0 | fixed | missing documentation for password_reset_confirm, password_reset_complete views | there's no docs! help! | nobody | aaronkrill | pycamp2009 kkmegapatch | 0 | 1 | 0 | 0 | 0 | 0 | ||
| 8968 | 2008-09-08 15:57:01 | 2013-03-24 13:37:42 | 2022-03-06 03:43:39.010131 | Accepted | closed | contrib.comments | New feature | Normal | 1.0 | wontfix | No way to utilize `next` parameter to redirect after comment deletion | How is default «delete comment» view from new comments system meant to get `next` argument (see `contrib/comments/views/moderation.py`)? I think good way to do it is to support `next` GET request parameter, so that one could use `/delete/123/?next=/blog/entry/bla-blah` as a link to comment deletion page in order to redirect to page other than default «deleted» view after actually removing the comment. This works with «post comment» because `next_redirect` in `post_comment` function can see the `next` POST parameter in `data`. This does not work with «delete comment» because confirmation page is rendered first with `next="None"` in confirmation form. | kkubasik | Dzhus | comments | 0 | 1 | 1 | 1 | 1 | 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
);