tickets_full

29,846 rows sorted by status

View and edit SQL

Suggested facets: stage, status, type, severity, resolution, easy, has_patch, needs_better_patch, needs_tests, ui_ux

These facets timed out: needs_docs

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
56 2005-07-18 08:23:54 2019-06-04 13:23:29 2019-06-24 00:15:52.490950 Accepted assigned Database layer (models, ORM) New feature Normal master   Primary key columns should be UNSIGNED This gets you twice the integer space, and seems to me to be a nice sanity check. Don't know if the same would go for Postgres. Not enough into the code right know to produce a patch myself. caioariede Manuzhai <mail@manuzhai.nl> mysql 0 1 1 0 0 0
1891 2006-05-16 10:41:36 2019-04-05 00:13:25 2019-06-24 00:35:22.325209 Accepted assigned Database layer (models, ORM) Bug Normal     ForeignKey with m2m filter can duplicate foreign model entries in ModelForm/ModelChoiceField My app has the following models similar to: {{{ #!python PROXY_GROUPS = ('Terminal Server', 'Socks Proxy', 'Web Proxy') class Group(models.Model): name = models.CharField(maxlength=32) class Asset(models.Model): name = models.CharField(maxlength=32) groups = models.ManyToManyField(Group) class Proxy(models.Model): asset = models.ForeignKey(Asset, limit_choices_to={'groups__name__in': PROXY_GROUPS, 'distinct':True}) port = models.PositiveIntegerField() }}} Which spews an error when I try to add a Proxy object in the admin. The error is something to do with 'distinct' not being a valid field (Sorry i can post the exact error later). How can I achieve the equivalent to this in the current post-mr trunk? From #django earlier today: {{{ malcolmt mattimustang_: I think you've found a bug. You're right, distinct has become a method on QuerySets, not a filter parameter now. So you may be temporarily stuck. Can you file a ticket so we don't forget to fix this somehow, please? }}} gcc mattimustang@gmail.com   0 1 1 0 0 0
2259 2006-06-28 19:20:45 2018-01-15 20:31:52 2019-06-24 00:39:16.716037 Accepted assigned contrib.admin Bug Normal master   Primary keys should be readonly by default in admin When creating a simple model with a non-integer primary key, the Admin interface shows the field as editable, but when making a change, it seems to execute an incorrect query. For example: {{{ class Group(models.Model): name = models.CharField(maxlength=32, primary_key=True) def __str__(self): return self.name class Admin: list_display = ('name',) search_fields = ('name',) }}} When changing the primary key field (e.g. from 'Test' to 'TestX') when editing a record, a ProgrammingError exception is raised. The SQL that is generated is: {{{ UPDATE "config_group" SET WHERE "name"='Test' }}} This is missing the primary key field to be changed after SET. This is with the latest SVN code. It seems to be an issue around line 179 of db/models/base.py where it only adds the non-pk columns after SET. Pathangi-Jatinshravan ed@edplese.com   0 0 0 0 0 0
2361 2006-07-16 18:42:51 2018-05-15 19:37:49 2019-06-24 00:40:21.530387 Accepted assigned Database layer (models, ORM) Bug normal master   QuerySet.filter(m2mfield__isnull=False) may return duplicates My Django installation is SVN Revision: 3238 Filtering models by a ManyToMany field does not appear to work. See Google groups thread http://groups.google.com/group/django-users/browse_thread/thread/d0d799a45cb92d35 I have two classes -- Blog and Submission: {{{ class Blog( models.Model ): entries = models.ManyToManyField( Submission ) class Submission( models.Model ): [... whatever ] }}} I want to fetch a list of all Blog instances which have at least one Submission , i.e. entries.count() > 0. The suggested {{{ Blog.objects.filter(entries__isnull = False) }}} (suggested by Malcolm Tredinnick) returns: {{{ psycopg.ProgrammingError: FEHLER: Spalte m2m_models_blog__entries.entries existiert nicht SELECT "models_blog"."id","models_blog"."title","models_blog"."description","models_blog"."region_id","models_blog"."regionname","models_blog"."date_submitted","models_blog"."author_id","models_blog"."visible" FROM "models_blog" LEFT OUTER JOIN "models_blog_entries" AS "m2m_models_blog__entries" ON "models_blog"."id" = "m2m_models_blog__entries"."blog_id" WHERE ("m2m_models_blog__entries"."entries" IS NOT NULL) }}} m2m_models_blog__entries is an alias for models_blog_entries -- I *have* this table, but it has no column "entries". This is what it looks like: {{{ # \d models_blog_entries Tabelle »public.models_blog_entries« Spalte | Typ | Attribute ---------------+---------+--------------------------------------------------------------------- id | integer | not null default nextval('public.models_blog_entries_id_seq'::text) blog_id | integer | not null submission_id | integer | not null Indexe: »models_blog_entries_pkey« PRIMARY KEY, btree (id) »models_blog_entries_blog_id_key« UNIQUE, btree (blog_id, submission_id) Fremdschlüssel-Constraints: »models_blog_entries_blog_id_fkey« FOREIGN KEY (blog_id) REFERENCES models_blog(id) »models_blog_entries_submission_id_fk… cgdeboer daniel.tietze@gmail.com   0 0 0 0 0 0
3461 2007-02-08 20:38:52 2018-02-08 10:46:21 2019-06-24 00:52:06.069655 Accepted assigned Database layer (models, ORM) Bug Normal master   DatabaseWrapper should pass through args and kwargs to underlying database adapter Currently the DatabaseWrapper (at least for the postgresql) does not pass args and kwargs for cursor() calls to the underlying database adapter. This makes it impossible to use the adapter fully at the low level. For example, to use dict cursors in psycopg2 you have to pass a different cursor factory via the cursor_factory keyword argument to cursor(). The attached patch passes through args and kwargs for cursor() calls. auvipy Jack Moffitt <metajack@gmail.com>   0 1 0 0 1 0
4282 2007-05-12 12:39:41 2014-06-14 15:43:22 2019-06-24 01:00:42.923389 Accepted assigned Core (Management commands) New feature Normal master   startproject should honor umask Ticket #1651 fixed the problem of manage.py not being made executable by copying *all* the permission bits (not just the executable flags). This means that the user's umask doesn't work, e.g.: {{{ $ umask 077 $ touch foo $ ls -l foo -rw------- 1 talex talex 0 2007-05-12 13:27 foo $ PYTHONPATH=trunk ./trunk/django/bin/django-admin.py startproject mysite $ ls -l mysite/settings.py -rw-r--r-- 1 talex talex 2804 2007-05-12 13:28 mysite/settings.py }}} I discovered this whilst trying to make a Zero Install package for Django. Everything in the Zero Install cache is read-only, so startproject fails with: {{{ File "/var/cache/0install.net/implementations/sha1new=262c95b5a7cc34f525408b675106e4e4ae3494cc/django/core/management.py", line 799, in startproject fp = open(main_settings_file, 'w') IOError: [Errno 13] Permission denied: '.../site/settings.py' }}} Thanks, merb talex5+django@gmail.com   0 1 1 0 0 0
5711 2007-10-09 04:08:46 2016-09-10 14:45:42 2019-06-24 01:16:21.930563 Accepted assigned Core (Serialization) Bug Normal master   Allow non-field attributes to be serialized It seems if I create a request set with extra(), the fields are not in the output generated by serialize(). senko valankar@gmail.com   0 1 1 0 0 0
5899 2007-11-08 14:08:08 2016-06-28 19:33:51 2019-06-24 01:18:23.518917 Accepted assigned contrib.admin New feature Normal newforms-admin   Allow admin fieldsets to be collapsible but not initially collapsed I want to use the collapse feature of the admin, but not have the field initially collapsed, so I made this little patch. It adds a "collapsible" class that does just that. It also patches the documentation. dArignac Ionut Ciocirlan <ionut.ciocirlan@gmail.com> admin fieldset collapsed collapsible nfa-someday 0 1 0 1 0 1
6363 2008-01-11 19:15:42 2016-10-14 15:10:31 2019-06-24 01:23:23.311796 Accepted assigned contrib.admin Bug Normal master   Login page is redisplayed without any message if AdminSite.has_permission() returns False I found a bug when using the has_permission method of the AdminSite class to filter which users can access the admin page: {{{ class SuperuserAdminSite(admin.AdminSite): def has_permission(self, request): return super(SuperuserAdminSite, self).has_permission(request) and request.user.is_superuser admin_site = SuperuserAdminSite() }}} When I try to log on a user that is not a superuser, it already get the login but stay on the login page (with the header but no application loaded), I think this is a bug :) The user should get a error message as if it passed a wrong password or such, isn´t it? yakky michelts   0 1 0 1 0 0
6376 2008-01-14 13:59:11 2019-05-20 15:26:27 2019-06-24 01:23:31.878221 Accepted assigned Internationalization New feature Normal master   Allow using custom gettext domains I'm using django as a library in my non-web-based application. As such I prefer not to use the 'django' gettext domain but my own. I currently work around it with some symlinking trickery since being compatible with upstream django is more important than not having workarounds, but it would be great if django supported this. To illustrate what I mean, I've attached a simple and untested patch against current svn (rev 7020). R4G3-BABY dennis@kaarsemaker.net gettext 0 1 0 0 0 0
6517 2008-01-31 08:42:34 2017-05-12 12:43:31 2019-06-24 01:25:04.136309 Accepted assigned Database layer (models, ORM) Bug Normal master   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. Biswajit-iiit tvrg   0 1 0 1 0 0
6989 2008-04-09 01:42:11 2019-04-04 09:08:50 2019-06-24 01:30:13.586209 Accepted assigned Core (Mail) Bug Normal master   Inability to define DNS_NAME in django.core.mail results in e-mail messages being rejected or marked as spam '''Summary'''[[BR]] Being the case that the application server's hostname may not necessarily be a valid fully qualified domain name (FQDN) the use of socket.getfqdn() in defining DNS_NAME may yield a number of e-mail messages either rejected or marked as spam. Rejection issues arise if settings.EMAIL_USE_TLS is True - meaning smtplib.ehlo() will be called - and if a mail server is particularly strict (or misconfigured) and rejects any ehlo command followed by an invalid FQDN. Spam issues arise with DNS_NAME being used as the local_hostname argument to smtplib.SMTP() within the SMTPConnection.open() method, meaning the initial "Received:" e-mail header may be from an invalid FQDN. Further increasing the chance of being marked as spam is DNS_NAME being used by the make_msgid() method, leaving the "Message-ID:" e-mail header ending in an invalid FQDN. '''Real World Scenario'''[[BR]] A shared server has a hostname, which you may not and can not change, of "star-wars-reference". The socket.getfqdn() method fails to find info on its IP address and by default simply returns said hostname. E-mail is then sent by Django with a Message-ID of "200804....@star-wars-reference" from a server claiming to be "star-wars-reference ([server's IP address])" and is, of course, marked as spam. '''Solution'''[[BR]] Provide an optional settings variable such as EMAIL_LOCAL_HOSTNAME where Django developers may define a FQDN which maps to their application's server. EMAIL_LOCAL_HOSTNAME will be used by the class defining DNS_NAME in lieu of socket.getfqdn() if EMAIL_LOCAL_HOSTNAME exists in the settings file (this has the added benefit of preventing a call to socket.getfqdn() - further reducing overhead on restarts). heathervm Franklin local_hostname, DNS_NAME, CachedDnsName, smtplib, SMTPConnection 0 1 1 0 1 0
7556 2008-06-27 15:32:35 2011-07-31 22:07:35 2019-06-24 01:36:21.966262 Accepted assigned Core (Management commands) Bug Normal master   inspectdb fails in MySql if a table references a table outside the current schema If a table contains a foreign key that refers to another table that sits outside the schema, that index includes a '.' in the table name. Suppose our current schema is `schema1`: {{{ CREATE TABLE `T1` ( `ACID` int(8) unsigned NOT NULL, `SITE` varchar(8) character set latin1 default NULL, CONSTRAINT `FK_T1_SITE` FOREIGN KEY (`SITE`) REFERENCES `schema2`.`site` (`SITE`) ) }}} For this situation, inspectdb will return something similar to this: {{{ _mysql_exceptions.ProgrammingError: (1146, "Table 'schema1.site' doesn't exist") }}} So it tries to use `schema1.site` as the table to introspect instead of the appropriate `schema2`.`site` Notice it not only needs to use the schema as part of the table name, but also not quote the '.'. Also, introspection.py was not pulling the schema name and just assuming the current schema, which for most cases is right, but in this case causes issues for legacy databases. brockweaver brockweaver mysql foreign key schema inspectdb 0 1 0 1 0 0
8472 2008-08-21 15:58:44 2015-01-26 17:52:14 2019-06-24 01:47:13.253085 Accepted assigned contrib.admin New feature Normal master   Add "Recent Actions" panel to app_index template This was a feature request and relates to the changeset in [http://code.djangoproject.com/ticket/1390 #1390]. The goal is to produce specified results for the Recent Actions panel (sidebar) to only display logged actions for that particular model. For example, at Home > Auth would only display logged actions for the apps pertaining to that model (e.g. User, Groups). burzak juliae   0 1 0 0 1 1
8972 2008-09-08 17:35:43 2011-04-22 06:13:28 2019-06-24 01:52:37.925115 Accepted assigned GIS New feature Normal 1.0   Add ability to delete selected vector features within the Geodjango/OpenLayers Admin map interface This feature has been needed for some time, and was recently requested. See: http://groups.google.com/group/django-users/browse_thread/thread/36242edfd0d0281c?hl=en I've started a basic patch that adds a javascript function to allow multiple features to be selected in the map interface, deleted from view, and removed from the save method. I've tested this so far when editing multipolygon data in the admin. A known issue I'm hoping others may have a solution to: Currently, an OL javascript error occurs on line 948 of OpenLayer.js after successfully deleting a feature. This do not seem to cause any problems in saving the correct geometry or in continuing to use the select control. This is the firebug output: {{{ object is undefined selectFeature()(undefined)OpenLayers.js (line 948) clearSelectedFeatures()()277 (line 327) javascript:geodjango_geometry.clearSelectedFeatures()()()javascri...eatures() (line 1) [Break on this error] this.feature=null;this.dragControl.deact...ply(this.selectControl,[this.feature]);} }}} jbronn springmeyer OpenLayers, admin, vector editing 0 1 0 1 0 0
9061 2008-09-12 18:47:59 2015-09-25 13:48:30 2019-06-24 01:53:34.097469 Accepted assigned Forms New feature Normal master   formsets with can_delete=True shouldn't add delete field to extra forms Current behavior of formsets with can_delete=True is to add a delete field to every form. This behavior differs from that expected, however (why would one want a delete option on an "add" form?), as well as that of the builtin admin. I've included a patch on formsets.py, but haven't bothered with patching tests yet. danielward gsf   0 1 1 0 0 0
9249 2008-09-30 02:55:17 2016-04-04 13:55:29 2019-06-24 01:55:34.936592 Accepted assigned HTTP handling New feature Normal 1.0   Google Analytics' Cookies break CacheMiddleware when SessionMiddleware turns on Vary: Cookie When using Google Analytics on a Django project with CacheMiddleware and SessionMiddleware turned on, the Cookies that Google Analytics apparently change on each reload, invalidating the Vary: Cookie parameter that SessionMiddleware is setting. There should be a way to define cookie prefixes, such as ``'__utm'``, to ignore for cookie variation for caching. ambv pixelcort cache cookies 0 1 1 0 1 0
9373 2008-10-15 20:41:25 2014-12-18 21:39:03 2019-06-24 01:56:54.389043 Accepted assigned contrib.admin Bug Normal 1.7   "This field is required" error even on empty inlines formsets in the admin model page, when hiding a choice field of a custom form. I have a custom Form for one of my models (in the example !SecondModel) that adds one choice field with an initial value. If I use that model/form as an inline formset and I exclude the extra field using the "fields" attribute of the !ModelAdmin, I got "This Field is required" on all the forms of the formset, including those who where left blank. Here a simple example: {{{ #!python # models.py from django.db import models class FirstModel(models.Model): a = models.CharField(max_length=10) b = models.CharField(max_length=10) class SecondModel(models.Model): link = models.ForeignKey(FirstModel) c = models.CharField(max_length=10) # admin.py from django.contrib import admin from bug.bugged import models, forms class SecondAdmin(admin.TabularInline): model = models.SecondModel form = forms.SecondForm fields = ['c'] extra = 3 class FirstAdmin(admin.ModelAdmin): inlines = [SecondAdmin] admin.site.register(models.FirstModel, FirstAdmin) # forms.py from django import forms from bug.bugged import models DUMMY_CHOICES = ( (0, 'a'), (1, 'b'), (2, 'c') ) class SecondForm(forms.ModelForm): d = forms.IntegerField(label='d', initial=0, widget=forms.Select(choices=DUMMY_CHOICES)) class Meta: model = models.SecondModel }}} The problem is {{{fields = ['c']}}}, commenting out that line I get no errors. I guess, this is beacuse of the {{{has_changed}}} check, called by the {{{full_clean}}} method of {{{forms.Form}}}. It happens that {{{changed_data}}} compares the initial "d" value that had been set to 0 with the result of "field.widget.value_from_datadict(self.data,..." that is None because we have not a key for "d" in self.data. So changed_data will contain "d" even if the form has not been changed. From django/forms/forms.py {{{ #!python prefixed_name = self.add_prefix(name) data_value = field.widget.value_from_datadict(self.data, self.files, prefixed_name) … schacki tyrion.mx@gmail.com admin, inlines 0 0 0 0 0 0
9388 2008-10-17 11:03:58 2014-05-16 12:42:29 2019-06-24 01:57:04.052904 Accepted assigned contrib.admin New feature Normal master   Year navigation in admin's date widgets' calendar My colleague Javier de la Rosa has enhanced the calendar shown in admin's date fields to allow navigation through years, and not only through months. This requires changing calendar.js and DateTimeShortcuts.js. We have chosen not to maintain backwards compatibility because this should be a feature in Django 1.1, but it's easy to do if required. Javier de la Rosa will attach his patch later. versae framos admin calendar year previous next widget ui 0 1 1 0 0 1
9602 2008-11-14 19:23:15 2015-02-04 13:03:59 2019-06-24 01:59:23.518021 Accepted assigned contrib.admin New feature Normal master   Add admin.site._registry manipulation methods This is a feature request... Currently, one can unregister a model from the admin and register it again with a new ModelAdmin. The problem I'm anticipating is when 2 or more apps want to add ModelAdmin options to a Model and the last one wins. Not to point out a specific 3rd party app, but this is an easily contrived example... If I have my own apps and one of them unregisters the User model's ModelAdmin and registers its own that, say, adds the `is_superuser` to the list_display. Then if I add the django-openid app that (currently) also unregisters the User model's ModelAdmin and registers its own that adds an inline to a ManyToManyField for the OpenID associations tied to that user. If django-openid is after my app in the INSTALLED_APPS list, I lose my list_display override. And if my app is after the django-openid app, I lose the OpenID associations inlines. (See: http://code.google.com/p/django-openid/source/browse/trunk/django_openid/admin.py) It's possible currently to write the unregistration/registration such that this doesn't happen, but it relies on pulling the ModelAdmin out of the "private" _registry dictionary in the admin.site class. For example: {{{ useradmin = admin.site._registry.get(User, None) if useradmin: useradmin.list_display = useradmin.list_display + ('is_superuser',) else: class MyUserAdmin(AuthUserAdmin): list_display = ('username', 'email', 'first_name', 'last_name', 'is_staff', 'is_superuser') admin.site.register(User, MyUserAdmin) }}} I can think of a few ways of fixing this, from least involved to more involved: 1. At the very least I think it would be nice if the internal `_registry` dictionary didn't have the prepended underscore to signify that it is a private variable not to be touched, so one doesn't feel dirty doing something like this. 2. I think it would be a bit cleaner if there were methods to lookup, get, and update this dict and keep it as a private dict. For example, something like `admin.site.get_model_admin(User)… anonymous robhudson register modeladmin 0 0 0 0 0 0
9739 2008-12-02 16:13:38 2017-01-03 09:14:09 2019-06-24 02:00:52.360345 Accepted assigned contrib.admin Bug Normal 1.0   Admin does not correctly prefill DataTimeField from URL I was not able to format URL for Admin interface to prefill DateTimeField with given value. It worked in 0.96, but does not work in 1.0 ( I used ../admin/MyApp/MyTable/add/?box=359&datum_date=2008-12-01&datum_time=17:30:27) After some looking on source code and testing i find a solution: - in /django/contrib/admin/options.py before line 520 add {{{ if isinstance(f, models.DateTimeField): initial[k] = initial[k].split(",") }}} - use this format: https://../admin/MyApp/MyTable/add/?box=359&datum=2008-12-01,17:30:27 For reference - the model of MyTable is such : {{{ class MyTable(models.Model): box = models.ForeignKey(Boxes) datum = models.DateTimeField(null=True, blank=True) }}} (plus some other insignificant fields. The "datum" field should be prefilled with some date, which is computed by long way (not simple now()) and the use must be able to edit it BEFORE saving it) ---- The problem arises from DateTimeField be treated by MultiWidget, but not properly broken when got by URL (GET) ----- Patch: {{{ --- options.py.old 2008-12-01 19:56:34.000000000 +0100 +++ options.py 2008-12-01 19:40:34.000000000 +0100 @@ -517,6 +517,8 @@ continue if isinstance(f, models.ManyToManyField): initial[k] = initial[k].split(",") + if isinstance(f, models.DateTimeField): + initial[k] = initial[k].split(",") form = ModelForm(initial=initial) for FormSet in self.get_formsets(request): formset = FormSet(instance=self.model()) }}} RidleyLarsen gilhad   0 1 1 0 0 0
10403 2009-03-03 18:21:58 2019-06-17 14:47:53 2019-06-24 02:08:04.208581 Accepted assigned Forms New feature Normal master   provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet Provide a declarative mechanism to define modelformsets or inlineformsets. The attached patch allows definitions like this: {{{ class AuthorForm(forms.ModelForm): class Meta: model = Author class DeclarativeAuthorFormSet(forms.models.ModelFormSet): form = AuthorForm model = Author extra = 3 }}} and {{{ class BookForm(forms.ModelForm): class Meta: model = Book class DeclarativeAuthorBooksFormSet(forms.models.InlineFormSet): model = Book form = BookForm parent = 'author' }}} An advantage is that the defined form is directly used as the form class in the formset, not as a base class for a new form class (what inlineformset_factory does). This way specific field definitions and other customisations in the form work like they should so you don't need to redefine things in __init__(). Parth1811 Koen Biermans <koen.biermans@werk.belgie.be> formset modelformset inlineformset 0 1 1 1 1 0
10686 2009-04-01 04:03:19 2016-08-17 14:32:05 2019-06-24 02:11:08.552615 Accepted assigned Database layer (models, ORM) New feature Normal master   Add class name interpolation in Meta.permissions codenames I've got a patch for a slight behavior modification that I needed and that might be useful for others, and I wanted to collect some thoughts on it before writing up the regression tests and documentation changes. Twice now, I've come across a situation where the default Django behavior for inheriting permissions is inappropriate for my security model. Here's the situation: I have a permission on an abstract base model class that I want all child classes to inherit, and I want to then append specific permission(s) to one or more of the children. Example: {{{ #!python class MyAppBaseModel(models.Model): class Meta: abstract = True permissions = (("view_%(class)s", "Can view %(class)s"),) class ChildModel(MyAppBaseModel): class Meta: permissions = (("foobar_childmodel", "Can foobar childmodel"),) }}} Two problems arise: 1. Although permissions currently may be inherited, the Options class does not currently implement %(class)s replacement like the RelatedField class does, so my permissions end up actually being stored in the database with %(class)s in the name and codename. 2. The way Meta attributes are currently processed in the ModelBase metaclass causes inherited permissions to be completely replaced if any explicit permissions are defined on the child class. So instead of can_view and can_foobar on ChildModel, I only get can_foobar. This patch changes Django's behavior such that any explicit child class permissions would be appended to the inherited ones, rather than completely replacing them. Also, I've added a backwards-compatible flag to the Meta options, 'inherit_permissions'. This flag would only be required in the case that one wanted Django's current behavior which is to discard base class permissions when explicit permissions are declared on the child class. Example: {{{ #!python class MyAppBaseModel(models.Model): class Meta: abstract = True permissions = (("view_%(class)s", "Can view %(class)s")… sergei-maertens faldridge permissions inheritance 0 1 1 0 0 0
10944 2009-04-28 02:35:03 2018-02-08 12:01:35 2019-06-24 02:14:00.926637 Accepted assigned contrib.sites New feature Normal 1.0   Site app should be able to make absolute URLs. I wish Site instances could make (real) absolute URLs (e.g. http.../path/) based on a given relative path like /path/. And a template tag to make it nicer from templates, too: {% site_url ... %} or similar. Can I have a pony? I'll write the patch if I can have a pony. krzysiumed jdunck   0 1 1 0 0 0
11580 2009-07-28 19:14:20 2014-11-15 19:30:43 2019-06-24 02:20:48.365761 Accepted assigned Database layer (models, ORM) Bug Normal 1.6   Unable to query TextField against oracle nclob 10Gr4 I have tried __icontains and __regex against a TextField on an oracle database and get the following error: DatabaseError: ORA-06502: PL/SQL: numeric or value error: character string buffer too small ORA-06512: at line 1 The code was ported directly over from mysql where the i_contains query worked. The column was created as an NCLOB. I can query against other fields fine. Environment: Request Method: GET Request URL: http://django/eis/banobj/search/?q=class Django Version: 1.1 rc 1 SVN-11348 Python Version: 2.4.3 Installed Applications: ['django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.sites', 'eis.banobj', 'django.contrib.admin', 'django.contrib.admindocs', 'eis.ldapauth', 'eis.emailLogs'] Installed Middleware: ('django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware') Template error: In template /opt/django/eis/templates/banobj/arealist.html, error at line 17 Caught an exception while rendering: ORA-06502: PL/SQL: numeric or value error: character string buffer too small ORA-06512: at line 1 7 : {% block content %} 8 : <h1> {{heading}} </h1> 9 : <table border=1> 10 : <tr> 11 : <th>Banner Object</th> 12 : <th>Ready For Testing</th> 13 : <th>Tested</th> 14 : <th>Primary User</th> 15 : <th>Object Type</th> 16 : </tr> 17 : {% for obj in obj_list %} 18 : <tr bgcolor="{% cycle rowcolors %}"> 19 : <td><a href="/eis/banobj/wiki/{{ obj.id }}/">{{ obj.name|upper }}</a></td> 20 : <td>{% if obj.prod_svn %} 21 : <img src="/media/img/admin/icon-yes.gif"> 22 : {% else %} 23 : <img src="/media/img/admin/icon-no.gif"> 24 : {% endif %}</td> 25 : <td>{% if obj.user_tested %} 26 : <img src="/media/img/admin/ic… shaib nosrednakram oracle TextField 0 0 0 0 0 0
11593 2009-07-29 19:30:41 2019-02-15 11:11:22 2019-06-24 02:20:56.545574 Accepted assigned Testing framework New feature Normal master   Incomplete support for app-level testing Django and its community have a pretty strong focus on the concept of reusable applications: applications as pluggable behavior blocks, independent from one another and from projects. And the test framework documentation and setup emphasize that: the documentation page is called [http://docs.djangoproject.com/en/dev/topics/testing/ Testing Django applications] and the test themselves are saved at the application level not at the project level. Yet Django provides no provision whatsoever for running tests from an application: a project (or at least a settings and a urls file) is required, and barring fairly weird setups (global settings and urls modules) there is no way to create a new app, write a test and run it just like that. Which means applications aren't as self-contained as they could be, and can't easily be tested "in a void" (independently of everything else). RaphaelKimmig masklinn   0 1 1 0 0 0
11927 2009-09-22 13:54:20 2018-08-23 10:32:15 2019-06-24 02:24:37.418884 Accepted assigned Core (Management commands) New feature Normal master   Allow manage.py dumpdata to dump YAML in block style Using {{{ python manage.py dumpdata --format=yaml }}} produces output in [http://pyyaml.org/wiki/PyYAMLDocumentation#Dictionarieswithoutnestedcollectionsarenotdumpedcorrectly flow style]. That's OK for automated processing, but it isn't anything like as human-readable as block style YAML. For people who, like me, need to edit the fixtures manually, it would be very useful to be able to do something like: {{{ python manage.py dumpdata --format=yaml --flowstyle=false }}} matthijskooijman sampablokuper   0 1 1 0 0 0
12075 2009-10-22 16:06:12 2013-04-09 13:52:34 2019-06-24 02:26:12.850678 Accepted assigned HTTP handling New feature Normal master   Add wsgiorg.routing args support The [http://wsgi.readthedocs.org/en/latest/specifications/routing_args.html wsgiorg.routing_args] standard may be really useful if you want to use WSGI middleware or applications inside Django because some of them take advantage of that to do nice/useful things. It's currently not supported in Django - But it will with the attached patch. ''[edit] fixed broken link.'' Gustavo Gustavo WSGI, wsgiorg.routing_args 0 1 0 1 1 0
12090 2009-10-26 16:19:44 2013-10-17 13:18:54 2019-06-24 02:26:22.515997 Accepted assigned contrib.admin New feature Normal master   Show admin actions on the edit pages too Currently the workflow for comment moderation might look like this (without knowing the comment moderation admin actions ;)): * Look at the overview page * If in doubt open the comment in a new page * if it's spam go back to the previous page, select it and execute the admin action We could redisplay the admin actions box in the detail views (where they of course would only effect the current object) to prevent the unneeded roundtrip. jgmize apollo13   0 0 1 0 0 1
12227 2009-11-16 19:40:40 2015-07-31 13:38:44 2019-06-24 02:27:49.858037 Accepted assigned Testing framework Bug Normal 1.1   PREPEND_WWW breaks the test client With PREPEND_WWW set to true the test client will always give a 301 status_code: {{{ >>> from django.test.client import Client >>> c = Client() >>> r = c.get('/admin/', follow=True) >>> r.status_code 301 >>> r.redirect_chain [('http://www.testserver/admin/', 301), ('http://www.testserver/admin/', 301)] }}} Sharpek andybak test client, redirect, prepend_www 0 0 0 0 0 0
12416 2009-12-21 10:37:49 2011-09-28 16:12:30 2019-06-24 02:29:53.182175 Accepted assigned GIS New feature Normal master   Improve KML Serialization Currently, there are several problems with the way KML is generated inside !GeoDjango: 1. Now that 3D is supported, there is no way to specify the following element tags, which are important to displaying them in Google Earth: `<altitudeMode>`, `<extrude>`, and `<tessellate>`. 2. A Z value of 0 needs to be omitted for geometries that are purely 2D (this primarily affects the `GEOSGeometry.kml` property) 3. Allow specification of an `id` for geometries, so that styling rules may be easily applied by the user. 4. For polygons: "the `<coordinates>` for polygons must be specified in counterclockwise order. Polygons follow the "right-hand rule," which states that if you place the fingers of your right hand in the direction in which the coordinates are specified, your thumb points in the general direction of the geometric normal for the polygon." [http://code.google.com/apis/kml/documentation/kmlreference.html#polygon KML Reference]. I'm not sure about implementing this within the 'dumb' `kml` properties of `GEOSGeometry` and `OGRGeometry`, rather `GeoQueryset.kml` should wrap `ST_AsKml` in the necessary routines, e.g., `ST_Reverse(ST_ForceRHR(ST_AsKml(the_geom)))`. Attached is an initial idea for a `write_kml` routine. jbronn jbronn gis kml 3d style rhr 0 0 0 0 0 0
12498 2010-01-04 02:20:04 2013-03-14 22:05:47 2019-06-24 02:30:45.745414 Accepted assigned Forms New feature Normal     Add multi-field validators Multi-field validator functionality was taken out of the model-validation branch in [12078]. Add it back in. See [http://groups.google.com/group/django-developers/browse_thread/thread/d4a4bf8607f4b8a this thread] on django-developers for more details. There's also a more extensive and older [http://groups.google.com/group/django-developers/browse_thread/thread/436307e426844ae0/f2fa0647b97569ad discussion] that I missed. Thank you mrts for pointing it out. jkocherhans jkocherhans   0 1 1 0 0 0
12772 2010-02-04 12:19:03 2014-12-27 01:57:26 2019-06-24 02:33:42.020748 Accepted assigned Template system New feature Normal 1.2-beta   Allow loading template tags by fully qualified python module path Currently templatetags are magically searched for in the list of installed apps. This leads to all kind of problems when debugging code, starting from being forced to use find to locate tag libraries and ending with global namespace collisions. The attached patch adds the possibility to import tags by fully qualified module path by first trying to make an absolute import and only then falling back to searching inside installed apps. This also allows people to import tag libraries that are not parts of any application (so common tags can be kept together without the need of adding a fake app). Also: "Explicit is better than implicit." :) patrys patrys   0 1 1 1 1 0
12990 2010-02-27 21:14:53 2019-06-11 04:42:44 2019-06-24 02:36:09.611435 Accepted assigned Database layer (models, ORM) New feature Normal master   Add JSONField model field I have been using this for over a year now and find it quite useful. I posted it about it the other day (http://paltman.com/2010/feb/25/how-to-store-arbitrary-data-in-a-django-model/) and then thought it might be generally useful as an out of the box field type so I thought I'd submit a patch in case it is deemed "generally useful" enough to be considered for inclusion in django proper. laymonage paltman   0 1 1 0 1 0
13009 2010-03-02 14:56:35 2017-05-03 19:11:43 2019-06-24 02:36:21.803732 Accepted assigned Forms New feature Normal master   provide django.forms field type info for use in templates My use case is that it would be useful to have access to this info from templates when generating forms, eg: {{{ {% for field in form.fields %} {% if field.type == 'checkbox' %} {# render one way... #} {% else %} {# render another way #} {% endif %} {% endfor %} }}} FWIW, django.contrib.admin seems to get around this problem in AdminField by adding an is_checkbox attribute, but it seems to me that the type of field being rendered should be easily available in the template, in other words, IMHO this makes sense as a core feature of django.forms. rameshugar tvon   0 0 0 0 0 0
13559 2010-05-18 12:36:25 2014-06-13 19:37:33 2019-06-24 02:42:23.957413 Accepted assigned contrib.sites New feature Normal master   Need a contextprocessor for current site If you use Sites app you would need to use current site instance in your templates. For that purpose there should be a ContextProcessor in django.contrib.sites application. The code is quite simple, but it makes no sense to create and store it in user's application: {{{ from django.contrib.sites.models import Site def current_site(request): return {'SITE': Site.objects.get_current()} }}} I can provide a patch if needed. chrismedrela tonnzor   0 1 1 0 0 0
13564 2010-05-19 05:01:19 2011-05-15 17:15:44 2019-06-24 02:42:27.130814 Accepted assigned Forms New feature Normal 1.2-beta   Provide class attributes for form fields I work a lot with Django forms and I'm also working on grappelli and I've come to find that there's one thing that is cruelly missing from django's forms.. Meaningful class names on form inputs. As now if I want to change the class name of an input I either have to write the forms explicitly or do something like this for *every* forms: {{{ from django import forms from django.forms import widgets class MyForm(forms.Form): title = forms.CharField(required=True, widget=widgets.TextInput(attrs={ 'class': 'charfield required' })) }}} Whereas it would be easy to simply use the field type's name to generate a meaningful class; {{{ <input type="text" value="" class="django-charfield django-required" /> }}} The "required" is not crucial, but would be really useful for JavaScript enhanced validation. That said, just a class hinting the field type would be a 100% improvement. Finally, it's not just for JavaScript. It would also be useful for CSS styling. For example when I use a PositiveInteger field I never need it to be the same width as a Char field. It would be nice to be able to style them without having to write many lines of Python or HTML codes. trebor74hr h3   0 1 1 0 0 0
13570 2010-05-19 17:22:26 2011-09-28 16:12:27 2019-06-24 02:42:31.080349 Accepted assigned Core (Mail) Bug Normal 1.2   SMTP backend should try harder to figure out the local host name Django's SMTP backend sets the `local_hostname` argument to `smtplib.SMTP` by calling `socket.getfqdn()` (via `django.core.mail.utils.DNS_NAME`, which caches that result). `smtplib` itself uses a slightly more robust method (see `smtplib` around line 245) if `local_hostname` isn't given. In certain circumstances this can mean that sending mail through `smtplib` directly works, but sending it via `django.core.mail` fails. We could solve this by just passing `local_hostname=None`, but that'd result in a DNS lookup every time we send email, which is silly (and which is why we're caching it in the first place). So, `DNS_NAME` should use similar logic to `smtplib` to try harder to get the DNS hostname. sernin jacob   0 1 1 1 0 0
13659 2010-05-28 16:05:59 2017-01-16 09:55:55 2019-06-24 02:43:27.641275 Accepted assigned contrib.admin New feature Normal master   Make the request accessible in callables used in ModelAdmin.list_display Its a nice feature of the dajngo admin that you can use names of model or model admin methods and plain callables in ModelAdmin.list_display. But I want show content in my custom column dependant on the logged in user. This isn't possible at the moment. But I have written a patch that passes the request object to the given callable or method, when it has the needs_request attribute and it is True. czpython sebastian_noack   0 1 1 0 1 0
13677 2010-06-01 20:05:56 2019-06-20 13:11:26 2019-06-24 02:43:39.019042 Accepted assigned Forms Bug Normal master   ModelFormSet may query wrong database backend When using a !ModelFormSet with a queryset using a DB different from the 'default' one, the validation of the fields fails. debugging the code shows that the db used is the wrong one: {{{ -> self.instance.clean_fields(exclude=exclude) /usr/lib/pymodules/python2.5/django/db/models/base.py(902)clean_fields() -> setattr(self, f.attname, f.clean(raw_value, self)) /usr/lib/pymodules/python2.5/django/db/models/fields/__init__.py(194)clean() -> self.validate(value, model_instance) /usr/lib/pymodules/python2.5/django/db/models/fields/related.py(831)validate() -> qs = self.rel.to._default_manager.filter(**{self.rel.field_name:value}) > /usr/lib/pymodules/python2.5/django/db/models/manager.py(141)filter() -> return self.get_query_set().filter(*args, **kwargs) (Pdb) p self.get_query_set().db 'default' }}} The !ModelFormSet was created by creating Form with a queryset: {{{ def make_projecttask_formset(p, extra=0): class _ProjectTaskForm(forms.ModelForm): project = forms.ModelChoiceField(label="Project", queryset=Project.objects.using('otherdb').filter(project_id=p.project_id)) ... return modelformset_factory(ew_projecttask, form=_ProjectTaskForm, extra=extra) }}} Expected behavior: used db should be the same as in the queryset Note: it seems the problems is known (bug not fixed): * discussed in http://groups.google.com/group/django-developers/browse_thread/thread/22e52a2fd03eac82 * someone proposed a patch at http://github.com/aparo/django/commit/edcdc1d9364224fcbc3b810b9d9fa19a10cd537c (only the fields/related part imho) rixx pollux   0 1 1 1 0 0
13750 2010-06-12 22:34:14 2015-03-25 19:01:32 2019-06-24 02:44:27.039228 Accepted assigned File uploads/storage Bug Normal 1.2   ImageField accessing height or width and then data results in "I/O operation on closed file" If you have a simple model with an ImageField, the following code will fail with a "I/O operation on closed file": {{{ instance = MyClass.objects.get(...) w = instance.image.width h = instance.image.height original = Image.open(instance.image) }}} The work around is to reopen the file: {{{ instance = MyClass.objects.get(...) w = instance.image.width h = instance.image.height instance.image.open() original = Image.open(instance.image) }}} Note this is different than the issue of the 2nd read() returning empty strings for two reasons: 1. You can not seek(0), the file is closed. 2. Needing to reopen in this case is unexpected. aethemba ROsborne   0 1 1 0 0 0
13841 2010-06-27 16:25:49 2014-06-06 00:04:34 2019-06-24 02:45:25.864492 Accepted assigned Template system New feature Normal master   Allow context processors access to current version of context Allow context processors access to current version of context so that they can change values and not just override them. This can be easily done with another argument, context, and also backwards compatible. Functions would only get additional argument if they are defined to get two arguments and whatever they would return would override that in the context. copelco mitar   0 1 1 0 0 0
13896 2010-07-06 08:30:09 2011-11-18 23:29:11 2019-06-24 02:46:08.160131 Accepted assigned contrib.syndication New feature Normal master   Change language to dynamic attribute in syndication feed generator In my project, the language is dynamic and not hardcoded in settings. IMHO there is no way to change the language in syndication feed generator without a hack. Change language to dynamic attribute in syndication feed generator: {{{ #!diff Index: django/contrib/syndication/views.py =================================================================== --- django/contrib/syndication/views.py (revision 13426) +++ django/contrib/syndication/views.py (working copy) @@ -104,7 +104,7 @@ subtitle = self.__get_dynamic_attr('subtitle', obj), link = link, description = self.__get_dynamic_attr('description', obj), - language = settings.LANGUAGE_CODE.decode(), + language=self.__get_dynamic_attr('language', obj, settings.LANGUAGE_CODE.decode()), feed_url = add_domain(current_site.domain, self.__get_dynamic_attr('feed_url', obj) or request.path), author_name = self.__get_dynamic_attr('author_name', obj), }}} jasonkotenko jedie   0 1 1 0 0 0
13910 2010-07-08 04:07:27 2019-04-22 03:12:13 2019-06-24 02:46:17.096820 Accepted assigned Template system New feature Normal master   Add generator version of Template.render(Context) We already can make a streaming HttpResponse by passing a generator to it. This patch adds a "stream()" method to the Template class that returns a string generator that renders the template node-by-node suitable for passing to such HttpResponse. This also includes a shortcut function "stream_to_response()" -- the streaming version of render_to_response(). Gagaro rooney   0 1 0 0 0 0
14035 2010-07-30 15:43:03 2017-03-17 17:45:10 2019-06-24 02:47:36.806019 Accepted assigned HTTP handling Bug Normal master   Cannot access POST after request.encoding was set to a custom value Issue happens for multipart/form-data and WSGi handler. {{{ #Django trunk r13353. class DetectEncodingMiddleware(object): def process_request(request): # Lets say we define data encoding in POST param called "enc" enc = request.POST['enc'] # request._load_post_and_files() request.encoding = enc # request._set_encoding(): del self._post request.POST # request._load_post_and_files() # raise AttributeError("You cannot set the upload handlers after the upload has been processed."); }}} This issue is related: #12522 zimnyx zimnyx   0 0 0 0 0 0
14094 2010-08-11 13:59:39 2019-05-03 17:19:28 2019-06-24 02:48:14.445830 Accepted assigned Database layer (models, ORM) New feature Normal master   Cannot define CharField with unlimited length Model validation throws an error on CharField with a null max_length: {{{ #!python class Test(Model): char_field = CharField(max_length=None) }}} ''' One or more models did not validate:[[BR]] test.test: "char_field": CharFields require a "max_length" attribute that is a positive integer. ''' CharField should allow max_length=None, which intuitively means there is no maximum length. This is a perfectly valid use case. Postgres, for example, supports varchar/text columns without a length limit, but Django appears to have no way to define such a column in a model class. The model validation code looks like this ([http://code.djangoproject.com/browser/django/tags/releases/1.2.1/django/core/management/validation.py#L40 django/core/management/validation.py:40]): {{{ #!python if isinstance(f, models.CharField): try: max_length = int(f.max_length) if max_length <= 0: e.add(opts, '"%s": CharFields require a "max_length" attribute that is a positive integer.' % f.name) except (ValueError, TypeError): e.add(opts, '"%s": CharFields require a "max_length" attribute that is a positive integer.' % f.name) }}} It should be changed to something this: {{{ #!python if isinstance(f, models.CharField) and f.max_length is not None: ... }}} The FileField does not happen to throw this error because it is not a derivative of CharField. However, the SQL generated for FileField is not correct when max_length=None, so that would need to be addressed as well. ar45 millerdev   0 1 1 0 0 0
14317 2010-09-20 19:45:13 2019-04-14 09:10:07 2019-06-24 02:50:38.000095 Accepted assigned Internationalization Bug Normal master   numberformat.format produces wrong results The problem: {{{ >>> from django.utils.numberformat import format >>> print format(0.000000001, ',', 2) 1e-10,2 }}} It can be fixed with using '%.2f' % number (the format string can be constructed dynamically), and then replacing the decimal separator and doing the grouping if needed. As a bonus, it is faster that way. bartoszgrabski akaariai Localization, number formatting 0 1 1 0 1 0
14336 2010-09-23 21:24:23 2016-09-25 21:38:55 2019-06-24 02:50:50.089617 Accepted assigned contrib.admin New feature Normal 1.2   list_display should be able to contain sortable references to annotated fields Overriding the `queryset` method of a `ModelAdmin` should be an easy way to annotate the `QuerySet` used in the admin list view for a model. My use case is that I have two `IntegerField`s containing counts of various things, but what I'd like to be able to display and sort by in the admin list view is the sum of these two fields. This can best be explained by an example: {{{ #!python # Given this model class Article(models.Model): title = models.CharField(max_length=255) num_a = models.PositiveIntegerField() num_b = models.PositiveIntegerField() # Want ModelAdmin like... class ArticleAdmin(admin.ModelAdmin): list_display = ('title' 'total_nums') def queryset(self, request): qs = super(ArticleAdmin, self).queryset(request) return qs.extra(select={'total_nums':'num_a + num_b'}) }}} This fails at model validation with a `ImproperlyConfigured` exception in `django.contrib.admin.validation.validate` because the model has no 'total_nums' field, which we know. But the model validation mechanism has no access to the instance of the `ModelAdmin`, and therefore no access to the queryset to be able to check for any extras or annotations. I tried fixing this and would have submitted a patch, but I failed in the time I had. However, there is a workaround I discovered and am using, but it seems silly. You change `ArticleAdmin` to the following: {{{ #!python class ArticleAdmin(admin.ModelAdmin): list_display = ('title' 'total') def total(self, obj): return obj.total_nums total.admin_order_field = 'total_nums' def queryset(self, request): qs = super(ArticleAdmin, self).queryset(request) return qs.extra(select={'total_nums':'num_a + num_b'}) }}} This seems overly verbose and a little hacky, but it does work. I'd say that makes this ticket non-urgent, though I do wonder how many developers gave up before discovering this technique. bahoo pmclanahan   0 1 0 0 1 0
14761 2010-11-23 06:21:30 2015-05-28 15:39:30 2019-06-24 02:55:24.054158 Accepted assigned Core (URLs) New feature Normal master   URL resolving / reversing design doesn't allow alternate specs Django's URL resolution system is currently based on regexps and is represented by the RegexURLPattern class. There are cases where it would be preferable to subclass this and allow alternate ways of specifying URL patterns that ultimately compile down to regexps. Right now, this works for URL resolving as during resolution, the resolve method on the RegexURLPattern class is called, and hence subclasses can modify that behaviour. It however, '''doesn't''' work for URL reversal, because the resolver class generates the possible matches itself, instead of calling a method on RegexURLPattern or its subclasses as is the case with URL resolution. The attached patch simply refactors urlresolvers.py so the resolver calls a method on RegexURLPattern to get possible matches. It passes all the URL tests in Django, is completely backwards-compatible and introduces no new issues or quirks. I don't believe any new tests are required, and because the new method on RegexURLPattern is marked private (hence subject to change), no new docs are required either. This should stay as an unsupported way to extend Django's URL system until it is fully revamped (support disjunctives, URI templates etc.). The relevant thread on django-developers is here - http://groups.google.com/group/django-developers/browse_thread/thread/c94b551ebd57fbe6/65d79a336fef04b2 knbk samuel337 url resolve reverse 0 0 0 0 0 0
15279 2011-02-11 20:28:38 2014-06-14 00:20:07 2019-06-24 03:01:02.035016 Accepted assigned Database layer (models, ORM) Bug Normal master   Inheritance of fields from a single abstract base class through multiple abstract classes causes errors. Assume the following models in `app`: {{{#!python from django.db import models class Orange(models.Model): pass class BaseClass(models.Model): field = models.ForeignKey(Orange) class Meta: abstract = True class Parent1(BaseClass): class Meta: abstract=True class Parent2(BaseClass): class Meta: abstract=True class Child(Parent1, Parent2): pass }}} Currently, this definition will raise the following errors during model validation: {{{#!sh Unhandled exception in thread started by <bound method Command.inner_run of <django.core.management.commands.runserver.Command object at 0x101470490>> Traceback (most recent call last): File "..../django/core/management/commands/runserver.py", line 88, in inner_run self.validate(display_num_errors=True) File "..../django/core/management/base.py", line 253, in validate raise CommandError("One or more models did not validate:\n%s" % error_text) django.core.management.base.CommandError: One or more models did not validate: app.child: Accessor for field 'field' clashes with related field 'Orange.child_set'. Add a related_name argument to the definition for 'field'. app.child: Accessor for field 'field' clashes with related field 'Orange.child_set'. Add a related_name argument to the definition for 'field'. }}} Using the {{{ %(app_label)s_%(class)s_related }}} syntax only makes things worse: {{{ #!sh Unhandled exception in thread started by <bound method Command.inner_run of <django.core.management.commands.runserver.Command object at 0x10146e4d0>> Traceback (most recent call last): File "..../django/core/management/commands/runserver.py", line 88, in inner_run self.validate(display_num_errors=True) File "..../django/core/management/base.py", line 253, in validate raise CommandError("One or more models did not validate:\n%s" % error_text) django.core.management.base.CommandError: One or more models did not validate: app.child: Accessor for field … melinath melinath abstract inheritance 0 1 1 0 0 0
15619 2011-03-15 20:43:07 2018-01-09 13:34:11 2019-06-24 03:04:41.394413 Accepted assigned contrib.auth Bug Normal master   Logout link should be protected There is a logout link in admin app. It is link, not a form. Therefore it is not CSRF-protected. Probably it is not so important to protect logout from CSRF attack, because this fact cannot be used to do anything harmful. So this is just a request for purity. Another reason is that GET request should never change invernal state of the system. ramiro void   0 1 1 0 0 0
15727 2011-03-31 13:16:57 2019-03-20 10:48:41 2019-06-24 03:05:53.979488 Accepted assigned HTTP handling New feature Normal master   Add support for Content-Security-Policy (CSP) to core out of the box support for CSP would totally rock! See https://developer.mozilla.org/en/Security/CSP/Introducing_Content_Security_Policy for more information on what CSP is about. orf db.pub.mail@gmail.com   0 1 0 0 1 0
15855 2011-04-19 19:44:57 2017-07-15 11:39:14 2019-06-24 03:07:14.945040 Accepted assigned Core (Cache system) Bug Normal     cache_page decorator bypasses any Vary headers set in middleware A number of common response middlewares in Django (gzip, sessions, locale, csrf) add to the Vary header on responses, which is checked both by Django's caching system and upstream HTTP caches to determine what requests can safely be served that cached response. Getting the Vary header correct can be quite important, as failure to include it can mean upstream caches show session-private content to users who should not see it. Since view decorators run on the outgoing response first, before response middleware, the cache_page decorator caches the response before any of the mentioned response middlewares have a chance to add their Vary headers. This means two things: 1) the cache key used won't include the headers the response ought to vary on, and Django may later serve that response to users who really shouldn't get it, and 2) when that cached response is later served to a user, it still won't include the Vary header that it should have, and thus may also be cached wrongly by an upstream HTTP cache. I can't see a reasonable way of fixing this that maintains the current semantics of the cache_page decorator. The only option I've come up with is to require all users of full-response caching to always include the `UpdateCacheMiddleware` in their MIDDLEWARE_CLASSES (in its recommended spot at the top of the list, thus last in response processing), and only do the actual caching there. We'd then have to provide some way to say "don't cache pages unless they are marked" (a setting? ugh), and then the cache_page decorator would just mark the response for later caching (which would override the global don't-cache flag). renskiy carljm   0 1 0 0 1 0
16149 2011-06-03 14:53:43 2013-04-07 18:44:15 2019-06-24 03:10:30.778309 Accepted assigned Forms New feature Normal 1.3   Allow disabling choices in a <select> We need to be able to disable choices in a <select>, which is done by setting the disabled attribute on the <option> tag, for example: {{{<option value="bananas" disabled="disabled">Bananas</option>}}} Currently we're doing this by subclassing the Select widget: http://djangosnippets.org/snippets/2453/ It would be nice if the built in Select widget supported this. One way would be to replace the existing render_option method with what I've written, and I can prepare a patch if desired, but this approach changes the format of the "choices" data structure to something that won't be understood by other widgets. Perhaps these widgets should be improved too, but I don't want to do this unless the patch has a chance of being accepted. scjody scjody   0 0 0 0 0 0
16176 2011-06-08 17:16:03 2015-10-21 09:56:26 2019-06-24 03:10:50.178376 Accepted assigned Database layer (models, ORM) Bug Normal master   Overwriting a property with field during model inheritance. Documentation says (in https://docs.djangoproject.com/en/1.3/topics/db/models/#field-name-hiding-is-not-permitted paragraph) that: This restriction only applies to attributes which are Field instances. Normal Python attributes can be overridden if you wish. It also only applies to the name of the attribute as Python sees it: if you are manually specifying the database column name, you can have the same column name appearing in both a child and an ancestor model for multi-table inheritance (they are columns in two different database tables). However.. I came up today with setup like this: {{{ 1 from django.db import models 2 3 # Create your models here. 4 5 class SomeTestModel(models.Model): 6 some_field = models.CharField(max_length=100) 7 8 class Meta: 9 abstract = True 10 11 @property 12 def other_field(self): 13 return "[OTHER] %s" % self.some_field 14 15 16 17 class OtherModel(SomeTestModel): 18 other_field = models.CharField(max_length=100) 19 20 21 class AndMoreOther(SomeTestModel): 22 not_important_field = models.CharField(max_length=100) }}} And then if you do: {{{ >>> from testapp.models import * >>> o = OtherModel() Traceback (most recent call last): File "<console>", line 1, in <module> File "/home/arturstudio/PROJEKTY/tempdjango/inh/src/django/django/db/models/base.py", line 357, in __init__ setattr(self, field.attname, val) AttributeError: can't set attribute }}} Since my models where a lot bigger and more complicate, it took me almost all day to figure out that the problem was a @property from a base model, and my suggestion is that there should be at least a warning somewhere (during model's __init__ perhaps) that could be more precise about why attribute couldn't been set. (or attribute to which object (either Model or Field). I tried it on 1.2 and 1.4 pre-alpha SVN-16338 To reproduc… Thomas_Moronez czepiel.artur@gmail.com   0 1 1 0 0 0
16260 2011-06-15 01:40:13 2013-10-03 14:28:23 2019-06-24 03:11:45.211962 Accepted assigned contrib.admin New feature Normal master   Ability to change dismissRelatedLookupPopup on custom callback function The best solution for some cases for customizing admin is put some links with showRelatedObjectLookupPopup javascript function on admin changelist, but after user choose the object, custom javascript function must be called instead of dismissRelatedLookupPopup javascript function. Execution of dismissRelatedLookupPopup is hard coded in python code now. The easiest way to implement use case described higher is adding new GET argument "_callback" to changelist view. alekam alekam admin javascript 0 1 1 0 0 1
16508 2011-07-24 11:36:29 2019-03-08 06:15:51 2019-06-24 03:14:25.025764 Accepted assigned Database layer (models, ORM) New feature Normal master   Provide real support for virtual fields I have created a virtual field based on `GenericForeignKey`, but I found out that it can not be properly used for model initiation. Altered example from my test: {{{ class Managing(models.Model): shortcut = models.CharField(max_length=20) name_cs = TranslationProxyField('name', 'cs', False) class ManagingTranslation(models.Model): name = models.CharField(max_length=20) class TranslationProxyField(object): """ Descriptor that is a virtual field that provides access to translations. """ def __init__(self, field_name, language_code=None, fallback=False): self._field_name = field_name self._language_code = language_code self._fallback = fallback names = [field_name] if language_code is not None: names.append(language_code.replace('-', '_')) if fallback: names.append(FALLBACK_FIELD_SUFFIX) self.name = '_'.join(names) def contribute_to_class(self, cls, name): if self.name != name: raise ValueError('Field proxy %s is added to class under bad attribute name.' % self) self.model = cls cls._meta.add_virtual_field(self) # Connect myself as the descriptor for this field setattr(cls, name, self) # This results in Type error from Model.__init__, because of extra kwarg Managing(shortcut='name', name_cs='jméno') }}} I tried to use `pre_init` signal, but I found out that I will not get `instance` argument, so I can not use that. This way is truly usable only for virtual fields which are like `GenericForeignKey` built on real model fields of object. When it gets more complicated, it can not be used. Confusing on this path is that `instance` is in `providing_args` of `pre_init` signal. Currently I solve this by quite a hack which is deriving of `TranslationProxyField` from `property` instead of `object`. This works because of setting properties is allowed in `Model.__init__`. In my opinion, a stable solution would… auvipy vzima   0 0 0 0 0 0
16521 2011-07-26 13:56:40 2013-10-22 22:11:14 2019-06-24 03:14:33.245771 Accepted assigned contrib.admin New feature Normal 1.3   Provide keyboard shortcuts in admin Please provide keyboard shortcuts in Django's admin. They could be GMail-style (j and k for going up and down the item lists, / to search, etc.) or anything else, as long as they work. anonymous coolRR   0 0 0 0 0 1
16732 2011-08-30 21:49:03 2019-06-21 12:27:14 2019-06-24 03:16:50.032951 Accepted assigned Database layer (models, ORM) Bug Normal master   Unable to have abstract model with unique_together I have such model definition: {{{ class SlugVersion(models.Model): class Meta: abstract = True unique_together = (('slug', 'version'),) slug = models.CharField(db_index=True, max_length=10, editable=False) version = models.IntegerField(db_index=True, editable=False) class Base(SlugVersion): name = models.CharField(max_length=10) class Test(Base): test = models.IntegerField() }}} And I am getting: {{{ Error: One or more models did not validate: test.test: "unique_together" refers to slug. This is not in the same model as the unique_together statement. test.test: "unique_together" refers to version. This is not in the same model as the unique_together statement. }}} I see this is as a bug. Why there could not be a table for class `Base` with unique constraints on its `slug` and `version` fields, and then 1-1 relationship with additional table for model `Test` with field `test`. cansarigol mitar   0 1 0 0 0 0
16872 2011-09-17 20:08:58 2014-06-06 00:04:05 2019-06-24 03:18:25.541127 Accepted assigned GIS New feature Normal     Add touch support to the geographic admin !OpenLayers 2.11 added support for touch events, it would be nice to be able to edit geometries inside the admin from mobile devices, e.g., the iPad and Android tablets. jbronn jbronn gis admin touch 0 1 1 0 0 0
17208 2011-11-12 09:22:11 2016-10-20 22:41:22 2019-06-24 03:22:02.681968 Accepted assigned contrib.admin Cleanup/optimization Normal master   Dogfood class-based views in contrib.admin This is something that I believe was discussed at DjangoCon, as well as in the django-dev mailing list and on IRC. It would be good to do a) on principle, b) to make the admin views easier to extend, and c) to potentially find and correct issues in the generic class-based views. Naturally, any solution would need to be backwards-compatible. yoongkang melinath class-based views admin 0 1 0 0 1 0
17235 2011-11-15 15:41:51 2018-06-29 16:36:19 2019-06-24 03:22:19.877187 Accepted assigned HTTP handling Bug Normal master   Multipartparser shouldn't leave request.POST/request.FILES mutable Currently the multipart parser constructs ''!QueryDicts'' for POST and FILES as mutable. Since we discourage users to change ''!QueryDicts'' (and don't allow it for GET and normal POST) the parser should change the flag to False before returning it. This way multipart POSTs would be more consistent with normal POSTs which aren't mutable. vinayinvicible apollo13   0 0 0 0 0 0
17461 2011-12-25 12:36:12 2015-03-07 19:25:06 2019-06-24 03:24:45.231557 Accepted assigned Documentation Cleanup/optimization Normal 1.3   Document presumed order of foreign keys on intermediate M2M model When defining a many-to-many relationship from a model to itself and using an intermediary model, {{{ class User(models.Model): name = models.CharField(max_length=100) followers = models.ManyToManyField('self', through='Relationship', symmetrical=False) def __unicode__(self): return self.name class Relationship(models.Model): target = models.ForeignKey('User', related_name='r1') follower = models.ForeignKey('User', related_name='r2') created_at = models.DateTimeField(auto_now_add=True) }}} It seems that django determine 'from field' and 'to field' by it's definition order, the first field always used as 'from field' and the second field always used as 'to field'. So I MUST put `target` field defintion above the `follower` field. I checked the document but can not found any infomation to confirm it, I think the document should clearly explained the rule. Oxylo flytwokites@gmail.com   0 0 0 0 1 0
17498 2012-01-03 16:19:45 2017-09-25 17:41:12 2019-06-24 03:25:08.796325 Accepted assigned contrib.admin New feature Normal     Add a way to register a model with the admin but prevent it from appearing on the app index page I have come upon an interesting use case that I believe would benefit from a new option. I have a model that is normally administered underneath another model via a TabularInline arrangement. However, this model may also be a foreign key option to other models. When going to the admin page of these other models, the normal "+" sign graphic to add a model is not present (which makes sense, as it is not registered independently with the admin). However, I need the "+" sign add option to appear, but also want the object to not appear in the main index by itself -- because it should be administered via the TabularInline's underneath its normal parent object and two standard paths to the same object cause user confusion. (There is more detail here: http://groups.google.com/group/django-users/browse_thread/thread/99f90b66e24cfa60 .) The patch I propose and attach is against Django version 1.2.5. It adds an option "no_index" to the models' meta class which causes an independently registered model to not appear in the main index or app index. (The patch is functional, but not pretty. If the use case and feature are deemed valuable, it might be implemented in a better way. (E.g., it only checks for the presence of "no_index" and ignores the value.)) heba1108 kace admin 0 1 1 0 0 0
17508 2012-01-06 12:22:31 2013-07-06 09:21:06 2019-06-24 03:25:15.026601 Accepted assigned Generic views New feature Normal master   DateDetailView should accept less specific dates, ie Year/Month or just Year DateDetailView currently expects segments for year, month and day in the URL. This introduces the requirement to have an archive page for each level of the date; ie a year archive, a month archive, and a day archive: /2012/ /2012/jan/ /2012/jan/06/ /2012/jan/06/blog-entry-name/ I don't think I'm inaccurate in saying that most bloggers (as opposed to news sites) don't usually create more than one post a day, and many (myself included) have a frequency of much less than once per month. This means we're introducing views such as day archive that have exactly the same information as the higher levels. As a URL purist, I don't like unnecessary segments in my schema and unnecessary pages in my information architecture. In my case my URL structure is as follows, I don't use DayArchive at all: /2012/ /2012/jan/ /2012/jan/blog-entry-name/ I've achieved this by creating my own version of DateDetailView that removes the use of DayMixin, but I think this can also be achieved by modifying DateDetailView itself to allow looser date matching using configuration of the view itself. Is this a common enough use case to be worth making the change in Django itself? I think it can be done without affecting backwards compatibility. moonlimb AndrewIngram   0 1 0 1 1 0
17664 2012-02-09 08:48:31 2018-04-02 21:06:59 2019-06-24 03:26:55.337763 Accepted assigned Template system Bug Normal master   {% if %} template tag silences exceptions inconsistently This buggy behaviour took me a while to track down. I hope I can explain it clearly. Given a `QuerySet` with invalid ordering (and possibly other conditions) that should raise an exception when evaluated, `{% if qs %}` will raise the exception while `{% if not qs %}` will silence it and leave `qs` as if it were simply empty on subsequent access in the template. First, the exception is silenced and the queryset becomes empty: {{{ >>> from django.contrib.auth.models import User >>> from django.template import Template, Context >>> Template('count: {{ qs.count }}, empty: {% if not qs %}yes{% else %}no{% endif %}, qs: {{ qs }}, count: {{ qs.count }}').render(Context({'qs': User.objects.order_by('invalid_field')})) u'count: 98, empty: no, qs: [], count: 0' }}} And now if we swap the `{% if %}` around a bit, we get an exception: {{{ >>> Template('count: {{ qs.count }}, empty: {% if qs %}no{% else %}yes{% endif %}, qs: {{ qs }}, count: {{ qs.count }}').render(Context({'qs': User.objects.order_by('invalid_field')})) Traceback (most recent call last): File "<console>", line 1, in <module> File "/Users/mrmachine/django/template/base.py", line 139, in render return self._render(context) File "/Users/mrmachine/django/template/base.py", line 133, in _render return self.nodelist.render(context) File "/Users/mrmachine/django/template/base.py", line 819, in render bits = [] File "/Users/mrmachine/django/template/debug.py", line 73, in render_node return node.render(context) File "/Users/mrmachine/django/template/defaulttags.py", line 273, in render if var: File "/Users/mrmachine/django/db/models/query.py", line 129, in __nonzero__ iter(self).next() File "/Users/mrmachine/django/db/models/query.py", line 117, in _result_iter self._fill_cache() File "/Users/mrmachine/django/db/models/query.py", line 855, in _fill_cache self._result_cache.append(self._iter.next()) File "/Users/mrmachine/django/db/models/query.py", line 288, in iterator … raiderrobert mrmachine smart if tag queryset exception silenced 0 0 0 0 0 0
17688 2012-02-14 22:18:26 2016-10-07 09:34:49 2019-06-24 03:27:11.094680 Accepted assigned Database layer (models, ORM) Bug Normal 1.3   No m2m_changed signal sent to when referenced object is deleted {{{ class Topping(models.Model): name = models.CharField() class Pizza(models.Model): name = models.CharField() toppings = models.ManyToManyField(Topping, null=true, blank=true) }}} And this data established using those models: {{{ TOPPING id=1, name="Pepperoni" id=2, name="Onion" id=3, name="Mushroom" PIZZA id=1, name="foopizza" toppings=1,2,3 }}} 1. Deleting any Topping object (for example, deleting id=1, name="Pepperoni") also removes it from foopizza.toppings. '''GOOD''' 2. No m2m_changed signal is sent when 1 (above happens). '''BAD?''' jorgecarleitao jblaine@kickflop.net   0 1 1 0 0 0
17905 2012-03-15 13:20:41 2013-02-23 23:11:27 2019-06-24 03:29:33.140202 Accepted assigned contrib.admindocs New feature Normal 1.4-alpha-1   Admin documentation lists all models, even for users without access to certain applications By default, the admin docs lists documentation for all models. Some users may not have access to models that are still listed in their entirety. The easiest way to fix this was to check each model in the model index, and only add the model to the listing if a user has the correct permissions. I'm not sure if this is the correct way to go about this, but I'm submitting the patch for review. gszczepanczyk chriscohoat   0 1 0 1 0 0
17943 2012-03-20 21:34:27 2014-01-31 10:20:55 2019-06-24 03:29:57.573793 Accepted assigned Core (Cache system) Bug Normal 1.4   Too many open file descriptors while using memcache Hi all, I am using Django 1.3.1 with memcached server under Linux (PLD distro). Django application is run with runfcgi command (maxspare set to 20). After switching to Django 1.3.1 (from line 1.2.x) I encountered very strange behaviour -- the app became crashing after some time. What I have discovered is very large number of open socket connections made by the Django app to the memcached server (lsof show hundrets of open descriptors). After some time the app process had been killed by the system, due to exceeded number of opened file descriptors. Look at Google pointed me to the ticket #15324. Since that patch has been incorporated in the Django 1.3.1, I have started digging into memcached Django wrapper over the pyton-memcached module (django.core.cache.backends.memcached). What I found is that Django app run in multithreaded mode creates new cache object for every thread. This is probably good information, since it has allowed avoid difficult race conditions. What is sad - after closing/releasing the thread, the cache object is somehow not deleted properly. I mean it seems that it does not clean up all gathered resources properly. This lasts with large number of opened file descriptors in the memcached case. I have added simple patch fixing said behaviour. It works quite well for me, thus I assume I could be considered to be improved and somehow merged with the Django sources. I have not created any tests, I am sorry for that. haxoza m.gajda@paranoja.pl cache memcache open file descriptors 0 1 1 0 0 0
18283 2012-05-07 17:17:13 2015-11-15 22:13:33 2019-06-24 03:33:36.844636 Accepted assigned Database layer (models, ORM) Bug Normal 1.4   FileField should not reuse FieldFiles A simple example: {{{ old_image = mymodel.image old_image.open() try: mymodel.image = do_something_with_image(old_image) finally: old_image.close() mymodel.save() # transaction manager is in auto commit mode old_image.delete() }}} '''Expected behavior:''' New file is commited to disk and database, old file is removed. '''Actual behavior:''' New file is commited to disk and database, then this new file is removed from disk. That's because FileField (or to be more precise: FileDescriptor class) is re-using FieldFile objects instead of creating new FieldFile for every new instance of a file. This leads to unexpected results and data loss (like in example). trg sayane   0 0 0 0 0 0
18763 2012-08-13 21:47:49 2019-04-21 19:51:04 2019-06-24 03:38:47.031752 Accepted assigned contrib.auth New feature Normal master   Shortcut to get users by permission In my apps I often need to get the list of users who have a specific permission. But it seems there is no shortcut to do this in Django itself (unless I'm missing something obvious). And getting users by permission is slightly more complicated than may appear at first sight because user permission can be set at user level or at group level, and also we need to pay special attention to superusers. So I usually end up doing something like this: {{{ from django.contrib.auth.models import User from django.db.models import Q def get_users_by_permission_q(permission_name, include_superusers=True): """ Returns the Q object suitable for querying users by permission. If include_superusers is true (default) all superusers will be also included. Otherwise only users with explicitely set permissions will be included. """ (appname, codename) = permission_name.split(".") query = \ Q(user_permissions__codename=codename, user_permissions__content_type__app_label=appname) | \ Q(groups__permissions__codename=codename, groups__permissions__content_type__app_label=appname) if include_superusers: query |= Q(is_superuser=True) # The above query may return multiple instances of User objects if user # has overlapping permissions. Hence we are using a nested query by unique # user ids. return {'pk__in': User.objects.filter(query).distinct().values('pk')} def get_users_by_permission(permission_name, include_superusers=True): """ Returns the queryset of User objects with the given permission. Permission name is in the form appname.permission similar to the format required by django.contrib.auth.decorators.permission_required """ return User.objects.filter( get_users_by_permission_q(permission_name, include_superusers) ) }}} And them in my models.py: {{{ class MyModel: my_fk_field = models.ForeignKey(User, limit_choices_to=dict(is_active=True, \ *get_users_by_permission_q("myapp.cha… berkerpeksag shelldweller   0 1 0 0 0 0
18855 2012-08-25 15:45:33 2014-07-03 13:13:23 2019-06-24 03:39:46.115446 Accepted assigned HTTP handling New feature Normal master   persist a socket across reloads of the dev server Using livereload (livereload.com) with Django becomes painful when updating a file immediately results in reloading the webpage AND the Django dev server. There is a short period of time when the dev server is not listening as it is busy reloading (frequently hit when using livereload). This is exacerbated with larger projects as reload time is longer. This has been an itch I've wanted to scratch for a long time. Hopefully, this will be accepted so others can benefit from it also. Helps plenty even with users hitting Reload manually on their browser. dlamotte dlamotte   0 1 1 0 0 0
18887 2012-08-31 08:51:43 2015-11-11 11:06:57 2019-06-24 03:40:06.277027 Accepted assigned GIS Cleanup/optimization Normal 1.4   LineString array method (property) returns different data type without and with NumPy installed Apparently LineString (and probably other geometry types) return data in different types depending on whether NumPy is installed. Simple test case (reproducible in Django 1.3, 1.3.1 and 1.4.1). Clean virtual env with only Django installed (and ipython). First - no NumPy installed. {{{ In [1]: from django.contrib.gis.geos import LineString In [2]: line = LineString((0, 0), (3, 3)) In [3]: line.array Out[3]: [(0.0, 0.0), (3.0, 3.0)] }}} Now - install NumPy and try again. {{{ In [1]: from django.contrib.gis.geos import LineString In [2]: line = LineString((0, 0), (3, 3)) In [3]: line.array Out[3]: array([[ 0., 0.], [ 3., 3.]]) }}} [(0.0, 0.0), (3.0, 3.0)] =! array([[ 0., 0.],[ 3., 3.]]) This is rather serious issue. sir-sigurd mal GIS, NumPy, LineString 0 1 1 0 1 0
19221 2012-10-31 22:50:42 2017-01-14 20:39:43 2019-06-24 03:43:42.768507 Accepted assigned Core (Cache system) Bug Normal master   Check that cache keys are string In current master cache keys can't be integers whilst they can in 1.4. Attempts to do this result in: {{{ File "/home/ismdj/src/django/django/core/cache/backends/dummy.py", line 15, in get key = self.make_key(key, version=version) File "/home/ismdj/src/django/django/core/cache/backends/base.py", line 80, in make_key new_key = self.key_func(key, self.key_prefix, version) File "/home/ismdj/src/django/django/core/cache/backends/base.py", line 26, in default_key_func return ':'.join([key_prefix, str(version), key]) TypeError: sequence item 2: expected string or Unicode, int found }}} The issue seems to have been introduced with this commit: https://github.com/django/django/commit/45baaabafb6cf911afad9ec63c86753b284f7269 etos mhsparks   0 0 0 0 0 0
19227 2012-11-02 10:27:18 2013-09-18 17:25:22 2019-06-24 03:43:46.622934 Accepted assigned Documentation Cleanup/optimization Normal master   Reorganize method flowchart for class based generic views to tree It would be nice to have a tree that build up the flowchart. jambonrose shoul@gmx.de docs 0 0 0 0 0 0
19255 2012-11-06 09:24:36 2015-10-16 20:58:57 2019-06-24 03:44:05.035997 Accepted assigned contrib.contenttypes Bug Normal 1.4   BaseGenericInlineFormSet runs validation methods before linking form instances to their related object Given this model: {{{ class Model(models.Model): content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() object = generic.GenericForeignKey() def clean(self): assert self.object_id assert self.object }}} and this admin: {{{ class ModelInline(generic.GenericStackedInline): model = Model }}} When saving a new `Model`, the assertion will fail. The object will not be linked, nor will the object_id be available to the clean function. This is because the fields are excluded from the formset and the values are set through the generic InlineAdmin, see this excerpt: {{{ generic.py:412 def save_new(self, form, commit=True): # Avoid a circular import. from django.contrib.contenttypes.models import ContentType kwargs = { self.ct_field.get_attname(): ContentType.objects.get_for_model(self.instance).pk, self.ct_fk_field.get_attname(): self.instance.pk, } new_obj = self.model(**kwargs) return save_instance(form, new_obj, commit=commit) }}} To hack around this issue, the forms and formsets involved should not cache the validation result. The clean function should then validate the value if it is present (the second time when cleaning). The hack is quite ugly and requires a lot of coding. It should be possible to easily validate the newly related-to foreign key object. arielpontes bouke   0 0 0 0 0 0
19515 2012-12-24 17:40:33 2017-09-30 15:37:04 2019-06-24 03:46:53.956195 Accepted assigned contrib.redirects Cleanup/optimization Normal master   Increase the max_length of Redirect.old_path/new_path In `django.contrib.redirects` the the `old_path` and `new_path` have `max_length=200`. This presents problems when either of the paths has a longer length than 200. `URLField` used to have a `max_length=200`, but this was resolved [1477] and isn't even applicable, since the path fields use `CharField`s, not `URLfield`s. I would recommend a `max_length=2000`. URL's with a length over 2000 are [http://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url not as well supported]. However since [https://docs.djangoproject.com/en/dev/ref/databases/#character-fields database enforcement of CharFields in MySQL is limited to 255 characters], the fields have to be also changed to `TextField`s. saulshanabrook s.shanabrook@gmail.com   0 1 1 0 0 0
19528 2012-12-27 12:48:07 2015-07-12 16:20:13 2019-06-24 03:47:02.269262 Accepted assigned contrib.staticfiles Bug Normal 1.4   CachedFilesMixin does not rewrite rules for css selector with path Using CachedFilesMixin we'll have paths like this `<img alt="True" src="/media/static/admin/img/icon-yes.0596085e212f.gif">` after template rendering, but an unmodified selector: `img[src$="admin/img/icon-yes.gif"]` in processed stylesheet. This happens because CachedFilesMixin.patterns does not contain a rule like this `"""(img\[src[\^\$\*]{0,1}=\s*["']\s*(.*?)["'])"""` to match against and actually can not deal with `^=|$=|*=` operators. I am not sure how such paths can be properly processed, though. jnovinger mike@openbunker.org CachedFilesMixin staticfiles djbday 0 0 0 0 0 0
19544 2012-12-31 18:06:27 2019-02-24 21:39:37 2019-06-24 03:47:12.465611 Accepted assigned Database layer (models, ORM) Cleanup/optimization Normal master   IntegrityError during ManyToMany add() on Oracle or for user-defined through relationships. I'm frequently getting this exception ("IntegrityError: duplicate key value violates unique constraint...") a lot in my production server when I do `add()` on a Many To Many relationship. For what I've seen, there seems to be a race condition in `django.db.models.fields.related`'s `ManyRelatedManager._add_items()` between the point `new_ids` is "calculated" and the point `bulk_create()` actually creates the tuples in the database. charettes Kronuz   0 0 0 0 0 0
19580 2013-01-08 19:24:27 2019-04-14 20:11:18 2019-06-24 03:47:37.625120 Accepted assigned Database layer (models, ORM) Cleanup/optimization Normal master   Unify reverse foreign key and m2m unsaved model querying Currently when querying unsaved reverse relations the behavior differs. Using model: {{{ class Foo(models.Model): fk = models.ForeignKey('self', related_name='fk_rev') m2m = models.ManyToManyField('self') }}} and test case: {{{ print(Foo().fk_rev.all()) print(Foo().m2m.all()) }}} We get [] from the first filter, but an error {{{ ValueError: "<Foo: Foo object>" needs to have a value for field "from_foo" before this many-to-many relationship can be used. }}} from the second filter. So, m2m fields can't be filtered if the object isn't saved, but reverse fk fields can be filtered. There is a (slightly stale) patch for #17541 which makes fk fields and m2m fields work consistently. The changes in behavior are: {{{ * Nullable many-to-many and foreign key relations will return an empty queryset when the relation field is null. For many-to-many this was previously an error (no change for foreign keys). * Trying to add objects to a foreign key relation when the relation field is null is now an error (no change for m2m). * Trying to use a relation of any kind when the object isn't saved is now an error (no change for m2m). }}} I think we can squeeze these changes in as bug-fixes. These are slight backwards compatibility changes, but to me it seems that almost always the changes will be visible only in code that isn't working as intended. If these are seen as something likely breaking working code, then I don't see any way to make the APIs consistent. The #17541 patch is available from: https://github.com/akaariai/django/compare/ticket_17541 Rajesh-Veeranki akaariai   1 1 1 0 0 0
19755 2013-02-06 14:13:35 2019-01-09 21:39:03 2019-06-24 03:49:29.336142 Design decision needed assigned contrib.admin New feature Normal master   Incremental filter Would be a good feature to have filter's value that change incrementally when user select one of them. I try to explain with an example: {{{ class Person(models.Model): name = models.CharField() hair_color = models.CharField() eye_color = models.CharField() class PersonAdmin(admin.ModelAdmin): list_filter = ["hair_color", "eye_color"] }}} At first I'll see all hair color and eye color values in the filter. When I select an hair color value from the filter I'll see only person with that hair color. I would view in the eye color filter only distinct values of eye colors of person that have hair color I selected from the filter. suligap paulox@paulox.net filter, admin 0 1 1 0 0 1
19898 2013-02-23 18:41:29 2013-10-17 13:26:56 2019-06-24 03:51:00.935797 Accepted assigned Documentation New feature Normal master   Document why/when of class-based views The documentation for class-based views is getting better, but it's missing an introductory discussion of why and when you use them. Specifically, the goals of such a narrative should be: * Practical context for choosing CBVs vs. FBVs * Usage patterns appropriate to class-based views * List of helpful, concrete decision points from the above discussion Hopefully this can be something that people point to for diffusing absolutist arguments for CBVs or FBVs, and the community can start to agree when each is right (a bit of a grandiose goal, yes, but it should be possible). New documentation that may arise out of the above needs: * How to test class-based views (and comparison with testing FBVs) Ticket #19227 aims to provide visualizations code flows in class-based views and so may interact with some of the changes made on this ticket. estebistec estebistec docs sprint2013 0 1 1 0 0 0
20081 2013-03-18 21:08:53 2015-04-16 17:29:33 2019-06-24 03:52:58.571393 Accepted assigned Core (Other) New feature Normal master   Minimize the risk of SECRET_KEY leaks '''Paul:''' We should consider generating it on the fly something like the way Horizon does: https://github.com/openstack/horizon/blob/master/horizon/utils/secret_key.py The things we lose when the secret key changes (sessions and password reset links IIRC) are generally per-deployment specific anyway. There's still a lot of bikeshedding to be found behind that issue (should production servers have the ability to write this file), but it's not a bad approach for those same users who commit their secret keys to their public github repos. '''Jacob:''' Oh this is neat! So basically when the server starts up it writes out a secret key file if it one doesn't already exist? I like it, seems like a really good thing to do in core. Security-by-default and all that. How does this handle multiple web servers, though? Seems like if you weren't careful you'd end up with differing secrets across your web nodes, bad news. Couldn't we do something similar but store the key in the database? That seems like it wouldn't be any more or less secure than the filesystem, and would solve N=1 problems. '''Paul:''' Yeah, the multiple servers deployment its downside and the reason I originally objected to including it in Horizon. What it does is bump the user-facing issue (you have to deal with and understand a secret key) a bit further along the line. I'd be willing to guess that a majority of Django sites that leak the secret key fall into the N=1 category, or would do the correct thing WRT secret key if it weren't so easy to commit to the repo and was a specific action they had to take when N > 1. The downside of course is that there will always be a learning curve. I'm -1 on storing the key in the database - databases tend to be easier to compromise than file systems, and people tend to be lazy about the security of their DB backups. aj7may jacob nlsprint14 0 1 1 0 0 0
20205 2013-04-05 16:26:37 2018-08-09 21:36:37 2019-06-24 03:54:17.639457 Accepted assigned Database layer (models, ORM) Bug Normal master   PositiveIntegerfield does not handle empty values well When using a model PositiveIntegerField with blank=True and null=True, '' (empty string) is not allowed as a blank response value. An extra manual step seems needlessly necessary to convert an empty string (say, received from a form) to convert to python None value. Shouldn't this be fixed in to_get_prep_value()? This is usually not the case for CharFields, TextFields or some of the other model fields. Here is the exception: {{{ Exception Value: invalid literal for int() with base 10: '' Exception Location: .../django/db/models/fields/__init__.py in get_prep_value, line 991 }}} It seems an update to IntegerField's get_prep_value or to_python may help. AmiZya anonymous   0 1 1 0 0 0
20313 2013-04-24 12:49:57 2019-02-12 18:15:36 2019-06-24 03:55:27.683209 Accepted assigned contrib.auth New feature Normal     AnonymousUser should follow custom User implementation Introducing custom User classes opened a few new options for handling authorization logic, e.g.: {{{ self.request.user.has_purchased(object) }}} or as @akaariai mentioned: {{{ request.user.has_role_in_org(some_org) }}} Without being able to define custom AnonymousUser class that follows User implementation this will not work. There are some ideas on how to solve that, and the ones discussed are: * defining {{{anonymous_user_class}}} on {{{UserClass}}} (@akaariai) * merging {{{User}}} and {{{AnonymousUser}}} (@apollo13) The current dirty patch uses the same approach as with {{{get_user_model()}}}: * django.contrib.auth.get_anonymous_model * django.conf.global_settings.AUTH_ANONYMOUS_MODEL and changes in: * django.contrib.auth.context_processors * django.db.models.sql.where.WhereNode thinkingpotato thinkingpotato@gmail.com   0 0 0 0 0 0
20347 2013-05-03 12:07:19 2013-09-18 17:23:39 2019-06-24 03:55:49.809685 Accepted assigned Forms New feature Normal 1.5   Add an absolute_max parameter to formset_factory The documentation at https://docs.djangoproject.com/en/1.5/topics/forms/formsets/#limiting-the-maximum-number-of-forms seems to indicate (if I understood it correctly) that the purpose of the `max_num` parameter is to prevent that someone sends a manipulated, excessively large value in the hidden form field that states the number of (extra) forms that are submitted, whereas it is not (directly) related to the number of forms that are //actually// POSTed, or initialized via parameter `initials`. However, following the example at that page, with `MyInitials` being a list of e.g. 1500 initial values and `request.POST` containing more than 1500 formsets: {{{ #!python >>> ArticleFormSet = formset_factory(ArticleForm, extra=0) >>> formset1 = ArticleFormSet(initial=MyInitials) >>> formset2 = ArticleFormSet(request.POST) }}} Now, accessing `formset1.forms[1000]` throws an IndexError exception. The `max_num` is at its default value of 1000, but in the above context, it is not expected that `formset1` or `formset2` is reduced to `max_num` forms -- I'd have expected each to have the full number of forms as initialized. Related thread at django-users: http://thread.gmane.org/gmane.comp.python.django.user/152946 ethurgood CarstenF   0 1 1 0 0 0
20372 2013-05-07 16:41:18 2017-03-14 03:00:27 2019-06-24 03:56:05.675277 Accepted assigned contrib.admin Cleanup/optimization Normal 1.5   using registration/logged_out.html template overrides admin logout Hi I created registration/login.html and registration/logged_out.html templates to handle my site login/logout using the provided auth views login/logout. While the admin app login using admin/login.html, it logouts using registration/logged_out.html. So, having my own registration/logged_out.html overrides that of the admin app. alexisbellido tomerz@cgen.com   0 1 1 0 1 0
20423 2013-05-16 20:50:12 2013-05-20 14:42:06 2019-06-24 03:56:39.501114 Accepted assigned Template system Bug Normal master   Template renderer does not parse numeric variables Currently a Variable is defined, according to the django template [https://docs.djangoproject.com/en/dev/ref/templates/api/ manual], as : Variable names consist of any combination of alphanumeric characters and the underscore ("_"). If a variable is composed of numbers only, it will not get its context data correctly, coming across as an int. This patch assigns the appropriate context data to the Variable class when it encounters an integer. Here's the current behavior: from django.template.base import Template from django.template.base import Context t = Template("{{ 123 }}") t.render(Context()) u'123' t = Template("{{ foo }}") t.render(Context({"foo":"bar"})) u'bar' iapain antonio@webcubecms.com number variable 0 1 1 0 0 0
20434 2013-05-18 10:40:16 2014-02-12 16:24:09 2019-06-24 03:56:46.532883 Accepted assigned Template system New feature Normal     Have a template tag grammar instead of handling token/parser for every tag, and make it possible to introspect the grammar. Right now, if people use @register.simpletag (or assignment_tag/inclusion_tag), a compiled parser function will be registered in the library.tags mapping. This however, is insufficient, if you need to do some introspection on the available template tags. I'd like to know for instance which template tags in module X are an instance of simpletag and would thus create a SimpleNode. Right now, we are unable to accurately build a real AST from the template without manually defining which templatetags behave in which way. This is also required for AST transformations, like template compression and such. I guess, it would be great to encourage people to always use @register.simpletag or anything that uses the built-in Node classes of Django. We can't force that, but it has a lot of advantages. jonathanslenders jonathanslenders   0 0 0 0 0 0
20581 2013-06-11 05:40:24 2019-04-19 08:59:37 2019-06-24 03:58:20.865120 Accepted assigned Database layer (models, ORM) New feature Normal master   Support DEFERRABLE INITIALLY DEFERRED for UNIQUE constraints It would be useful, when using unique_together, to be able to defer constraint checking the way we defer foreign key checking until the end of the transaction. Ian-Foote dmadeley@infoxchange.net.au db-indexes 0 1 1 0 0 0
20712 2013-07-07 04:46:45 2013-09-16 14:48:55 2019-06-24 03:59:44.291591 Accepted assigned contrib.staticfiles New feature Normal 1.4   staticfiles and serving post-processed files through development server [https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/ staticfiles app] allows custom storage. I have implemented a storage which [https://github.com/wlanslovenija/nodewatcher/blob/98525b82e410989c033301f755b1e180b7947662/nodewatcher/core/frontend/staticfiles/storage.py automatically compiles .scss files into .css files]. The issue that such post-processed files are not served when using staticfiles development server. I have to override `runserver` with core one to be able to serve the files I collect manually. I think it would be useful to support such use cases as it would open window for further integration of static files (like bundling JavaScript into one and so on). While some are useful just for production, some are necessary while development as well. jezdez mitar   0 0 0 0 0 0
20749 2013-07-15 16:35:37 2015-07-31 18:49:12 2019-06-24 04:00:08.092935 Accepted assigned Core (System checks) New feature Normal master   Add validation for type of Field.choices arguments If I have a model like so: {{{ class Program(models.Model): STATUS_CHOICES = ( (1, 'Inactive'), (2, 'Active'), ) status = models.CharField(choices=STATUS_CHOICES) }}} And I try get_status_display(), I will get '1' or '2' as the output rather than 'Inactive' or 'Active'. Django silently coerces the type of the choices upon saving, but does not give an indicator upon retrieval that the choice was not found. _get_FIELD_display in db/models/base.py attempts to pull the value from the choices, but since python does not see int and str keys as equivalent, it does not find the value; instead, it defaults to the value in the database. The end-user solution is to make sure all types are correct, but this could cause confusion for a newbie since this is all done without warning. I see a few possible solutions: 1) warn the user when creating a choice field that is not of the same type as the model. 2) warn the user when get_FOO_display is called but no value is found. 3) coerce the keys to strings before attempting to retrieve in get_FOO_display. I'm not sure if this would have other implications. ellisd23 ellisd23@gmail.com   0 0 0 0 0 0
20752 2013-07-15 19:45:47 2014-06-07 20:46:02 2019-06-24 04:00:10.163397 Accepted assigned HTTP handling Bug Normal master   Error signals are not reliable, especially when dealing with database errors In core.handlers.base, unhandled exceptions are processed as such: {{{ except: # Handle everything else, including SuspiciousOperation, etc. # Get the exception info now, in case another exception is thrown later. signals.got_request_exception.send(sender=self.__class__, request=request) response = self.handle_uncaught_exception(request, resolver, sys.exc_info()) }}} Which delivers the error signal to the various handlers (database transaction resets, things like Sentry etc). However, the code that dispatches signals aborts the dispatch if any of the handlers fail (to try..except block): {{{ for receiver in self._live_receivers(_make_id(sender)): response = receiver(signal=self, sender=sender, **named) responses.append((receiver, response)) return responses }}} This is perfectly reasonable in most cases, but is problematic when dealing with top-level error handling, as this prevents the unhandled error from reaching handlers that just want to report it. This is very noticeable in cases where "something bad" happens to the database connection, as the first handler is always the database rollback handler, which only catches DatabaseError, which excludes a lot of errors that can and do crop up in production {{{ def _rollback_on_exception(**kwargs): from django.db import transaction for conn in connections: try: transaction.rollback_unless_managed(using=conn) except DatabaseError: pass }}} I think that it will be better to have the error signal dispatcher defer except raising until after all the handlers were called (or just swallow them all). Alternatively, a different signal for error reporting is possible, but I think that's a little confusing. Thoughts? schacki tal@sookasa.com signals errors databaseError 0 1 1 1 0 0
20757 2013-07-17 17:58:09 2015-05-28 15:39:48 2019-06-24 04:00:13.587624 Accepted assigned Core (URLs) New feature Normal master   A more Object-Oriented URLResolver Currently, the `RegexURLResolver` is populated using tuples. Because of that, code that tries to inspect the resolver will end up containg awkward indexing like this (semplified code for clarity's sake): {{{ def get_urlformat(urlname): """ Given a URL name, returns the URL as a string suitable for string.format. Example:: urlpatterns = patterns('', url(r'^extra/(?P<extra>\w+)/$', empty_view, name="named-url2"), ) >>> get_urlformat('named-url2') 'extra/%(extra)s/' """ resolver = get_resolver() return resolver.reverse_dict[urlname][0][0][0] }}} My proposal is to replace tuples with a tuple-like object whose elements can be accessed by using attribute names. That way, the above method could become: {{{ def get_urlformat(urlname): """ Given a URL name, returns the URL as a string suitable for string.format. Example:: urlpatterns = patterns('', url(r'^extra/(?P<extra>\w+)/$', empty_view, name="named-url2"), ) >>> get_urlformat('named-url2') 'extra/%(extra)s/' """ resolver = get_resolver() urlbit = resolver.reverse_dict[urlname].urlbits[0] return urlbit.format }}} I realize this is mostly aesthetic, and there could be performance implications since the URLResolver is probably the most hit codepath, so I appreciate every kind of opinion. The attached patch is still a draft, it definitely needs more extensive test coverage, but it's a start to get the idea. knbk fcurella   0 0 0 0 0 0
20824 2013-07-30 00:36:18 2014-05-16 10:29:26 2019-06-24 04:00:58.090230 Accepted assigned contrib.auth New feature Normal master   User Auth: A Complete Solution for Email Login Handling With Django 1.5 more support has been given to those Django developers who wish to have the Email as the username. However, I think we can continue to push onwards to a point where Django can realize a complete solution. By following the user login with username handling but porting it for email handling I think we can solve this issue once and for all. Currently I have been just going online and putting together my own solution, but my hope is with this ticket we can get everyone working together and a finalized solution merged into Django. tanderegg JJZolper User Auth Email Login Handling 0 1 1 0 1 0
20917 2013-08-14 12:18:02 2013-10-11 16:45:15 2019-06-24 04:01:57.991108 Accepted assigned Testing framework New feature Normal master   Change the password hashers when testing Disclaimer: I'm not completely sure this is a good idea as a default. The default password hasher is very secure, and very slow to create passwords. This is never an issue in production, but in testing it is *amazingly* slow. Most of the time using the unsalted MD5 hasher as `settings.PASSWORD_HASHERS[0]` has resulted in a six-fold increase in speed in my test suites. To be honest, I think we could use a "non-hashing" hasher in these cases. I'd like to change the "default" to insert this new non-hashing hasher as `settings.PASSWORD_HASHERS[0]` during `setup_test_environment()`. For anyone who does not know about this trick, their test suits will automatically speed up. Any tests expecting a certain hasher to have been used when creating would fail in a backwardsly incompatible manner. Any fixtures or similar with passwords created using another hasher would still be valid, but would then update to be the raw password on success. Of course, to validate these passwords the password text would need to be included in plain text in the test suite (See #20916 for an alternative solution to this issue). Other comparable setting changes done in this way include: turning off translations, using the console email backend, removing allowed_hosts checking, turning debug off. Am I mental, or is this a sensible optimisation? ashchristopher mjtamlyn   0 0 0 0 0 0
20960 2013-08-23 12:35:15 2014-12-21 22:18:52 2019-06-24 04:02:25.753331 Accepted assigned Database layer (models, ORM) New feature Normal master   DEFAULT_TABLESPACE should be part of DATABASES Currently DEFAULT_TABLESPACE is settings global. Of course, this short of thing is better set per-database. So, lets move DEFAULT_TABLESPACE and DEFAULT_INDEX_TABLESPACE to `DATABASES['some_alias']['OPTIONS']`. This also allows those databases that do not support tablespaces to throw errors if tablespace is defined in options. e0ne akaariai   0 0 0 0 0 0
20995 2013-08-29 14:18:08 2013-09-19 13:49:35 2019-06-24 04:02:48.119404 Accepted assigned Template system New feature Normal master   {% include %} uses get_template where it could select_template It'd be nice if the Include template tag was sensible enough to allow fallbacks by selecting the most appropriate template, as things like `render`/`render_to_response`/`render_to_string` do. It's tripped me up on more than one occasion, and it seems a trivial feature to support, from my limited testing. {{{ >>> from django.template import Template, Context >>> tmpl = Template('{% include var %}') >>> ctx = Context({'var':'admin/base.html'}) >>> ctx [{'var': 'admin/base.html'}] >>> tmpl.render(ctx) ... some HTML output ... >>> ctx.update({'var':['admin/base.html', 'admin/fail.html']}) {'var': ['admin/base.html', 'admin/fail.html']} >>> tmpl.render(ctx) Traceback (most recent call last): File "<console>", line 1, in <module> File "/path/django/template/base.py", line 140, in render return self._render(context) File "/path/django/template/base.py", line 134, in _render return self.nodelist.render(context) File "/path/django/template/base.py", line 823, in render bit = self.render_node(node, context) File "/path/django/template/debug.py", line 74, in render_node return node.render(context) File "/path/django/template/loader_tags.py", line 165, in render template = get_template(template_name) File "/path/django/template/loader.py", line 145, in get_template template, origin = find_template(template_name) File "/path/django/template/loader.py", line 138, in find_template raise TemplateDoesNotExist(name) TemplateDoesNotExist: ['admin/base.html', 'admin/fail.html'] }}} The 'fix' is to change [https://github.com/django/django/blob/5cdacbda034af928f5033c9afc7b50ee0b13f75c/django/template/loader_tags.py#L166 this line] from `get_template` to `select_template`, though this might now be slightly complicated by the recent changes in 5cdacbda034af928f5033c9afc7b50ee0b13f75c to allow for rendering of `Template` instances. Changing to `select_template` on 1.4 yields the results I'd expect: {{{ >>> from django.template import Template, Context >>> … amberdoctor Keryn Knight <django@kerynknight.com>   0 0 0 0 0 0
21039 2013-09-05 07:08:00 2019-03-12 15:12:16 2019-06-24 04:03:16.887595 Accepted assigned Migrations New feature Normal master   Support Postgres "CREATE INDEX CONCURRENTLY" in migrations When a migration creates a new index, it's sometimes preferable to use a concurrent index creation so it won't interfere with the operation of the DB: http://www.postgresql.org/docs/9.2/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY It would be nice to have an option to enable this in migrations. dtao FunkyBob   0 1 1 0 0 0
21076 2013-09-09 15:48:03 2018-02-21 14:31:57 2019-06-24 04:03:40.526331 Accepted assigned contrib.sessions New feature Normal master   Offer the ability to store a hash of session IDs rather than the ID itself We should offer the ability to store a hash each session ID in the session backend rather the the ID itself. This hash should be reasonably fast, because it'll be re-computed for every request. Currently, if an attacker gains access to the session storage backend — which may easier than gaining access to the database — he can login as anyone on the site. On a related note, we're inconsistent about whether or not we sign entries in the session backends. Some do, some don't. If we're hashing session keys by default, we should probably also sign everything by default. Both of these things need an off-switch. There are a fair number of apps that rely on raw sessionids to provide cross-framework compatibility. chris-griffin timo   0 1 1 0 0 0

Next page

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options:

CREATE TABLE "tickets_full" (
        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
    )
Powered by Datasette · Query took 3113.522ms