tickets
2,809 rows where easy = 1
This data as json, CSV (advanced)
Suggested facets: stage, status, type, severity, resolution, has_patch, needs_better_patch, needs_tests, needs_docs, ui_ux, created (date), 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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 640 | 2005-10-17 21:46:17 | 2011-12-31 15:30:41 | 2022-03-06 03:21:17.625920 | Ready for checkin | closed | Documentation | defect | major | dev | fixed | order_with_respect_to option fails | Example model code: {{{ from django.core import meta class Country(meta.Model): domain = meta.CharField(maxlength=2, unique=True) name = meta.CharField(maxlength=50, unique=True) class META: module_name = verbose_name_plural = "countries" ordering = ['domain'] admin = meta.Admin() def __repr__(self): return self.domain class State(meta.Model): name = meta.CharField(maxlength=100) country = meta.ForeignKey(Country) class META: order_with_respect_to = 'country' #ordering = ['name'] admin = meta.Admin() def __repr__(self): return self.name }}} ---- In Site administration, if fails when i click in States table and Change (States) too but it fails when i add 'order_with_respect_to' option only {{{ There's been an error: Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py", line 77, in get_response raise e FieldDoesNotExist: name=_order }}} ---- rev. 917 - Python 2.4.2 - sqlite-3.2.1 - pysqlite-2.0.4 | nobody | Bless | order_with_respect_to ordering mysql bug | 1 | 1 | 0 | 0 | 0 | 0 |
| 1458 | 2006-03-03 02:52:34 | 2019-04-26 17:48:51 | 2022-03-06 03:23:24.203739 | Unreviewed | closed | Core (Other) | Cleanup/optimization | normal | wontfix | make the template error page useful for command line clients | when using curl, or a command line client (say a automated update bot) the error message is hard to understand (or even see) my solution was to do the following {{{ Index: debug.py =================================================================== --- debug.py (revision 2461) +++ debug.py (working copy) @@ -181,6 +181,17 @@ TECHNICAL_500_TEMPLATE = """ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"> +<!-- +Traceback (most recent call last): +{% for frame in frames %} + File "{{ frame.filename }}" in {{ frame.function }} + {% if frame.context_line %} + {{ frame.lineno|add:"1" }}. {{ frame.context_line|escape }} + {% endif %} +{% endfor %} +{{ exception_type }} at {{ request.path }} +{{ exception_value|escape }} +--> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <meta name="robots" content="NONE,NOARCHIVE" /> @@ -531,7 +542,17 @@ display a standard 500 page. </p> </div> - +<!-- +Traceback (most recent call last): +{% for frame in frames %} + File "{{ frame.filename }}" in {{ frame.function }} + {% if frame.context_line %} + {{ frame.lineno|add:"1" }}. {{ frame.context_line|escape }} + {% endif %} +{% endfor %} +{{ exception_type }} at {{ request.path }} +{{ exception_value|escape }} +--> </body> </html> """ }}} which puts the traceback at the start and end of the HTML page as a comment so that the developer can just see it quickly. | adrian | Ian@holsman.net | 1 | 0 | 0 | 0 | 0 | 1 | ||
| 1675 | 2006-04-24 22:10:44 | 2011-10-19 00:28:18 | 2022-03-06 03:23:58.568016 | Unreviewed | closed | Template system | defect | normal | worksforme | application-specific templatetags aren't loaded | The documentation for custom templatetags http://www.djangoproject.com/documentation/templates_python/#extending-the-template-system states that you can add a templatetags module to your app. If I understand the doc correctly, a {% load xyz %} tag will look for the library in myapp/templatetags/xyz.py and load it. The implementation doesn't do that, however, it only looks in django.templatetags and none of the application directories. There are some old tickets on this, such as ticket:288 and ticket:86, but these have been closed as invalid. Not sure why, though, because the documentation still says it should work and it seems like a useful feature. | adrian | shs | templatetags load INSTALLED_APPS | 1 | 0 | 0 | 0 | 0 | 1 | |
| 1908 | 2006-05-17 13:51:53 | 2011-12-21 15:57:44 | 2022-03-06 03:24:37.114633 | Accepted | closed | Core (Management commands) | Bug | Normal | dev | fixed | Having an app name the same as project name breaks manage.py ( unable to import projectname.settings ) | When a project has an app with the same name, manage.py breaks. This might seem like a trivial example - there's probably a good argument to be made why a projectname should be different to an appname, but I think this problem will crop up often on small apps. Step 1: Create Project fudge & test {{{ minerva:~ simon$ django-admin.py startproject fudge minerva:~ simon$ cd fudge/ minerva:~/fudge simon$ ls __init__.py manage.py settings.py urls.py minerva:~/fudge simon$ python manage.py runserver 80808 Validating models... 0 errors found. Django version 0.95 (post-magic-removal), using settings 'fudge.settings' Development server is running at http://127.0.0.1:80808/ Quit the server with CONTROL-C. }}} Step 2: add an app, also called fudge & try to runserver {{{ minerva:~/fudge simon$ python manage.py startapp fudge minerva:~/fudge simon$ python manage.py runserver 80808 Traceback (most recent call last): File "manage.py", line 11, in ? execute_manager(settings) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1237, in execute_manager execute_from_command_line(action_mapping) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1158, in execute_from_command_line translation.activate('en-us') File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/utils/translation.py", line 195, in activate _active[currentThread()] = translation(language) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/utils/translation.py", line 120, in translation if settings.SETTINGS_MODULE is not None: File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/conf/__init__.py", line 28, in __getattr__ self._import_settings() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/djang… | adrian | simon@simon.net.nz | 1 | 0 | 0 | 0 | 0 | 1 | |
| 2550 | 2006-08-16 15:11:50 | 2012-11-17 19:25:07 | 2022-03-06 03:26:21.182766 | Ready for checkin | closed | contrib.auth | New feature | Normal | dev | fixed | Allow a Backend to Globally Fail Authentication | Allows a backend to fail all authentication - I.E. if a user exists in a backend but the password is wrong, it's very possible that the backend might just want to kick the user out instead of letting it go through the rest of the authentication backends and possibly succeeding. Kind of like PAM's 'required' option. | aashu_dwivedi | umbrae@gmail.com | authentication backends easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 3371 | 2007-01-26 17:42:28 | 2014-09-04 20:55:24 | 2022-03-06 03:28:32.147454 | Unreviewed | closed | Template system | New feature | Normal | dev | wontfix | Filter to get dict's value by key name (for the purpose of enabling variable lookups in the template) | Filter's description is in summary. Example usage: {{{ {{ dict|key:key_name }} }}} Filter: {{{ def key(d, key_name): return d[key_name] key = register.filter('key', key) }}} Looking that #2741 is closed as wontfix i have a little hope that it could be added to trunk, but i'll try :). | nobody | Alex Dedul | template filter dict key | 1 | 1 | 0 | 0 | 0 | 0 |
| 3884 | 2007-03-31 07:26:45 | 2011-05-28 05:01:14 | 2022-03-06 03:29:54.907507 | Design decision needed | closed | Contrib apps | Uncategorized | Normal | dev | wontfix | humanize filter `intcomma` should be renamed to `numcomma` | The current filter name doesn't give it justice (it also comma separates floats). Backwards compatibility is easy, and it'd be good to provide a documentation example of it handling a float. #3017 was the inspiration for this ticket. | adrian | SmileyChris | 1 | 0 | 0 | 0 | 0 | 0 | |
| 4198 | 2007-05-02 02:01:54 | 2011-10-09 13:42:11 | 2022-03-06 03:30:45.157472 | Ready for checkin | closed | contrib.admin | Bug | Normal | dev | fixed | admin javascript calendar spacing problem | See the right edge of the calendar in the attached screen capture. Setting the table's width to 100% seems to make the gap disappear (at least in Firefox on Linux). {{{ #!diff Index: django/contrib/admin/media/css/widgets.css =================================================================== --- django/contrib/admin/media/css/widgets.css (revision 5135) +++ django/contrib/admin/media/css/widgets.css (working copy) @@ -45,7 +45,7 @@ .calendarbox, .clockbox { margin:5px auto; font-size:11px; width:16em; text-align:center; background:white; position:relative; } .clockbox { width:9em; } .calendar { margin:0; padding: 0; } -.calendar table { margin:0; padding:0; border-collapse:collapse; background:white; width:99%; } +.calendar table { margin:0; padding:0; border-collapse:collapse; background:white; width:100%; } .calendar caption, .calendarbox h2 { margin: 0; font-size:11px; text-align:center; border-top:none; } .calendar th { font-size:10px; color:#666; padding:2px 3px; text-align:center; background:#e1e1e1 url(../img/admin/nav-bg.gif) 0 50% repeat-x; border-bottom:1px solid #ddd; } .calendar td { font-size:11px; text-align: center; padding: 0; border-top:1px solid #eee; border-bottom:none; } }}} So anyone know a reason why this needs to be 99%? Is this needed so that other browsers don't break? | xian | Gary Wilson <gary.wilson@gmail.com> | 1 | 1 | 0 | 0 | 0 | 1 | |
| 4492 | 2007-06-06 20:31:17 | 2013-09-23 17:04:38 | 2022-03-06 03:31:36.034293 | Accepted | closed | Database layer (models, ORM) | Cleanup/optimization | Normal | dev | fixed | Provide tests for mixed-case column names | Django generates this query, which gives this error: {{{ SELECT setval('"product_item_relatedItems_id_seq"', (SELECT max("id") FROM product_item_relatedItems)); psycopg.ProgrammingError: ERROR: relation "product_item_relateditems" does not exist }}} I'm attaching a patch to generate this query instead: {{{ SELECT setval('"product_item_relatedItems_id_seq"', (SELECT max("id") FROM "product_item_relatedItems")); }}} | nobody | John Shaffer <jshaffer2112@gmail.com> | postgresql psycopg | 1 | 1 | 1 | 0 | 0 | 0 |
| 4528 | 2007-06-11 08:54:18 | 2012-01-18 21:06:03 | 2022-03-06 03:31:42.135490 | Accepted | closed | Core (Management commands) | New feature | Normal | dev | wontfix | Add DATABASE_PRE_SYNCDB to settings | DATABASE_PRE_SYNCDB is a way of letting users execute SQL before tables are created (for instance through syncdb). The main reason for this is users which don't have control over their db - in practise, no rights to set default modes (which has been brought up [http://code.djangoproject.com/ticket/347 earlier]). This would allow users to set the "correct" charset and storage engine for his/her tables. Another useful feature is that django now has the possibility to create a database.[[BR]] Here's a "real world" example: {{{ #!python DATABASE_PRE_SYNCDB = ( "CREATE DATABASE IF NOT EXISTS %s" % DATABASE_NAME, "SET storage_engine=INNODB", ) }}} Alternative approaches to this has been suggested, such as: * Alter tables ''after'' the table has been created (refs: wiki:AlterModelOnSyncDB) * Export SQL, modify and import manually I personally think this implementation is cleaner and allows greater flexibility. | Johan Bergström <bugs@bergstroem.nu> | database_pre_syncdb sql syncdb | 1 | 1 | 0 | 0 | 0 | 0 | |
| 4574 | 2007-06-15 17:10:15 | 2013-09-10 13:07:43 | 2022-03-06 03:31:49.532534 | Accepted | closed | contrib.admin | Cleanup/optimization | Normal | newforms-admin | fixed | add CSS classes to rendered calendar | The current calendar does not add any CSS classes to the rendered table. This patch adds "today" for the current date, "selected" for the selected date (which is added as new function argument), and "noday" for the empty cells. The old style definitions are removed. | berto | calvin@debian.org | nfa-someday javascript admin | 1 | 1 | 0 | 1 | 0 | 1 |
| 4617 | 2007-06-18 21:02:46 | 2011-08-12 14:15:42 | 2022-03-06 03:31:56.431150 | Ready for checkin | closed | contrib.auth | Bug | Normal | dev | fixed | permission_required decorator behaviour is odd | The permission_required() decorator is a great idea, but in practice its behaviour is odd. When used, it first checks whether the user is logged in. If they're not, it redirects to the login page. So far, so good. If they are logged in, it then checks whether they have been granted the specified permission. If they have, it calls the view function and displays the result. Also good. If they're logged in but don't have the specified permission, it redirects to the login page. This is odd. Sure, they might have another user id they can use, but that sounds unusual to me. In most cases, this is just going to confuse them because they're already logged in. Surely it would make more sense to return a HttpResponseForbidden in this case, even if the code to achieve that is a little more complex. | ctrochalakis | cbrand@redback.com | easy-pickings dceu2011 | 1 | 1 | 0 | 0 | 0 | 0 |
| 4907 | 2007-07-17 17:23:20 | 2011-11-28 11:24:47 | 2022-03-06 03:32:56.499135 | Unreviewed | closed | Forms | Uncategorized | Normal | dev | worksforme | MultipleChoiceField cleaned_data returns last choice | When using a MultipleChoiceField, it is possible for the user to select multiple choices, however when accessing cleaned_data, only the last choice is in the dictionary. I've investigated somewhat, and this is happening before the clean method of the field object gets called. I haven't had a chance to investigate further. | adrian | hattawayd+django@gmail.com | MultipleChoiceField cleaned_data | 1 | 1 | 0 | 1 | 0 | 0 |
| 5625 | 2007-09-27 12:20:45 | 2011-09-23 18:43:29 | 2022-03-06 03:34:52.023470 | Accepted | closed | contrib.admin | Bug | Normal | 1.3 | duplicate | Custom admin views get wrong 'Home' breadcrumb url | Custom admin views get "/" as the Home url. The supplied patch changes this to the admin index page using the url function. | nobody | Bjorn Ruud <bjorn.ruud@gmail.com> | 1 | 1 | 1 | 0 | 0 | 0 | |
| 5763 | 2007-10-16 07:39:48 | 2018-01-12 22:32:48 | 2022-03-06 03:35:19.315815 | Design decision needed | closed | Database layer (models, ORM) | New feature | Normal | dev | wontfix | Queryset doesn't have a "not equal" filter operator | Querysets can be filter for 'gt', 'gte', 'lt', 'lte', 'exact'. The ability to filter for inequality / 'ne' is not in the list.[[BR]] Using 'exclude' it is possible to negate a filter, but it's not as clear and clean as a direct filter. Including an inequality operator isn't hard and difficult, I believe.[[BR]] In case this feature is accepted to be included in Django, feel free to assign it to me: I'm willing to take on creating the patch, its documentation and testing. | nobody | jdetaeye | qs-rf | 1 | 0 | 0 | 0 | 0 | 0 |
| 5931 | 2007-11-13 10:07:47 | 2011-05-03 11:51:38 | 2022-03-06 03:35:47.367735 | Ready for checkin | closed | Database layer (models, ORM) | Cleanup/optimization | Normal | dev | fixed | __repr__ for db Fields | Hi, for debugging it is usefull, if repr(mydbfield) displays the name of the field. Small patch inclusive test attached. | nobody | Thomas Güttler <hv@tbz-pariv.de> | 1 | 1 | 0 | 0 | 0 | 0 | |
| 6045 | 2007-11-28 13:14:12 | 2011-08-25 06:07:29 | 2022-03-06 03:36:05.524209 | Ready for checkin | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | Many2Many manager and “TypeError: filter() keywords must be strings” | When using Many2Many fields with unicode data, it raises “TypeError: filter() keywords must be strings” on <model>.<m2m>.all(). The solution is same as in #4315. | Natim | proxor | many2many, related, unicode easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 6135 | 2007-12-05 16:04:43 | 2022-03-03 08:56:36 | 2022-03-06 03:36:19.789794 | Accepted | closed | Template system | New feature | Normal | dev | wontfix | Introduce a short-cut for template filters that has needs_autoescape = True | After the autoescaping was introduced I had to rewrite all filters to comform new requirements: put is_safe=True and needs_autoescape=True where needed. [[BR]] I have written about 25 filters that have needs_autoescape=True and absolutely of them contained contained the same strings {{{ def filter(text, autoescape=None): if autoescape: esc = conditional_escape else: esc = lambda x: x text = esc(text) # Then goes the part which is different for all filters # # return mark_safe(result) }}} I have checked the filters in django. All the same. I think it is way to much of writting. I propose to split property needs_autoescape = True on two properties:[[BR]] needs_manual_autoescape = True, then Do all the stuff above, manually.[[BR]] needs_autoescape = True, then all above steps will do template system for user. All this thinks can do a simple decorator as well. | chinmoy12c | anonymous | autoescape | 1 | 1 | 0 | 0 | 0 | 0 |
| 6283 | 2007-12-29 00:12:06 | 2011-05-22 14:53:02 | 2022-03-06 03:36:43.322907 | Accepted | closed | Forms | New feature | Normal | dev | fixed | NewForms labels are not conditionally escaped | Consider the following code: {{{ required = '<span class="required">*</span>'required = '<span class="required">*</span>' class FooForm(forms.Form): email = forms.EmailField(label='%sEmail Address' % required) username = forms.CharField(label='%sUsername' % required) password = forms.CharField(label='%sPassword' % required, widget=forms.PasswordInput) password2 = forms.CharField(label='%sPassword (Again)' % required, widget=forms.PasswordInput) firstname = forms.CharField(label='First Name') lastname = forms.CharField(label='Last Name') }}} The labels are currently being escaped. Considering that the labels are usually developer/designer created instead of user created, it's probably safe to assume that most times, they are safe from XSS attacks. | rockstar | rockstar | html escape easy-pickings | 1 | 1 | 0 | 1 | 0 | 0 |
| 6338 | 2008-01-07 21:44:47 | 2011-12-30 13:22:17 | 2022-03-06 03:36:52.548469 | Accepted | closed | Database layer (models, ORM) | New feature | Normal | dev | duplicate | Better error message on sqlite3 failure | I recently updgraded my OS and restored my django projects from backup. The django shell worked but when I ran {{{manage.py dbshell}}} I got a exception ending in {{{ File "/usr/lib/python2.5/site-packages/django/db/__init__.py", line 48, in <lambda> runshell = lambda: _import_database_module(_import_path, "client").runshell() File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/client.py", line 6, in runshell os.execvp('sqlite3', args) File "/usr/lib/python2.5/os.py", line 354, in execvp _execvpe(file, args) File "/usr/lib/python2.5/os.py", line 392, in _execvpe func(fullname, *argrest) OSError: [Errno 2] No such file or directory }}} The astute pythoner notes the 3rd line up tries to execute a call to sqlite3 and the actual error message "No such file or directory" is just to indicate that we couldn't execute the sqlite3 binary. It took me a minute to realise that I hadn't yet installed sqlite3 and I was on my way. Should we catch the exception and provide a more explicit error message? See patch - but I don't mind if this is a wontfix. | simeon | simeon | 1 | 1 | 1 | 0 | 0 | 0 | |
| 6412 | 2008-01-18 16:26:41 | 2013-05-21 15:00:30 | 2022-03-06 03:37:04.552373 | Ready for checkin | closed | Core (Other) | New feature | Normal | dev | fixed | [patch] Check for file permissions for proper error messages | This is a duplicate to #1194 with a simpler fix that only affects debug.py. This problem bit me earlier today (in my first django installation) and while it wasn't *that* hard to figure out it would've saved me a good 20 minutes of poking around. Think of the newbies! Also, FWIW the non-readability of templates was caused by a too-restrictive umask (0027) on my part; apparently data file installation from setup.py copies without modifying permissions, so I was stuck. | MarkusH | mbeachy@gmail.com | 1 | 1 | 0 | 0 | 0 | 0 | |
| 6517 | 2008-01-31 08:42:34 | 2020-10-17 10:48:14 | 2022-03-06 03:37:20.749251 | Ready for checkin | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | MySQL: manage.py dbshell does not get charset from DATABASES setting | I noticed that manage.py dbshell doesn't respect the database_options.[[BR]] I ran into an issue with an application we are creating that needs to support mysql and postgre at least, we execute some sql scripts that get piped to manage.py dbshell (to avoid hardcoding psql -U xxx or mysql -u xxx and creating 2 scripts every time). When running an utf8 database with utf8 as our charset in database_options, we ran into some weird encoding issues. The solution for us was to learn mysql/client.py to respect the encoding settings in settings.py Are you opposed to something like this? Attaching small patch that fixes our problem. Let me know if it needs extending to support other backends or database_options. | manav014 | tvrg | 1 | 1 | 0 | 0 | 0 | 0 | |
| 6580 | 2008-02-11 23:09:00 | 2011-05-22 15:05:29 | 2022-03-06 03:37:30.508395 | Ready for checkin | closed | HTTP handling | New feature | Normal | dev | fixed | Default argument to `getlist` on QueryDict | Add an optional default argument to the `getlist` method on QueryDict's. This would work just like it does on get, getattr, etc. | nobody | dcramer | 1 | 1 | 0 | 0 | 0 | 0 | |
| 7060 | 2008-04-22 04:59:51 | 2015-06-04 13:40:56 | 2022-03-06 03:38:37.368798 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | Fix race condition in tutorial vote() view | In the portion of the tutorial where you introduce the template system, you don't make any mention of how to escape output to avoid XSS and similar attacks. Later, when you show code to increment the vote count, you have a classic race condition. Both of these potential bugs could be considered advanced topics, not suitable for an introductory tutorial, but I am of the view that you should show folks the correct way to do things from the get-to. | raphaelm | donald.ball@gmail.com | 1 | 1 | 0 | 0 | 0 | 0 | |
| 7467 | 2008-06-16 15:45:10 | 2013-09-10 12:49:22 | 2022-03-06 03:39:42.670269 | Accepted | closed | contrib.admin | New feature | Normal | dev | fixed | [Improvement] Easier way to overwite the admin welcome message | To change the prominent visual welcome in admin/base.html div user-tools, one must copy the entire admin/base.html template and modify just one line. A block containing this welcome i.e. `block userwelcome` would be useful for customization. | rctay | Jeff Kowalczyk <jtk@yahoo.com> | 1 | 1 | 1 | 0 | 0 | 0 | |
| 7557 | 2008-06-27 16:20:47 | 2013-09-19 13:39:52 | 2022-03-06 03:39:56.852991 | Accepted | closed | Template system | New feature | Normal | dev | fixed | ValueError does not catch all cases when trying to determine type of variable in template.Variable class | {{{ File "/usr/lib/python2.5/site-packages/caktus/django/templatetags/__init__.py", line 59, in __init__ self.kwargs = dict([(k, Variable(arg)) for k, arg in kwargs.items()]) File "/usr/lib/python2.5/site-packages/django/template/__init__.py", line 628, in __init__ self.literal = float(var) TypeError: float() argument must be a string or a number }}} In my case "var" was a dict. obviously dict is not a supported variable type, so django should raise a more obvious error here. | saz | tobias | 1 | 1 | 0 | 0 | 0 | 0 | |
| 7704 | 2008-07-10 12:04:10 | 2012-02-12 15:10:09 | 2022-03-06 03:40:19.048408 | Accepted | closed | Internationalization | Bug | Normal | 1.0 | fixed | JS comments put after statements break make-messages.py output | {{{ #!rst To test, make a JS file (say ``myfile.js``) with the following valid JS content: .. code-block:: js var a = 1; if(a != 2 && a != 5) //this comment breaks the file { //this does not alert(gettext("foobar")); } Running ``make-messages.py -d djangojs -a`` will then yield the following output for that (in the ``myfile.js.py`` intermediate file it produces): .. code-block:: js var a = 1; if(a != 2 && a != 5) //this comment breaks the file { #this does not alert(gettext("foobar")); } As you can see, the comment after the if statement was not replaced, and since ``xgettext`` is then run in Perl mode, it seems to choke on that input. The result depends on the exact code: This example will cause only that next ``gettext("foobar")`` not to be generated (ones further down in the code will). With other code I had that had a similar line, nothing was generated. The failure is silent and the only way to know is by checking the gettext output (or lack thereof :). This is due to the regexp in make-messages: ``pythonize_re = re.compile(r'\n\s*//')`` and then the replacement code: ``src = pythonize_re.sub('\n#', src)`` That assumes that comments come after newlines. I'm not submitting a patch right now because I'm unsure about the best regexp to use for this that will get all the valid JS comment cases (or if that is even something the django devs want to do). At the very least, if you all choose not to address this in the code, there should be a note in the documentation telling folks to always put JS comments on their own lines. As ``make-messages.py`` is now included in django-admin AFAIK, I've categorized it to that. }}} | nedbatchelder | robbyd | djangojs, make-messages | 1 | 1 | 1 | 0 | 0 | 0 |
| 7758 | 2008-07-15 13:17:00 | 2012-02-09 18:56:33 | 2022-03-06 03:40:28.783264 | Ready for checkin | closed | contrib.admin | New feature | Normal | dev | fixed | Can't override the form_url for change_view - like you can with add_view | Refs: [http://code.djangoproject.com/ticket/7757 #7757] As there is a way to override the form_url for the add_view there should also be a way to override for the change_view. Use case example - add GET params to the form action so that you can pass GET data as well as post - for callback etc.. | nobody | Rozza | newforms admin customization | 1 | 1 | 0 | 1 | 1 | 0 |
| 8065 | 2008-08-01 02:39:05 | 2015-12-26 22:59:20 | 2022-03-06 03:41:17.355194 | Accepted | closed | Database layer (models, ORM) | New feature | Normal | dev | fixed | Calling queyset.in_bulk (without any arguments) should evaluate the whole queryset. | in_bulk() works well if you know beforehand which ids you want to pull out. It becomes irritating, however, if you want to map an entire queryset at once. Right now you have to do the following: {{{ id_list=list(Book.objects.filter(author__name='Douglas Adams').values_list('id', flat=True)) bulk=Book.objects.in_bulk(id_list) }}} With the patch included, the following will now work: {{{ bulk=Book.objects.filter(author__name='Douglas Adams').in_bulk() }}} I feel the second way is easier to read, and I really don't see any reason why people shouldn't be allowed to do this. | bxm156 | ElliottM | in_bulk filter list | 1 | 1 | 0 | 0 | 0 | 0 |
| 8527 | 2008-08-25 03:25:18 | 2011-05-07 16:59:08 | 2022-03-06 03:42:30.237273 | Ready for checkin | closed | contrib.localflavor | New feature | Normal | dev | fixed | CAPostalCodeField made more forgiving of input format | Similar to the work done in [6952] for #5670 for UKPostcodeField, this change is more forgiving of Canadian postal code input. Uppercase, lowercase, with or without a space in between the two segments. The clean method returns a nice, clean version -- enter 'K1A 0A9', 'k1a 0A9', 'k1a0a9', or even ' k1A 0A9 ' and it will return the standard form: 'K1A 0A9'. Patch contains code change and additions to regression tests. | nobody | dharris | ca postal code | 1 | 1 | 0 | 0 | 0 | 0 |
| 8918 | 2008-09-06 20:47:16 | 2013-10-14 18:36:17 | 2022-03-06 03:43:31.077284 | Accepted | closed | File uploads/storage | New feature | Normal | dev | fixed | FileField upload_to should not be required for custom backends | For some file storage backends, the upload_to could be unnecessary. For example, I have an S3 backend and don't need any keys or prefixes for my files. Currently an error is thrown if upload_to is missing or empty: "file": FileFields require an "upload_to" attribute. Could upload_to be optional if the storage backend is custom? | nobody | leahculver | FileField, files, upload, S3, upload_to | 1 | 1 | 1 | 0 | 0 | 0 |
| 9532 | 2008-11-06 05:52:34 | 2014-05-14 16:03:09 | 2022-03-06 03:45:07.452245 | Accepted | closed | Forms | New feature | Normal | dev | fixed | Add min_num and validate_min on formsets | Formsets have a max_num for limiting the number of forms, but no way to ensure a minimum. Use case: I want an address formset that displays all addresses that have been created and no extras, unless there are no addresses, then one empty form should be displayed. I would set extra=0 and min_num=1. Patch included is just a beginning. I may have missed a function or two and I haven't touched docs or tests. | yokomizor | gsf | 1 | 1 | 1 | 0 | 0 | 0 | |
| 9655 | 2008-11-21 09:36:47 | 2012-01-07 18:15:29 | 2022-03-06 03:45:22.934384 | Accepted | closed | Template system | Bug | Normal | 1.0 | fixed | urlize should not quote already quoted urls. | This template: {{{ {{ user.homepage:urlize }} }}} When user.homepage is "http://hi.baidu.com/%D6%D8%D0%C2%BF%AA%CA%BC", the output will be "http://hi.baidu.com/%25D6%25D8%25D0%25C2%25BF%25AA%25CA%25BC", It quoted '%' char in source url and outputs an invalid url. | aaugustin | flytwokites | urlize | 1 | 1 | 0 | 1 | 1 | 0 |
| 10098 | 2009-01-22 17:30:55 | 2011-05-07 09:22:52 | 2022-03-06 03:46:27.091752 | Unreviewed | closed | Uncategorized | Uncategorized | Normal | wontfix | LazySettings.get function with default value | Add a 'get' method to LazySettings class in order to easily get a settings.py variable or its default value. settings.get(var_name, default) instead of try: myvar = settings.var except AttributeError: myvar = default_value my current patch is: --- django/conf/__init__.py 2009-01-22 18:19:38.585001432 +0100 +++ django/conf/__init__.py.new 2009-01-22 18:23:00.221043810 +0100 @@ -41,6 +41,13 @@ self._import_settings() setattr(self._target, name, value) + def get(self, name, default=None): + + try: + getattr(self, name) + except AttributeError: + return default + def _import_settings(self): """ Load the settings module pointed to by the environment variable. This | nobody | fero | 1 | 1 | 1 | 0 | 0 | |||
| 10494 | 2009-03-13 15:05:38 | 2021-03-08 08:18:51 | 2022-03-06 03:47:26.285157 | Unreviewed | closed | Database layer (models, ORM) | New feature | Normal | 1.0 | wontfix | show query params DoesNotExist from QuerySet.get | In db.models.query.QuerySet.get, it'd be nice if it included kwargs when raising DoesNotExist, like it does when it raises MultipleObjectsReturned | zefciu | brondsem | 1 | 0 | 0 | 0 | 0 | 0 | |
| 10504 | 2009-03-14 21:57:12 | 2013-02-11 00:45:00 | 2022-03-06 03:47:28.132451 | Accepted | closed | HTTP handling | Cleanup/optimization | Normal | 1.0 | fixed | Consistency between HttpResponse* params and render_to_response | I was just browsing through some of the Django code and came across the new-ish (to me) addition of the content_type alias for the mimetype parameter to HttpResponse and company. Wondering about the rationale behind this decision, I came across ticket #3526, which may be helpful to review in evaluating this ticket. In light of this, (and just for consistency) I thought it would probably be a good idea to allow render_to_response to pass content_type along to HttpResponse. I'll attach a simple patch that does this. Also, this patch will conflict with another patch (#9081) I've submitted that has been accepted but not yet committed. It'll be very easy to resolve, but I'm unsure if I should take any special measures about this. | nobody | bhagany | 1 | 1 | 1 | 0 | 0 | 0 | |
| 10762 | 2009-04-07 21:19:17 | 2012-01-09 21:42:04 | 2022-03-06 03:48:08.658720 | Accepted | closed | HTTP handling | Cleanup/optimization | Normal | dev | fixed | Gzip Middleware Should Compress 201 (Created) Responses | Hi, RESTful web services that use POST for creation of resources often respond with a representation of the newly created resource, which can be lengthy. However, the appropriate status code is 201, which the Gzip middleware ignores. There's a trivial patch attached that contains these lines: {{{ - if response.status_code != 200 or len(response.content) < 200: + if response.status_code not in (200, 201) or len(response.content) < 200: }}} This is not a particularly big deal, just a convenience. Thanks, Rick | aaugustin | rwagner@physics.ucsd.edu | middleware gzip | 1 | 1 | 0 | 0 | 0 | 0 |
| 11321 | 2009-06-15 19:04:18 | 2016-05-01 10:44:03 | 2022-03-06 03:49:39.165566 | Accepted | closed | contrib.humanize | Bug | Normal | dev | fixed | Bug with humanize and timezones | Humanize's naturalday filter uses "date.today()" to determine relative dates. This is not valid if you pass it a datetime with the tzinfo field set. The following patch uses a datetime object as an intermediary to correct this behavior. | nobody | aarond10 | humanize, naturalday, timezone | 1 | 1 | 0 | 0 | 1 | 1 |
| 11400 | 2009-06-29 12:37:23 | 2013-08-14 11:48:43 | 2022-03-06 03:49:50.376764 | Accepted | closed | contrib.auth | New feature | Normal | dev | fixed | Pass kwargs from AbstractUser.email_user() to send_mail() | Add ``fail_silently=False`` to ``User.email_user`` and pass it to ``send_mail``. | susan | Jug_ | email user fail_silently | 1 | 1 | 1 | 0 | 0 | 0 |
| 11595 | 2009-07-29 20:11:34 | 2011-08-22 00:48:53 | 2022-03-06 03:50:19.115253 | Ready for checkin | closed | Core (Serialization) | Cleanup/optimization | Normal | 1.0 | fixed | Fixture validation errors should report their data | For example, here's what {{{django/db/models/fields/__init__.py}}} has for lines 341-348: {{{#!python def to_python(self, value): if value is None: return value try: return int(value) except (TypeError, ValueError): raise exceptions.ValidationError(_("This value must be an integer.")) }}} Changing line 348 to: {{{#!python _("(%s) must be an integer." % value)) }}} means that when you convert a text field to a joined object, you know which one's broken where. (Other places in that file do the same thing) | raulcd | freyley | easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 11674 | 2009-08-10 04:05:00 | 2011-09-22 05:48:43 | 2022-03-06 03:50:30.095485 | Ready for checkin | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | documentation clarifications on ModelForms & ModelFormsets Meta fields | Based on discussion from this thread: http://groups.google.com/group/django-users/browse_thread/thread/19a8b01d87819119/217ac9ecee6f474f the documentation of the fields attribute of a ModelForms inner Meta class should be clarified/expanded. Basically, add a sentence that states if you define fields (or excludes) on an inner Meta class, any excluded field 1) will not appear on the form by default, 2) will not be initialized from a model instance if manually added back to the form, and 3) will not be set by the form's save method. A similar caveat should be added to the ModelFormset documentation. In the current documentation: http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form Points 1 & 3 are mentioned, but 2 is not. | raulcd | david.h.haas@gmail.com | ModelForm, Meta class, easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 11857 | 2009-09-09 23:32:30 | 2013-09-07 00:45:12 | 2022-03-06 03:50:55.933412 | Accepted | closed | File uploads/storage | Bug | Normal | fixed | TemporaryFile class is missing the closed - attribute | Hi, the TemporaryFile-class (core/files/temp.py), is missing the 'closed'-attribute. It inherits from FileProxyMixin, but this class also doesn't have a closed-attribute. If I want to access the 'width' attribute of an ImageFieldFile, I get an "'TemporaryFile' object has no attribute 'closed'" - error. Traceback: {{{ File "D:\websites\picality\src\picalityproject\picality\models\image.py" in save 98. print self.image.width File "D:\websites\django-trunk\django\core\files\images.py" in _get_width 15. return self._get_image_dimensions()[0] File "D:\websites\django-trunk\django\core\files\images.py" in _get_image_dimensions 24. close = self.closed File "D:\websites\django-trunk\django\db\models\fields\files.py" in _get_closed 126. return file is None or file.closed File "D:\websites\django-trunk\django\core\files\base.py" in _get_closed 51. return not self.file or self.file.closed Exception Type: AttributeError at /upload/ Exception Value: 'TemporaryFile' object has no attribute 'closed' }}} But somehow this error occurs only if I want to upload 2 image files in the same form -> because if I upload only one image, the self.image.file.file is a StringIO object, which has a 'closed' attribute. | Christopher Adams <christopher.r.adams@gmail.com> | andi100 | TemporaryFile closed windows | 1 | 1 | 0 | 0 | 0 | 0 | |
| 11989 | 2009-10-06 14:52:00 | 2011-06-11 16:22:46 | 2022-03-06 03:51:19.425566 | Ready for checkin | closed | Template system | New feature | Normal | 1.1 | fixed | Allow @register.inclusion_tag to take a template as well as a template name | Sometimes, I want the convenience of an inclusion_tag without specifying an external template. I can't use simple_tag because I need context access. @inclusion_tag allows either a template name or an iterable of template names. The attach patch allows a template to be given directly, as well. I noticed @inclusion_tag doesn't seem to be currently tested, and this patch doesn't include tests. Where should @inclusion_tag tests live? | nobody | jdunck | 1 | 1 | 0 | 0 | 0 | 0 | |
| 12073 | 2009-10-22 14:26:22 | 2011-11-20 11:12:38 | 2022-03-06 03:51:32.580655 | Accepted | closed | contrib.admin | New feature | Normal | dev | fixed | AdminDateWidget and AdminTimeWidget not passing though additional attrs | Suggest a change to allow additional user-defined attributes to be passed though. currently they're passed in but not though: CURRENT: {{{ #!python class AdminDateWidget(forms.TextInput): class Media: js = (settings.ADMIN_MEDIA_PREFIX + "js/calendar.js", settings.ADMIN_MEDIA_PREFIX + "js/admin/DateTimeShortcuts.js") def __init__(self, attrs={}): super(AdminDateWidget, self).__init__(attrs={'class': 'vDateField', 'size': '10'}) class AdminTimeWidget(forms.TextInput): class Media: js = (settings.ADMIN_MEDIA_PREFIX + "js/calendar.js", settings.ADMIN_MEDIA_PREFIX + "js/admin/DateTimeShortcuts.js") def __init__(self, attrs={}): super(AdminTimeWidget, self).__init__(attrs={'class': 'vTimeField', 'size': '8'}) }}} SUGGESTED: {{{ #!python class AdminDateWidget(forms.TextInput): class Media: js = (settings.ADMIN_MEDIA_PREFIX + "js/calendar.js", settings.ADMIN_MEDIA_PREFIX + "js/admin/DateTimeShortcuts.js") def __init__(self, attrs={}): attrs.update({'class': 'vDateField', 'size': '10'}) super(AdminDateWidget, self).__init__(attrs=attrs) class AdminTimeWidget(forms.TextInput): class Media: js = (settings.ADMIN_MEDIA_PREFIX + "js/calendar.js", settings.ADMIN_MEDIA_PREFIX + "js/admin/DateTimeShortcuts.js") def __init__(self, attrs={}): attrs.update({'class': 'vTimeField', 'size': '8'}) super(AdminTimeWidget, self).__init__(attrs=attrs) }}} | nobody | elliss | widgets date time calendar | 1 | 1 | 0 | 0 | 0 | 0 |
| 12128 | 2009-11-02 01:01:15 | 2015-11-17 12:03:42 | 2022-03-06 03:51:40.858441 | Unreviewed | closed | contrib.auth | Uncategorized | Normal | 1.1 | fixed | Remove restrictive 30 character limit from username of AuthenticationForm. | While #8274 at least makes it possible to override the form now, the current default doesn't make sense. The AuthenticationForm is not directly tied to the User model - any backend could use it. Therefore, there should not be a default max_length for the username. | nobody | SmileyChris | 1 | 0 | 0 | 0 | 0 | 1 | |
| 12579 | 2010-01-11 13:31:15 | 2013-07-04 12:34:32 | 2022-03-06 03:52:56.089565 | Accepted | closed | Documentation | Bug | Normal | 1.0 | fixed | QuerySet.get_or_create()'s behavior depends on database's uniqueness restrictions | {{{QuerySet.get_or_create()}}} works as expected, IFF the kwargs that are provided correspond to database columns with appropriate uniqueness restrictions. In other words: {{{get_or_create()}}} depends on an IntegrityError being raised under certain circumstances. If you have a database that does not do this, f.e. because a table's uniqueness logic cannot be expressed with the database's {{{UNIQUE}}} construct. For instance: Given the following table: {{{CREATE TABLE t1 (i INT, flag TINYINT, parent_id INT, PRIMARY KEY (i)) ENGINE = InnoDB;}}} An additional restriction, one which cannot be expressed in the table definition, is that only one record can exist with {{{flag=1}}} for every given {{{parent_id}}}. The following code gives the impression that we enforce said restriction: {{{T1.objects.get_or_create(parent_id=3, flag=1)}}}. But this is a false impression, as two concurrent transactions executing this same code can (and will on a regular basis) result in two records with {{{parent_id=3}}} and {{{flag=1}}}. This is the result of both transactions trying to {{{get()}}} a record with {{{parent_id=3}}} and {{{flag=1}}} before any of them has inserted this record. So both transactions will conclude they need to {{{create{}}}} the record, which will be allowed by the database and thus an inconsistency will enter the database. Now the ideal scenario would be that race conditions are prevented regardless of how the underlying database table is defined. But I am not sure if this is a feasible approach. At the very least I think people who use {{{get_or_create()}}} need to be aware that it can give rise to concurrency issues, unless they follow some basic guidelines... something like that. | Tim Graham <timograham@gmail.com> | timmolendijk | get_or_create concurrency race unique documentation | 1 | 1 | 0 | 0 | 0 | 0 |
| 12666 | 2010-01-22 23:31:27 | 2016-06-04 13:53:32 | 2022-03-06 03:53:08.350803 | Accepted | closed | Core (Mail) | New feature | Normal | 1.1 | fixed | Setting for sending email using localtime instead of UTC | I would like to be able to send emails using local time in the Date header instead of UTC by default. Changes needed (based on Django 1.1.1): * `django/conf/global_settings.py`: * Add `"EMAIL_USE_LOCALTIME = False"` (won't sent using local time by default unless you explicitly enable it) * `django/core/mail.py`: * Change `"msg['Date'] = formatdate()"` to `"msg['Date'] = formatdate(localtime=settings.EMAIL_USE_LOCALTIME)"` | aisipos | net147 | 1 | 1 | 1 | 0 | 0 | 0 | |
| 12670 | 2010-01-23 02:54:01 | 2014-02-25 16:21:42 | 2022-03-06 03:53:08.822487 | Design decision needed | closed | File uploads/storage | Cleanup/optimization | Normal | dev | fixed | TemporaryUploadedFile objects do not respect FILE_UPLOAD_PERMISSIONS | From what I can tell, `TemporaryUploadedFile` objects do not respect the FILE_UPLOAD_PERMISSIONS setting. This setting is only used by FileSystemStorage, which is the default DEFAULT_FILE_STORAGE, which is used by *model* FileFields, but not by forms. Having temporary uploaded files respect FILE_UPLOAD_PERMISSIONS seems to have been the original intention if you read #8454, and to me the docs at http://docs.djangoproject.com/en/dev/topics/http/file-uploads/ implied that this was the case as well. | rednaw | andrewbadr | nlsprint14 | 1 | 0 | 0 | 0 | 1 | 0 |
| 12756 | 2010-02-03 07:54:52 | 2013-09-07 00:02:43 | 2022-03-06 03:53:22.637997 | Accepted | closed | Core (Serialization) | Cleanup/optimization | Normal | 1.1 | fixed | dumpdata error message should note pyyaml requirement | When trying to dumping some data to yaml, if pyyaml is not installed, one gets the following error message: $ ./manage-dev dumpdata --indent=2 --format=yaml auth Error: Unknown serialization format: yaml It would be very helpful, if the error message would mention the lack of pyyaml, for example by saying: "Error: Unknown serialization format: yaml (you need to install PyYAML perhaps?)" Also, the PyYAML requirement should be mentioned on the http://docs.djangoproject.com/en/dev/howto/initial-data/ page, as well. The point is that although the need for pyyaml is mentioned on the "Serializing Django objects" page, when one uses the documentation as a reference, one might miss that page resulting in some head-scratching as to how come yaml doesn't work even though the documentation claims it does. | berto | abeld@hal.elte.hu | 1 | 0 | 0 | 0 | 0 | 0 | |
| 13060 | 2010-03-08 18:09:30 | 2020-10-21 10:36:09 | 2022-03-06 03:54:09.518833 | Ready for checkin | closed | Forms | Cleanup/optimization | Normal | dev | fixed | ManagementForm exception in case of bad prefix should be easier to understand | If user adds multiple formsets with prefixes, and specifies the prefix incorrectly when binding the form and validating: {{{ some_formset = SomeFormSet(request.POST, 'articles') }}} instead of: {{{ some_formset = SomeFormSet(request.POST, prefix='articles') }}} Django "suppresses" the original exception and raises only relatively unhelpful "ManagementForm data is missing or has been tampered with". In file django/forms/formsets.py, line 57: {{{ 54. if self.data or self.files: 55. form = ManagementForm(self.data, auto_id=self.auto_id, prefix=self.prefix) 56. if not form.is_valid(): 57. raise ValidationError('ManagementForm data is missing or has been tampered with') }}} Suggestion: include form._errors in output, because for such a small bug in code, it can take a really long time find it. {{{ {'INITIAL_FORMS': [u'This field is required.'], 'MAX_NUM_FORMS': [u'This field is required.'], 'TOTAL_FORMS': [u'This field is required.']} }}} | manav014 | Karel | formset, ValidationError, ManagementForm | 1 | 1 | 0 | 0 | 0 | 0 |
| 13142 | 2010-03-18 10:25:45 | 2013-07-12 18:46:28 | 2022-03-06 03:54:22.568679 | Accepted | closed | Core (Mail) | New feature | Normal | dev | duplicate | Add support for SSL connections in core.mail.backends.smtp | Current code for smtp backend dont allow using SSL connections to mail server, patch add this support | jwmayfield | serg.partizan@gmail.com | 1 | 1 | 1 | 0 | 0 | 0 | |
| 13182 | 2010-03-23 10:55:33 | 2013-09-01 13:52:50 | 2022-03-06 03:54:29.436296 | Accepted | closed | Core (Serialization) | Cleanup/optimization | Normal | dev | fixed | Remove useless whitespaces in JSON dump with indent option | When a JSON dump is done with the indent option, all lines are terminated by a whitespace and a newline. The trailing whitespace is useless, it increases the file size and emits a warning in my editor and git. The goal of my patch is to remove these whitespaces (specific to the JSON serializer). | martmatwarne | stephaner | 1 | 1 | 1 | 0 | 0 | 0 | |
| 13462 | 2010-05-02 15:55:45 | 2013-06-11 15:33:02 | 2022-03-06 03:55:16.157589 | Accepted | closed | GIS | Bug | Normal | dev | wontfix | GoogleMaps object should default to version 2 of google maps | Currently, the google maps will default to version "2.x" if you do not specify a version in your settings. Version "2.x" is basically the alpha branch of google maps: http://code.google.com/p/gmaps-api-issues/wiki/JavascriptMapsAPIChangelog It should default to either "2.s" or just "2". Note: the `map.setUIToDefault();` method (which GoogleMaps adds by default) does not work in "2.s" (currently), so that would have to be changed if "2.s" is decided on instead. | EvilDMP | nbv4 | 1 | 1 | 1 | 0 | 0 | 0 | |
| 13575 | 2010-05-20 11:43:47 | 2012-12-30 23:47:38 | 2022-03-06 03:55:35.346264 | Unreviewed | closed | Internationalization | Uncategorized | Normal | dev | worksforme | nb/nn locale not a valid python locale | If this code is run in the django shell: {{{ #!python from django.utils.translation.trans_real import get_language_from_request g = get_language_from_request from django.http import HttpRequest r = HttpRequest() r.COOKIES = {} r.META = {'HTTP_ACCEPT_LANGUAGE': 'nb,nn;q=0.7,en;q=0.3'} g(r) }}} The returned language code is "en". The reason for this is that neither "no" or "nn" is in locale.locale_alias. Attaching temporary fix. | nobody | oyvind | locale python nb nn norwegian nynorsk | 1 | 0 | 0 | 0 | 0 | 0 |
| 13629 | 2010-05-27 12:10:55 | 2013-07-21 20:34:03 | 2022-03-06 03:55:44.240856 | Accepted | closed | contrib.admin | New feature | Normal | dev | fixed | Admin Changelist: add app-model_name class to <body> tag | Change form pages have "app-model_name" classes in body tag, for eg: <body class="main-client change-form">. Change list pages don't, which makes them unrecognizable in JavaScript code. Example use case: I'm currently implementing jQuery tooltips for searchbars to give user information about which model's fields are searchable in each change list. Currently to achieve this I had to override ModelAdmin.changelist_view (to add model._meta to context) and change_list.html template. This is ok but I think it would be nice to have it already done in django? | tcsorrel | naos | 1 | 1 | 0 | 0 | 0 | 1 | |
| 13640 | 2010-05-27 17:57:10 | 2011-11-13 15:09:09 | 2022-03-06 03:55:45.786896 | Accepted | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | add_filter in django/db/models/ sql/query.py causes exception when model have 'evaluate' attribute | I was migrating some django project recently from django 1.0.4 to 1.2. In Django 1.2/1.1 I found that if model have 'evaluate' attribute then one will get exception in admin edit page for that model if the page contains inline forms with related models: {{{ Exception Value: 'Shipper' object has no attribute 'prepare' Exception Location: .../django/db/models/sql/expressions.py in __init__, line 12 }}} It is caused by the fact that add_filter function in django/db/models/sql/query.py does such a check: {{{ ... 1005. elif hasattr(value, 'evaluate'): 1006. # If value is a query expression, evaluate it 1007. value = SQLEvaluator(value, self) ... 1008. having_clause = value.contains_aggregate ... }}} The problem is that "value" in this case is Shipper model which in have "evaluate" method so it is recognized as query expression here. Greetings, | tobias | LukaszKorzybski | 1 | 1 | 0 | 0 | 0 | 0 | |
| 13696 | 2010-06-04 22:24:37 | 2013-07-21 17:16:57 | 2022-03-06 03:55:54.432211 | Accepted | closed | contrib.admin | Bug | Normal | 1.2 | fixed | Admin Edit Inline templates don' t output hidden field for PK when it isn't an autoField and has editable=False | In my project I'm using a UUID field where I generate the uuid myself in python, and don't rely on any sequences on the database side. Because of this I just use a CharField field, and when used i set it to be the primary key. However because of this usage the field does not have 'has_auto_field' == True, This causes the edit inline forms for existing objects to not output the hidden field to hold the PK for the existing object. Right now this template requires the inline_admin_form.has_auto_field == True, for it to output the pk_field.field, however I think this should always output the primary key for the object. This line occurs on line 30 of contrib/admin/templates/admin/edit_inline/tabular.html in django 1.2.1 {% if inline_admin_form.has_auto_field %}{{ inline_admin_form.pk_field.field }}{% endif %} contrib/admin/templates/admin/edit_inline/tabular.html {{{ <td class="original"> {% if inline_admin_form.original or inline_admin_form.show_url %}<p> {% if inline_admin_form.original %} {{ inline_admin_form.original }}{% endif %} {% if inline_admin_form.show_url %}<a href="../../../r/{{ inline_admin_form.original_content_type_id }}/{{ inline_admin_form.original.id }}/">{% trans "View on site" %}</a>{% endif %} </p>{% endif %} {% if inline_admin_form.has_auto_field %}{{ inline_admin_form.pk_field.field }}{% endif %} {{ inline_admin_form.fk_field.field }} {% spaceless %} {% for fieldset in inline_admin_form %} {% for line in fieldset %} {% for field in line %} {% if field.is_hidden %} {{ field.field }} {% endif %} {% endfor %} {% endfor %} {% endfor %} {% endspaceless %} </td> }}} | dArignac | evan.reiser@gmail.com | inline templates | 1 | 1 | 0 | 0 | 0 | 0 |
| 13721 | 2010-06-08 16:52:27 | 2014-07-29 15:35:37 | 2022-03-06 03:55:58.329218 | Accepted | closed | File uploads/storage | New feature | Normal | dev | fixed | pass extra content-type values to file upload handlers | Currently, file upload handlers can only get the actual content type and charset, but App Engine's Blobstore file service passes a few extra vales to the content type which are needed to get the uploaded file's identifier ("blob-key"). Here's a sample snippet of an HTTP upload request's POST data: {{{ --===============0880245784== Content-Type: message/external-body; blob-key="WEexn9L82wky30ADBOWqYA=="; access-type="X-AppEngine-BlobKey" MIME-Version: 1.0 Content-Disposition: form-data; name="file"; filename="django-nonrel.diff" Content-Type: application/octet-stream MIME-Version: 1.0 Content-Length: 8522 content-type: application/octet-stream content-disposition: form-data; name="file"; filename="django-nonrel.diff" X-AppEngine-Upload-Creation: 2010-06-08 15:34:32.685000 --===============0880245784==-- }}} The attached patch changes the file upload handling code such that it passes a dictionary with all extra content type arguments to the upload handler. With this I was able to successfully upload files to a model's FileField via a ModelForm. | mvschaik | wkornewald | 1 | 1 | 0 | 0 | 0 | 0 | |
| 13875 | 2010-07-03 15:45:22 | 2016-02-04 16:57:39 | 2022-03-06 03:56:24.836337 | Ready for checkin | closed | contrib.admin | New feature | Normal | dev | fixed | submit_row templatetag should pass whole context | django submit_row inclusion tag doesn't pass extra_context from ModelAdmin.(add|change|..)_view to submit_row.html template. Because of that, i cannot add extra button to submit row (i.e. print invoice). this tag should pass whole context to the template | dArignac | drul | 1 | 1 | 0 | 0 | 0 | 1 | |
| 13883 | 2010-07-05 11:57:20 | 2021-10-12 07:37:18 | 2022-03-06 03:56:26.063181 | Accepted | new | contrib.admin | Bug | Normal | dev | SelectBox.js with grouping (optgroup elements) | Current implementation ignores optgroup elements in selects. Here is an example of SelectBox.js which takes optgroups in account, but uses jQuery (already used by django admin anyway). The script is not perfectly written. I can rewrite this to meet django's coding/quality standards if needed. | SardarNL | admin, SelectBox, optgroup, sprintdec2010 | 1 | 1 | 1 | 0 | 0 | 1 | ||
| 13958 | 2010-07-17 10:37:44 | 2013-05-18 16:31:17 | 2022-03-06 03:56:37.680422 | Accepted | closed | Core (Other) | Bug | Normal | 1.2 | fixed | There is an error, when a source file with backslash-r returns is interpreted by the Python error report page. | There is an error, when a source file with backslash-r returns is interpreted by the Python error report page. Due to a hard split on backslah-n, the lineno is out of range. Also it is not clear what the name of the file is where this goes wrong. Adding source = source.replace('\r', '\n') solves the problem, but maybe not structural enough. Kind regards, Petr van Blokland buro@petr.com {{{ Traceback (most recent call last): File "/Library/Python/2.5/site-packages/django/core/servers/basehttp.py", line 279, in run self.result = application(self.environ, self.start_response) File "/Library/Python/2.5/site-packages/django/core/servers/basehttp.py", line 651, in __call__ return self.application(environ, start_response) File "/Library/Python/2.5/site-packages/django/core/handlers/wsgi.py", line 241, in __call__ response = self.get_response(request) File "/Library/Python/2.5/site-packages/django/core/handlers/base.py", line 137, in get_response return self.handle_uncaught_exception(request, resolver, exc_info) File "/Library/Python/2.5/site-packages/django/core/handlers/base.py", line 157, in handle_uncaught_exception return debug.technical_500_response(request, *exc_info) File "/Library/Python/2.5/site-packages/django/views/debug.py", line 58, in technical_500_response html = reporter.get_traceback_html() File "/Library/Python/2.5/site-packages/django/views/debug.py", line 109, in get_traceback_html frames = self.get_traceback_frames() File "/Library/Python/2.5/site-packages/django/views/debug.py", line 228, in get_traceback_frames pre_context_lineno, pre_context, context_line, post_context = self._get_lines_from_file(filename, lineno, 7, loader, module_name) File "/Library/Python/2.5/site-packages/django/views/debug.py", line 209, in _get_lines_from_file context_line = source[lineno].strip('\n') IndexError: list index out of range }}} | saz | petrvanblokland | 1 | 1 | 0 | 0 | 0 | 0 | |
| 14028 | 2010-07-29 20:36:38 | 2013-09-23 15:52:32 | 2022-03-06 03:56:47.865425 | Accepted | closed | Database layer (models, ORM) | Bug | Normal | 1.2 | fixed | setting db_column to same value as another column should not validate | Consider having a model {{{ class FooBar(models.Model): foo = models.IntegerField() bar = models.IntegerField(db_column='foo') class Meta: db_table = 'foobar' }}} This does not raise any validation errors, even though the model clearly is not valid. | helenst | akaariai | validation, sprintdec2010 | 1 | 0 | 0 | 0 | 0 | 0 |
| 14093 | 2010-08-11 11:30:48 | 2012-10-28 11:41:12 | 2022-03-06 03:56:58.992838 | Accepted | closed | contrib.sessions | Bug | Normal | 1.2 | fixed | Confusing error when failing to create a session key because the cache is unavailable | Hi, We are using Django 1.2.1, cache session backend and from time to time, on higher traffic (but not so much, ~600 online users in 5 minutes) a few requests ends with exception: Traceback (most recent call last): File "/usr/lib64/python2.6/site-packages/django/core/handlers/base.py", line 80, in get_response response = middleware_method(request) File "/home/wonderlife/app/request.py", line 78, in process_request if request.user.is_authenticated(): File "/usr/lib64/python2.6/site-packages/django/contrib/auth/middleware.py", line 9, in __get__ request._cached_user = get_user(request) File "/usr/lib64/python2.6/site-packages/django/contrib/auth/__init__.py", line 97, in get_user user_id = request.session[SESSION_KEY] File "/usr/lib64/python2.6/site-packages/django/contrib/sessions/backends/base.py", line 46, in __getitem__ return self._session[key] File "/usr/lib64/python2.6/site-packages/django/contrib/sessions/backends/base.py", line 172, in _get_session self._session_cache = self.load() File "/usr/lib64/python2.6/site-packages/django/contrib/sessions/backends/cache.py", line 16, in load self.create() File "/usr/lib64/python2.6/site-packages/django/contrib/sessions/backends/cache.py", line 33, in create raise RuntimeError("Unable to create a new session key.") RuntimeError: Unable to create a new session key. | aaugustin | szymon@mwg.pl | session, cache, session key | 1 | 1 | 0 | 0 | 0 | 0 |
| 14415 | 2010-10-07 10:16:41 | 2016-05-18 01:35:04 | 2022-03-06 03:57:49.261110 | Accepted | closed | Testing framework | Bug | Normal | dev | fixed | Multiple aliases for one database: testing problems | In a setting where the multiple-databases feature is used to create multiple aliases for one database, the testing framework can get a little confused. For ease of reference, assume we have the following dictionary defining database parameters: {{{ db_params = dict ( NAME = 'main', ENGINE = 'django.db.backends.whatever', USER = 'user', PASSWORD = 'password', HOST = '', PORT = '' ) }}} == The relatively benign cases == In these cases, the test framework just treats the two aliases as separate databases; which means it first creates the test database for one alias, then tries to create the test database for the second one, running into an error because (of course) it already exists. The user is asked to choose between destroying the existing database (in order to recreate it) and canceling the test. In cases where database routers constrict models to a specific alias, this may completely prevent testing (or at least some of the tests). This happens if at least one of two conditions hold: === The dictionaries used to define the alias are distinct === That is, the databases are defined by {{{ DATABASES = { 'default' : db_params, 'other' : db_params.copy() } }}} or some equivalent === Test name is explicitly specified === That is, `db_params` looks like: {{{ db_params = dict ( NAME = 'main', TEST_NAME = 'test_main', ... # same as above ) }}} The databases may then be specified by the more natural {{{ DATABASES = { 'default' : db_params, 'other' : db_params } }}} == The more dangerous case == In this case, the testing framework creates spurious databases and finalizes be destroying the main, non-test database. This happens when none of the above applies -- that is, `db_params` does not include the `TEST_NAME` entry, relying on the default `test_` prefix addition, and databases are specified by two references to the same dictionary (as in the last definition above). Regretfully, one may expect th… | boaz85 | shai | multidb, multiple databases, multiple aliases | 1 | 1 | 0 | 0 | 0 | 0 |
| 14757 | 2010-11-22 22:26:33 | 2012-09-01 00:41:25 | 2022-03-06 03:58:42.262676 | Accepted | closed | Documentation | Bug | Normal | 1.2 | wontfix | Add An Example For .extra(tables=[]) | When fiddling around trying to find a solution to one of my problems, it seems to be that .extra(tables=[]) was what I needed. I took a trip through the django documentation just to find that there were no examples, or even a description into what kind of 'string' it takes. Is it JOIN statements? Just a name of a table and/or matching columns? Please add an example to the documentation and/or a better explanation of the string it accepts. Reference: http://docs.djangoproject.com/en/dev/ref/models/querysets/#extra-select-none-where-none-params-none-tables-none-order-by-none-select-params-none | nobody | mikeshultz | documentation extra tables | 1 | 1 | 1 | 0 | 0 | 0 |
| 14885 | 2010-12-10 21:06:04 | 2012-08-21 21:37:53 | 2022-03-06 03:59:03.071764 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.2 | fixed | is_valid for ModelForm changes instance if instance is provided | See this example: {{{ def val_check(value): from django.core.exceptions import ValidationError raise ValidationError('Some reason') class Model(models.Model): image = models.ImageField(upload_to='some/place', validators=[val_check(]) class ModelForm(forms.ModelForm): pass def view(request, model_id): instance = Model.objects.get(pk=model_id) if request.method=='POST': form = ModelForm(request.POST, instance=instance) else: form = ModelForm(instance=instance) if form.is_bound and form.is_valid(): form.save() # do something else return simple.direct_to_template(request, {'template':'some.html', 'extra_context':{'model':instance}}) }}} In the example above, if i send a post request with some data for the field image, instance will be modified. If i use the value of instance in my 'some.html' i'll get invalid data in my template. This seems wrong. | stumbles | italomaia | forms, is_valid, bad data | 1 | 1 | 0 | 0 | 0 | 0 |
| 14930 | 2010-12-21 11:48:47 | 2014-08-06 21:24:11 | 2022-03-06 03:59:09.908979 | Ready for checkin | closed | Database layer (models, ORM) | Bug | Normal | dev | fixed | `values_list()` fails on queryset ordered by extra column | `values_list()` returns an uncomplete QuerySet when called on a QuerySet that is ordered by a column defined using `QuerySet.extra()`. For example, the following QuerySet works as expected:: {{{ qs = Article.objects.extra(select={'id_plus_one': 'id+1'},order_by=['id_plus_one']) }}} but when I execute a `values_list('id')` on this, I'll get a `FieldError: Cannot resolve keyword 'id_plus_one' into field`. To show this problem, I added a test case to `django/tests/modeltests/lookup/tests.py`: {{{ # See http://lino.saffre-rumma.net/tickets/19.html qs = Article.objects.extra(select={'id_plus_one': 'id+1'}).order_by('id_plus_one') print qs.query.extra_select # output: {'id_plus_one': (u'id+1', [])} self.assertQuerysetEqual(qs, [ self.a1, self.a2, self.a3, self.a4, self.a5, self.a6, self.a7 ], transform=identity) qs = qs.values_list('id') print qs.query.extra_select # output: {} self.assertQuerysetEqual( qs, [ [self.a1.id], [self.a2.id], [self.a3.id], [self.a4.id], [self.a5.id], [self.a6.id], [self.a7.id] ], transform=identity) }}} [http://code.google.com/p/lino/source/browse/patches/20101221.diff Here] is a diff file for this code against Django 14995. Running the lookup tests with this patch will say:: {{{ ERROR: test_values_list (modeltests.lookup.tests.LookupTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "L:\snapshots\django\tests\modeltests\lookup\tests.py", line 347, in test_values_list transform=identity) File "l:\snapshots\django\django\test\testcases.py", line 526, in assertQuerysetEqual return self.assertEqual(map(transform, qs), values) File "l:\snapshots\django\django\db\models\query.py", line 84, in __len__ self._result_cache.extend(list(self._iter)) F… | fhahn | lsaffre | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15064 | 2011-01-12 20:06:34 | 2011-05-31 21:44:36 | 2022-03-06 03:59:32.138834 | Accepted | closed | Core (Management commands) | Bug | Normal | 1.3 | fixed | DJANGO_SETTINGS_MODULE doesn't work with runserver | The help for --settings claims that one can use DJANGO_SETTINGS_MODULE to specify the settings module as an alternative to --settings. This seems to be wrong on two accounts, first it works even without a DJANGO_SETTINGS_MODULE (since it guesses settings.py), second setting DJANGO_SETTINGS_MODULE doesn't seem to have any effect at all with runserver. If I try "DJANGO_SETTINGS_MODULE=alternative_settings python manage.py runserver" with a print in alternative_settings.py, I never get the print. The culprit seems to be setup_environ in django.core.__init__.py: {{{ # Set DJANGO_SETTINGS_MODULE appropriately. if original_settings_path: os.environ['DJANGO_SETTINGS_MODULE'] = original_settings_path else: os.environ['DJANGO_SETTINGS_MODULE'] = '%s.%s' % (project_name, settings_name) }}} This always overwrites the environment variable; if I delete those lines, my alternative_settings.py are imported. I guess the correct fix is checking that DJANGO_SETTINGS_MODULE isn't set before overwriting it. | ShawnMilo | olau | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15070 | 2011-01-13 12:49:35 | 2011-04-28 13:41:28 | 2022-03-06 03:59:32.996185 | Ready for checkin | closed | Template system | Bug | Normal | dev | fixed | url tag does not work within inclusion_tags when current_app is needed | suppose we deployed the same app two times (e.g., django-admin), each include in urls.py has tha namespace and app_name set. now we create a custom tag (with the inclusion_tag function of Library) that renders a specific template which has an url tag trying to resolve an url from the mentioned app. then we create a view which set current_app on the RequestContext object and renders a template with the custom tag; the reverse inside the url_tag at the included template fails to resolve to the right app as if the current_app was not set. | goodtune | raony | easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 15098 | 2011-01-16 10:10:12 | 2012-10-24 21:57:10 | 2022-03-06 03:59:37.076410 | Ready for checkin | closed | contrib.auth | Bug | Normal | dev | wontfix | SiteProfileNotAvailable needs silent_variable_failure=True | This makes sense in the context of #15097. If I understand this correctly, the problem from #15097 should exist in the dev version (because of the behavior detailed in the paragraph directly above [http://docs.djangoproject.com/en/dev/ref/templates/api/#how-invalid-variables-are-handled]). My guess is that this is exactly the type of thing that `silent_variable_failure` is there for, and `SiteProfileNotAvailable` does not have `silent_variable_failure=True` in SVN. I have attached a `models.py` that fixes this. | tkolar | tkolar | SiteProfileNotAvailable silent_variable_failure | 1 | 1 | 0 | 0 | 0 | 0 |
| 15143 | 2011-01-21 19:40:39 | 2016-09-15 00:09:30 | 2022-03-06 03:59:44.055221 | Accepted | closed | Documentation | New feature | Normal | dev | fixed | Document how to set the language for the test client | I suggest to add a note in the documentation about how to set the language for the test client. Without the LocaleMiddleware, it's possible to set it with the activate/deactivate functions from django.utils.translation. When LocaleMiddleware is activated, another method has to be used, otherwise the settings.LANGUAGE_CODE is always used. I've been able to set the language by passing HTTP_ACCEPT_LANGUAGE='de' to the get/post method, or by loading a cookie (client.cookies.load({settings.LANGUAGE_COOKIE_NAME:'de'})). | mscott250 | claudep | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15198 | 2011-01-31 15:16:57 | 2013-02-23 23:34:06 | 2022-03-06 03:59:52.829079 | Ready for checkin | closed | contrib.auth | Cleanup/optimization | Normal | dev | fixed | AuthenticationForm.clean call does not have request set | I'm working on per site login system currently. It is required to get the site of the request in prior to calling ``authenticate()`` so the calls to my auth backend should be either in form of: {{{ authenticate(site_id, username, password) }}} or more general: {{{ authenticate(request, username, password) }}} If I try to create own `django.contrib.auth.forms.AuthenticationForm` e.g. by subclassing, then the login view never sets the `request` attribute of auth form. So currently I have to recreate whole login view and authentication form in order to make per site login. With this simple patch I could just subclass AuthenticationForm and override the `clean()` functions call to authentication. More about my per site endeavours in [http://groups.google.com/group/django-developers/browse_thread/thread/7052c23321079295/fbf16f06fa17988c django-devs thread], and in [http://ciantic.github.com/multisited/README.html my proposal for changes to django]. | nobody | Ciantic | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15237 | 2011-02-07 18:31:59 | 2012-07-09 16:16:54 | 2022-03-06 03:59:58.976874 | Ready for checkin | closed | contrib.syndication | Bug | Normal | 1.3 | fixed | Django generated Atom/RSS feeds don't specify charset=utf8 in their Content-Type | Atom feeds containing UTF8 characters should be served with a Content-Type of "application/atom+xml; charset=utf8". At the moment Django's default behaviour is to serve them without the charset bit, and it's not particularly easy to over-ride this behaviour: http://code.djangoproject.com/browser/django/trunk/django/utils/feedgenerator.py#L290 The workaround I'm using at the moment is to wrap the feed in a view function which over-rides the content-type on the generated response object, but it's a bit of a hack: {{{ def feed(request): response = MyFeed()(request) response['Content-Type'] = 'application/atom+xml; charset=utf-8' return response }}} | jasonkotenko | simon | 1 | 0 | 0 | 0 | 0 | 0 | |
| 15252 | 2011-02-09 17:02:42 | 2011-08-11 14:07:41 | 2022-03-06 04:00:01.741861 | Accepted | closed | contrib.staticfiles | New feature | Normal | dev | fixed | get_static_url in static templatetags | Hello, When using the settings STATICFILES_STORAGE, it's the storage that should return the url. For example, a tag of this type works very well: {{{#!python @register.simple_tag() def get_static_url(filepath): if storage.exists(filepath): return storage.url(filepath) return None }}} and so STATIC_URL is not required anymore | nobody | ohardy | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15273 | 2011-02-11 01:11:28 | 2013-06-14 11:10:52 | 2022-03-06 04:00:06.912946 | Unreviewed | closed | Generic views | New feature | Normal | dev | fixed | Extend RedirectView to allow named-URL reversal? | It would be nice to allow named-URL reversal in the new `RedirectView`. Example workaround: {{{ class NamedRedirectView(RedirectView): url_name = None def get_redirect_url(**kwargs): if self.url_name: return reverse(url_name) return super(NamedRedirectView, self).get_redirect_url(**kwargs) }}} {{{ url(r'^blah/', NamedRedirectView.as_view(url_name='xyz:abc')), }}} I would imagine it is fairly common to want to keep URLconfs DRY, so perhaps this should be built into `RedirectView` as an additional option? Of course reversing with args/kwargs is a different story altogether... | nobody | DrMeers | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15304 | 2011-02-15 06:57:16 | 2011-08-22 07:37:35 | 2022-03-06 04:00:12.051905 | Design decision needed | closed | Database layer (models, ORM) | Bug | Normal | dev | wontfix | `Model.objects.create()` returns `long` instead of `int`. | Some database backends (I've only tested postgresql, sqlite seems OK) seem to return a `long` PK instead of `int` when creating new model objects. When getting an existing model object, `int` is correctly returned. I did find a comment about this in the [http://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-models tutorial], but I don't think this is by design and I think this difference in behaviour between new and existing objects and database backends is buggy and violates the principle of least surprise. It might be a bit of an edge case, but we were stumped for a while trying to figure out why created objects had a PK of a different type to existing objects. We initially noticed the problem because we use a pickle field to store various types of data -- PKs, dates and times, booleans, dicts, etc. -- and when passing in the value of a newly created PK to the pickle field we were then unable to filter on it unless we explicitly searched for `long` values. So to work-around this issue we need to a) know the type of the PK that should be returned for existing objects and coerce it before passing to the pickle field if it does not match. | nobody | mrmachine | int long primary key create get | 1 | 1 | 0 | 0 | 0 | 0 |
| 15379 | 2011-02-22 14:48:57 | 2013-03-29 20:50:54 | 2022-03-06 04:00:26.590625 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.2 | fixed | FAQ should include standard way to cite django | Many open source projects have a standard way to cite their use in publications. R has, for example, the citation command: """ {{{ > citation() }}} To cite R in publications use: R Development Core Team (2010). R: A language and environment for statistical computing. R Foundation for Statistical Computing, Vienna, Austria. ISBN 3-900051-07-0, URL http://www.R-project.org. A BibTeX entry for LaTeX users is {{{ @Manual{, title = {R: A Language and Environment for Statistical Computing}, author = {{R Development Core Team}}, organization = {R Foundation for Statistical Computing}, address = {Vienna, Austria}, year = {2010}, note = {{ISBN} 3-900051-07-0}, url = {http://www.R-project.org}, } }}} We have invested a lot of time and effort in creating R, please cite it when using it for data analysis. See also ‘citation("pkgname")’ for citing R packages. """ It would be nice if Django had a similar command or (and this is the easiest solution) if the FAQ addressed this. This would help academic users of django. | susan | csgreene | 1 | 0 | 0 | 0 | 0 | 0 | |
| 15566 | 2011-03-08 03:00:53 | 2012-09-08 10:58:01 | 2022-03-06 04:00:52.772252 | Accepted | closed | Documentation | Bug | Normal | 1.2 | fixed | .update queries should affect Date*Field's with auto_now | Right now, calling Manager.update will update records without affecting date fields w/ auto_now specified. This is a bug. Perhaps UpdateQuery should generate an update to any fields with auto_now. | agiliq | jdunck | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15590 | 2011-03-10 06:31:12 | 2015-03-30 14:38:51 | 2022-03-06 04:00:56.149140 | Accepted | closed | Documentation | New feature | Normal | dev | fixed | Document how to change the path of a FileField | Currently we can't set filefield/imagefield's underlying filename, without loading the file and feeding it's contents into save(). Obviously this is grossly inefficient. This is a simple patch that allows you to set the path like so -- {{{ instance.myfile.path = 'uploads/new-path.avi' }}} Previously, instance.myfile.path is read only. If you set instance.myfile then instance.myfile.path etc will raise a ValueError, The 'myfile' attribute has no file associated with it. Works with FileField, ImageField, and anything else that uses a File object that is subclassed from FieldFile. Check stackoverflow, google, etc- lots of people banging their heads trying to figure out why they can't simply set the filename. | jorgebg | simon29 | filefield imagefield path filename | 1 | 0 | 0 | 0 | 0 | 0 |
| 15595 | 2011-03-12 07:45:50 | 2011-05-12 12:31:57 | 2022-03-06 04:00:56.920477 | Accepted | closed | Documentation | Bug | Normal | dev | fixed | emphasize the importance of 'from django.test import TestCase' | On reading the dev docs on tests one starts of with importing unittest either directly or from django.utils. The docs should clearly specify at the beginning that the optimal way is to do from django.test import TestCase as this will automatically import unittest2 as well as all the goodies. | ShawnMilo | lawgon | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15646 | 2011-03-19 00:26:34 | 2011-11-19 15:08:07 | 2022-03-06 04:01:03.379636 | Accepted | closed | Documentation | Bug | Normal | 1.2 | fixed | Document that the FileField's path can not be relied on until the model is saved | The FileField's .path attribute misses the path given in 'upload_to'. Example: In settings.py: {{{ MEDIA_ROOT = '/somewhere/' }}} In some model: {{{ data = models.FileField(upload_to='files') }}} In the view that handles the file upload: {{{ print data.path }}} This prints '/somewhere/filename' but if I am correct it shall print '/somewhere/files/filename' Exact Version is 1.2.5(-1) (current version in debian/wheezy) upload_to='files/' does not remedy this issue. I sincerely hope that I am not wasting your time. Thank you. | nobody | anonymous | storage system path upload_to | 1 | 1 | 0 | 0 | 0 | 0 |
| 15661 | 2011-03-22 21:50:02 | 2012-11-17 18:06:51 | 2022-03-06 04:01:05.378359 | Ready for checkin | closed | contrib.admin | New feature | Normal | dev | fixed | LogEntry objects have no unicode method | This only, as far as I can tell, affects the admin view for deleting objects. When get_deleted_objects is called on an object (eg: an auth.models.User instance) it can find the associated log entries, and display them as part of the list of objects to be culled; as it stands at the moment, when the template displays the data, it just says {{{ LogEntry object }}} or some such. I attach a simple patch that attempts to resolve that by providing a unicode representation of the logentry type, based on whether its an addition, change or deletion. The wording and string formatting takes its cues from the construct_change_message method on ModelAdmin. As far as I can foresee, having a default representation of some sort would not provide any obstacles, as any usage of log entries currently in use will either be assembling the data itself (as the {{{ get_admin_log }}} templatetag does), or using a proxy object to do it, which would have to provide its own unicode (which would take precedence). I'm not sure there's a legitimate case for a LogEntry ''not'' having an object_repr or change_message (both of which are utilised in the patch), but if there is, I've not handled it at current. | ShawnMilo | Keryn Knight <keryn@kerynknight.com> | logentry unicode | 1 | 1 | 1 | 1 | 0 | 0 |
| 15697 | 2011-03-26 15:43:08 | 2013-05-29 13:51:38 | 2022-03-06 04:01:10.916352 | Accepted | closed | Core (Management commands) | Bug | Normal | dev | fixed | sqlindexes doesn't output index on manytomany tables although syncdb creates it | Django 1.2.5, Ubuntu 10.10. With these simple models: {{{ class A(models.Model): pass class B(models.Model): a = models.ManyToManyField(A) }}} `./manage.py sqlindexes myapp` doesn't output the following `CREATE INDEX` statement, but `./manage.py syncdb` does create them: {{{ CREATE INDEX `myapp_b_a_3797486b` ON `myapp_b_a` (`b_id`); CREATE INDEX `myapp_b_a_776cf5a8` ON `myapp_b_a` (`a_id`); }}} Shouldn’t the output of `./manage.py sqlindexes` correspond to what `./manage.py syncdb` does? | claudep | mbertheau | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15732 | 2011-04-01 07:52:15 | 2011-05-20 02:43:17 | 2022-03-06 04:01:17.422797 | Accepted | closed | Documentation | Cleanup/optimization | Normal | dev | fixed | stringfilter documentation example does not work | In [http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#template-filters-that-expect-strings stringfilter decorator documentation], the first code example given does not work because `@register.filter` is missing. | nobody | akaihola | easy-pickings | 1 | 1 | 0 | 0 | 0 | 0 |
| 15744 | 2011-04-03 03:42:06 | 2012-08-16 22:13:55 | 2022-03-06 04:01:19.548998 | Accepted | closed | Documentation | Cleanup/optimization | Normal | 1.3 | invalid | serialization docs improvement | In [http://docs.djangoproject.com/en/1.3/topics/serialization/], the code fragment {{{ return (self.first_name, self.last_name) }}} could be improved as a dict {{{ return {'first name':self.first_name, 'last name':self.last_name} }}} to show how to enable fieldnames in the JSON output, rather than the default "naturalkey". | gumuz | choj | docs serialization | 1 | 1 | 0 | 0 | 0 | 0 |
| 15750 | 2011-04-04 13:08:40 | 2011-09-28 16:12:30 | 2022-03-06 04:01:20.623446 | Ready for checkin | closed | Core (Mail) | Bug | Normal | 1.3-beta | fixed | smtp.EmailBackend won't use empty username/password | Assuming settings.EMAIL_HOST_USER and/or settings.EMAIL_HOST_PASSWORD is non-empty, then something like this won't work: {{{ connection = get_connection(host='mail.host.com', port=1234, username='', password='') send_mail(..., connection=connection) }}} Because !EmailBackend.!__init!__ does this: {{{ self.username = username or settings.EMAIL_HOST_USER self.password = password or settings.EMAIL_HOST_PASSWORD }}} and therefore will default to settings.EMAIL_HOST_USER and settings.EMAIL_HOST_PASSWORD. And then !EmailBackend.open() will attempt SMTP authentication: {{{ if self.username and self.password: self.connection.login(self.username, self.password) }}} A workaround to prevent the login then would be: {{{ connection = get_connection(host='mail.host.com', port=1234) connection.username = '' # or None connection.password = '' # or None send_mail(..., connection=connection) }}} A possible fix might be in !EmailBackend.!__init!__: {{{ if username is None: self.username = settings.EMAIL_HOST_USER else: self.username = username if password is None: self.password = settings.EMAIL_HOST_PASSWORD else: self.password = password }}} I'm not sure whether an empty string as username and password in order to prevent SMTP authentication is frowned upon and only None should be used. If that's the case, then perhaps !EmailBackend shouldn't use '''any''' defaults if, for instance, a different host is passed. | bedmondmark | thialfihar | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15764 | 2011-04-05 11:19:52 | 2011-06-12 00:28:12 | 2022-03-06 04:01:22.886839 | Ready for checkin | closed | Documentation | Bug | Normal | 1.3 | fixed | DeleteView does not have ModelFormMixin in its mixins | Documentation for DeleteView mentions that it inherits from ModelFormMixin However, reading the code, we have: * DeleteView * SingleObjectTemplateResponseMixin * TemplateResponseMixin * BaseDeleteView * DeletionMixin * BaseDetailView * SingleObjectMixin * View The point being that DeleteView doesn't pass any form as the documentation mentions. http://docs.djangoproject.com/en/1.3/ref/class-based-views/#deleteview | nobody | linovia | 1 | 1 | 0 | 1 | 0 | 0 | |
| 15789 | 2011-04-08 13:06:14 | 2012-05-29 21:35:05 | 2022-03-06 04:01:27.218496 | Ready for checkin | closed | Template system | Bug | Normal | 1.3 | fixed | floatformat filter works incorrectly when decimal precision is set low | When `floatformat` receives a decimal places argument which is equal or larger than the current decimal precision, the decimal part isn't truncated. An example: {{{ >>> from django.template.defaultfilters import floatformat >>> import decimal >>> decimal.getcontext().prec = 2 >>> floatformat(1.23456789123, 1) u'1.2' >>> floatformat(1.23456789123, 2) u'1.23456789123' >>> floatformat(1.23456789123, 3) u'1.23456789123' }}} | igalarzab | akaihola | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15793 | 2011-04-08 20:08:09 | 2012-02-29 14:18:52 | 2022-03-06 04:01:27.895660 | Accepted | closed | Core (Mail) | Cleanup/optimization | Normal | wontfix | Filebased email backend should save emails using the ".eml" standard extension | Emails saved by the filebased backend should be saved using .eml or .email extensions, this is the de facto standard extension for email files, using .email or .eml instead of .log has some other advantages as well. One of them is the possibility of opening emails directly in MS Outlook or preview them in OS X Finder by simply pressing space over the file. | nobody | Kronuz | 1 | 1 | 1 | 0 | 1 | 0 | ||
| 15795 | 2011-04-09 11:52:07 | 2011-05-05 00:29:17 | 2022-03-06 04:01:28.238359 | Ready for checkin | closed | Core (Other) | Bug | Normal | 1.3 | fixed | [patch] __repr__ for RegexURLPattern not unicode safe | An instance of {{{RegexURLPattern}}} is returned by the {{{url()}}} function, which can be used as an argument to {{{patterns()}}} for the URLConf. The url arguments for regex and name could contain unicode. However, the {{{__repr__}}} function handle this data as bytestring and could raise a {{{UnicodeDecodeError}}}: 'ascii' codec can't decode byte. {{{RegexURLResolver}}} should be affected too. | nobody | Mark Raddatz <mraddatz@gmail.com> | debug unicode | 1 | 1 | 0 | 1 | 0 | 0 |
| 15837 | 2011-04-16 00:50:12 | 2011-08-24 12:31:00 | 2022-03-06 04:01:35.324017 | Accepted | closed | contrib.localflavor | Cleanup/optimization | Normal | 1.3 | fixed | Consolidate localflavor tests | Localflavor tests are spread out between two locations: source:django/trunk/tests/regressiontests/forms/localflavor and source:django/trunk/tests/regressiontests/localflavor For clarity's sake, the tests in the former location should be moved to the latter one. | julien | julien | 1 | 0 | 0 | 0 | 0 | 0 | |
| 15840 | 2011-04-16 20:05:50 | 2012-02-09 18:57:06 | 2022-03-06 04:01:35.838951 | Ready for checkin | closed | Core (Other) | Cleanup/optimization | Normal | fixed | [patch] wrap the inner function of the condition decorator | Like all the other `inner` functions in the [http://code.djangoproject.com/browser/django/trunk/django/views/decorators/http.py?rev=16028 django/views/decorators/http.py] module, wrap the `inner` function so that it exposes it's wrapped function's attributes. Ran the unit tests successfully on my Mac Book Pro (10.6.7, 2 cores, 4 GB), see attached unit test run output. | zsiciarz | portante | 1 | 1 | 1 | 0 | 0 | 0 | ||
| 15862 | 2011-04-20 12:24:30 | 2011-04-22 21:25:17 | 2022-03-06 04:01:39.467099 | Ready for checkin | closed | Documentation | Bug | Normal | 1.2 | fixed | Error in post_syncdb example | The example given in the post_syncdb documentation seems to be wrong. In r15104 an example mentioning "yourapp/signals/__init__.py" was added, but the first paragraph of the post_syncdb documentation clearly states that the signal handlers must live in the management module. The simple patch attached replaces "yourapp/signals/__init__.py" with "yourapp/management/__init__.py". | nobody | andialbrecht | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15875 | 2011-04-21 00:10:29 | 2011-04-23 21:49:23 | 2022-03-06 04:01:41.739026 | Ready for checkin | closed | Documentation | Bug | Normal | 1.3 | fixed | F() example in db queries topic guide has an error | http://docs.djangoproject.com/en/1.3/topics/db/queries/#filters-can-reference-fields-on-the-model I'm thinking this is incorrect. The F() object references the pingback count, no? {{{ For example, to find a list of all blog entries that have had more comments than pingbacks, we construct an F() object to reference the comment count, and use that F() object in the query: >>> from django.db.models import F >>> Entry.objects.filter(n_comments__gt=F('n_pingbacks')) }}} | nobody | jblaine | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15878 | 2011-04-21 09:42:00 | 2011-05-31 22:21:21 | 2022-03-06 04:01:42.213560 | Accepted | closed | Documentation | Bug | Normal | 1.3 | duplicate | Bad Link In Module Index | Hello, In the [http://docs.djangoproject.com/en/1.3/py-modindex/ Module Index] there is a link called django.contrib.admin which goes to http://docs.djangoproject.com/en/1.3/ref/contrib/adm/ rather than http://docs.djangoproject.com/en/1.3/ref/contrib/admin/ Hope that helps, Shane Hudson | nobody | Shane@ShaneHudson.net | 1 | 0 | 0 | 0 | 0 | 0 | |
| 15885 | 2011-04-22 19:28:51 | 2011-04-28 00:26:32 | 2022-03-06 04:01:43.329480 | Ready for checkin | closed | Documentation | New feature | Normal | 1.3 | fixed | Update the docs to explain that auth views now return TemplateResponse | Changeset r16087 modified the auth views to return a TemplateResponse rather than an HttpResponse. Document the change in the Authentication topic page. | nobody | prestontimmons | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15886 | 2011-04-22 20:53:31 | 2011-04-24 21:57:16 | 2022-03-06 04:01:43.482366 | Accepted | closed | Documentation | New feature | Normal | 1.3 | duplicate | Improve django.core.serializers.get_serializer() docs | By experimentation, it appears that calling get_serializer() with an unknown format raises KeyError, but this is not documented. It should be documented what the behavior is. Even better (maybe this should be a separate issue), it should raise some more specific exception, which would make it easier to handle at a higher level (such as middleware). | nobody | RoySmith | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15887 | 2011-04-22 21:19:13 | 2011-05-01 20:11:04 | 2022-03-06 04:01:43.635540 | Ready for checkin | closed | Documentation | Cleanup/optimization | Normal | 1.3 | fixed | Improve django.views.decorators.http docs | {{{ require_http_methods() require_GET() require_POST() }}} None of these describe what happens if you try to access the view with the wrong method. Throw some exception? Return a 404? Cause daemons to fly out of your nose? Some additional clarity here would be useful. | nobody | RoySmith | 1 | 1 | 1 | 0 | 0 | 0 | |
| 15889 | 2011-04-23 23:24:51 | 2011-04-26 16:49:33 | 2022-03-06 04:01:43.938944 | Ready for checkin | closed | Core (Serialization) | New feature | Normal | 1.3 | fixed | django.core.serializers.get_serializer() should raise a more specific exception on invalid argument | If you call get_serializer("foo"), where "foo" is not a valid serializer type, it raises KeyError (see Ticket #15886). It should raise something more specific, such as UnknownSerializerFormat. We're trying to build a route structure something like: url(r'/foo/object\.(?P<format>\w+)', api.get_object) with a view that looks like: def get_object(request, format): serializer = django.core.serializers.get_serializer(format) [...] Then you can GET /foo/object.xml, /foo/object/json, etc and it all just works. The problem is, if you GET /foo/object.xyz, the get_serializer call will throw the generic KeyError, which means you need to deal with it right there (and the exception catching logic would have to be replicated in every view that used this) If it threw a more specific UnknownSerializerFormat, that could be caught in a middleware process_exception() handler, which could return HttpResponseNotFound or HttpResponseBadRequest or something like that (with an appropriate explanatory message in the body). You don't want to catch KeyError in middleware; that's much too generic and could mask all sorts of coding errors. Even if you wanted to keep it generic, ValueError seems more appropriate than KeyError. And it should be documented :-) | nobody | RoySmith | 1 | 1 | 0 | 0 | 0 | 0 | |
| 15892 | 2011-04-24 19:58:44 | 2011-04-25 05:59:10 | 2022-03-06 04:01:44.384355 | Ready for checkin | closed | Testing framework | Cleanup/optimization | Normal | 1.3 | fixed | Duplicate 'settings' import in settings_tests/tests.py | 'settings' is imported from django.conf twice. | ShawnMilo | ShawnMilo | 1 | 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
);