tickets_full

29,846 rows sorted by resolution

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
373 2005-08-19 18:15:29 2019-03-08 06:13:25 2019-06-24 00:19:14.700693 Accepted new Database layer (models, ORM) New feature Normal master   Add support for multiple-column primary keys In the interest of being able to use Django as an admin interface for ''any'' db schema, it really should support multiple column primary keys. Currently, you can "fake" it by declaring one of the keys to be primary in Django and adding a unique constraint to the model. You'd have to do without the auto-generated SQL that Django gives you, but if you're smart enough to know how and why to use multiple primary keys, you can probably write the schema by hand. Still, this is less than ideal. This is likely to be very difficult.   jacob database 0 0 0 0 0 0
470 2005-09-07 13:45:25 2019-01-15 20:46:04 2019-06-24 00:20:16.946582 Accepted new Database layer (models, ORM) New feature normal     Add Field.db_default for defining database defaults Apply this diff to django/core/mamagement.py Should work on any database. 75a76,77 > if f.default <> meta.fields.NOT_PROVIDED: > field_output.append("DEFAULT '%s'" % (f.default,)) nobody jws sql schema 0 0 0 0 0 0
897 2005-11-24 10:59:37 2018-09-14 14:49:53 2019-06-24 00:24:49.769430 Accepted new contrib.admin New feature Normal     Bi-Directional ManyToMany in Admin Allow amnytomany relationships to be defined both ways E.G {{{ class ItemType(meta.Model): name = meta.CharField(maxlength=100) descritpion = meta.CharField(maxlength=250) class PropertyType(meta.Model): name = meta.CharField(maxlength=100) itemtypes = meta.ManyToManyField(ItemType) }}} Excellent. When I make a new property type in the admin screens I get a mutiselect window for item types. What I want to be able to do however is have this work back the other way too so that whe I create a new item i can specify what property types apply. Thanks nobody anonymous   0 0 0 0 0 0
1028 2005-12-08 10:12:51 2018-04-14 16:09:16 2019-06-24 00:26:12.386082 Accepted new contrib.syndication New feature Normal master   High-level feed framework should make more feed elements available Currently, certain RSS and Atom elements can be populated only by making use of the "low-level" feed framework; this is particularly annoying in the case of certain common items such as the RSS category element. Ideally, all valid elements could be populated by use of the high-level framework, but in practice perhaps it would be best simply to determine which elements are needed in the most common use cases, and provide access to them. One possible implementation would be to extend the high-level framework's use of the template system; instead of providing templates for the title and description elements, perhaps the high-level framework could allow specification of a template for the complete item element. For example, a publisher who wished to list the categories to which items belong would be able to include this in the template for items in an RSS feed: {{{ {% for category in obj.get_category_list %} <category>{{ category }}</category> {% endfor %} }}}   ubernostrum djangocon 0 1 1 0 1 0
1873 2006-05-15 07:39:31 2017-04-24 20:20:56 2019-06-24 00:35:10.825344 Accepted new contrib.admin New feature Normal     Multi-select admin filter for RelatedFields Currently, you can only select one value from a RelatedField filter in de admin interface. This patch provides a multi-select filter, and an AND/OR switch for the values. The patch is at * http://www.million.nl/file/marc/django/multi-select-relatedfilterspec.2.diff Screenshots are at * http://www.million.nl/file/marc/django/multi-select-relatedfilterspec-and.gif * http://www.million.nl/file/marc/django/multi-select-relatedfilterspec-or.gif This replaces the current single-select filter, but could be used side-by-side if there was some mechanism to choose which filter to use for a particular field in the admin interface. Todo: test what happens with multiple RelatedField filters. nobody marc@million.nl nfa-changelist 0 1 1 0 1 1
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
2137 2006-06-11 23:51:21 2015-08-06 23:18:56 2019-06-24 00:37:58.762351 Accepted new contrib.admin New feature Normal     Add drag and drop ordering for inlines to set order_with_respect_to in admin interface Pre-MR, adding order_with_respect_to would present an ordering field in the admin interface (or a draggable list of inline objects if dom-drag.js was installed). Post M-R, neither appears. Not sure if this is a problem at the template level or at the model level. xian anonymous   0 0 0 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
2316 2006-07-09 18:20:22 2015-11-23 18:42:12 2019-06-24 00:39:53.262378 Accepted new contrib.contenttypes Bug Normal master   GenericRelation and get_or_create do not work together I think GenericRelation and get_or_create do not work together. Example: baz = Bar.objects.get_or_create(content_object=foo) You get an exception: Cannot resolve keyword 'content_object' into field adrian Rudolph GenericRelation 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
2539 2006-08-13 04:09:44 2013-06-13 11:36:09 2019-06-24 00:42:15.615980 Accepted new Template system New feature Normal     Custom tags and filters can be restricted by namespace How to use namespace? For example, {{{ {% load example %} {% example.testtag %} }}} And I think if the namespace can be optional is better. I don't know if it's useful, but sometimes I read others projects, and as I reading the template, I don't know which tag is in which file. So find the correct tag definition file is somewhat diffcult. If I can add namespace in the front of a custom tag name, it'll be easy to locate the source file. The maillist discussion thread is [http://groups.google.com/group/django-developers/browse_frm/thread/2b5a4a31f0349d27/b92c96a8dccc214b#b92c96a8dccc214b HERE]   limodou@gmail.com djangocon 0 1 1 1 1 0
2750 2006-09-17 23:32:23 2017-12-28 16:42:47 2019-06-24 00:44:30.198253 Accepted new Database layer (models, ORM) Bug Normal     ManyToManyField ignores 'default' option It doesn't seem possible to use the 'default' option to pre-select values in the admin site for a ManyToManyField. I've tried a string value, a list of strings, and even (following a recommendation from someone on #django) passing a list of the actual objects. It would be nice to either have this functionality added or to update the docs to reflect the fact that 'default' has no effect on ManyToManyFields. -Basil nobody bangcok_dangerus@hotmail.com   0 0 1 0 0 0
2901 2006-10-11 16:20:57 2016-01-22 00:16:56 2019-06-24 00:46:05.008632 Accepted new contrib.admin New feature Normal newforms-admin   Enable admin log display to be restricted to a specific site The admin log currently only provides way to show changes across all sites. For a project with multiple sites, it'd be very nice to be able to tell the admin log template tag to only show changes to objects that either aren't associated with any site, or associated with the current (or some other specific) site. This requires the `django_admin_log` table to be extended with a nullable `site_id` column, which would require appropriate upgrade instructions ala: {{{ BEGIN; ALTER TABLE django_admin_log ADD site_id integer NULL REFERENCES django_site (id); COMMIT; }}} The patch adds a method called `get_for_obj` to the `SiteManager` class, which attempts to find the site a given object is related with (either through a many-to-many, or a many-to-one relation). This function is reused in the `django.views.defaults.shortcut` function, which needs the same thing. nobody Christopher Lenz <cmlenz@gmx.de> nfa-someday 0 1 1 0 0 0
3254 2007-01-08 19:12:47 2016-05-07 22:13:56 2019-06-24 00:49:55.211080 Accepted new Database layer (models, ORM) New feature Normal     full text search support for postgres, oracle and mssql I didn't like it was missing. oracle, mssql : add a !FulltextIndex for the Fields postgresql: for each !FulltextField add a extra tsvector Field named like `"%(fieldname)_tsv"` Problems with sqlite fts: * they stated a match statement may only be used once in a query * it needs a very specific syntax to search multiple fields * i have no idea how to get that into the ORM   Ronny Pfannschmidt oracle fulltext search postgresql postgres mysql 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
3569 2007-02-25 04:06:58 2017-01-30 20:01:58 2019-06-24 00:53:13.944107 Accepted new contrib.syndication New feature Normal master   extend Atom feed support for other fields At present, Atom feed support is limited to a small number of fields and it is difficult to do things like generate full-content feeds. I'm offering to improve Atom feed support by implementing the full range of RFC 4287 elements. nobody jtauber@jtauber.com   0 0 0 0 0 0
4140 2007-04-24 08:51:38 2015-11-24 19:16:43 2019-06-24 00:59:12.943945 Accepted new Core (Management commands) Bug Normal master   oracle: manage.py syncdb fails with ORA-06552 when a fieldname is a keyword calling "manage.py syncdb log" with my log model on an empty Oracle database yields the following exception {{{ Traceback (most recent call last): File "./manage.py", line 11, in ? execute_manager(settings) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1730, in execute_manager execute_from_command_line(action_mapping, argv) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 1627, in execute_from_command_line action_mapping[action](int(options.verbosity), options.interactive) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/core/management.py", line 573, in syncdb cursor.execute(statement) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/db/backends/util.py", line 13, in execute return self.cursor.execute(sql, params) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/django/db/backends/oracle/base.py", line 104, in execute return Database.Cursor.execute(self, query, params) cx_Oracle.DatabaseError: ORA-06552: PL/SQL: Compilation unit analysis terminated ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed }}} the model myapp/log/models.py is simple and causes no problem in MySQL, I attached it to this ticket. a subsequent, second run of manage py syncdb goes without error.   frank.hoffsummer@gmail.com oracle Oracle 0 0 0 0 0 0
4147 2007-04-25 00:37:53 2013-05-19 23:37:59 2019-06-24 00:59:17.380565 Accepted new Internationalization New feature Normal master   Add some i18n hooks to DateFormat Django's handling of i18n is fairly good, but one major point that it doesn't handle well (together with almost everything else out there) is the formatting of dates. The most obvious example is the display of the month names. While in English there is only one case of nouns, in many other european languages there are more, which have different spellings. For example, in Greek, in order to be able to diplay full-word months and capture all possible sentence formats, one needs three cases: 1. The subjective case (eg. en: January, 2007 - el: '''Ιανουάριος''', 2007) 2. The posessive case (eg. en: 23th of January - el: 23η '''Ιανουαρίου''') 3. The objective case (eg. en: Entries posted on January - el: Δημοσιεύσεις που έγιναν τον '''Ιανουάριο''') I'm sure this is common in most european languages, but I'm not an expert; Please everybody comment on this. To implement this in django, I suggest the following: * Add MONTHS_POS, MONTHS_OBJ to django.utils.dates. This should read "of January" and "on January" in english . * Add a custom extension in django.utils.dateformat: Q for MONTHS_POS, V for MONTHS_OBJ. Any available letter should do. That's all. There is a=still an issue about the format 'S' that adds the ordinals (1st, 2nd etc) but I don't know how other languages deal with this. I can submit a patch for this... garcia_marc orestis dates month 0 0 0 0 0 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
4848 2007-07-11 17:59:05 2018-10-30 15:48:06 2019-06-24 01:06:46.488200 Accepted new contrib.admin New feature Normal newforms-admin   Allow inline fields to be "mixed in" with the models' own fields In newforms-admin, it would be quite helpful to be able to specify both a models' fields and its inline models' fields in the fields tuple of the options class. This would allow inline model fields to be "mixed in" with the models' own fields on the model's admin page. There are many situations where this would be preferable to the current situation -- always having inline model fields rendered below the models' own fields. I suggested this feature in the Django-developers group, and Adrian suggested that I open a ticket. http://groups.google.com/group/django-developers/browse_thread/thread/c54d026eb46ad375/93bebf102281bb41#93bebf102281bb41 nobody leifbyron nfa-someday newforms-admin inline models fields 0 0 0 0 0 0
5147 2007-08-13 12:39:55 2013-11-20 16:51:19 2019-06-24 01:10:00.294823 Accepted new Internationalization Bug Normal master   Translation inconsistency for Hungarian language (entry - entries) I'm building a site right now for a Hungarian customer, so I had to revise the Hungarian translation, and also review the UI bits. There is a small inconsistency I've found, which is pretty important for the Hungarian language (I don't know if this is an issue for other languages, too). So there is a verbose_name and a verbose_name_plural field in the Meta class of a model. The verbose_name_plural field is used in two different contexts: once you can see it in the admin homepage (let's say "Entries" - the same applies to the permissions list), and you see it on the listing page ("2 entries"). The problem is that these two words are the same in English, but not in Hungarian. Remaining at our example: the homepage should say "Bejegyzések" (plural form), and the listing should say "2 bejegyzés" (we don't use the plural form after counts). I hope you can fix the issue. A possible fix: use the verbose_name_plural on the listing page, and introduce a descriptive_name (or something similar) field for the admin index/permissions list.   Szilveszter Farkas <szilveszter.farkas@gmail.com> i18n hu pl inconsistency i18n-nofix 0 0 0 0 0 0
5349 2007-09-06 11:53:12 2012-02-18 10:42:49 2019-06-24 01:12:23.979246 Accepted new contrib.syndication Cleanup/optimization Normal master   Shouldn't the item_enclosure_url automatically prefixed with the current site? I'd recommend to add a call to add_domain() to the enclosure URL because other URLs are also automatically extended with the site's URL. I've included the patch. nobody anonymous   0 1 0 1 1 0
5372 2007-09-09 21:36:10 2015-01-26 16:46:06 2019-06-24 01:12:38.745371 Accepted new contrib.admin Cleanup/optimization Normal newforms-admin   Cache inline ForeignKey options   nobody anonymous nfa-someday newforms, admin, inlines 0 1 0 1 1 0
5518 2007-09-17 01:01:45 2013-03-22 19:25:51 2019-06-24 01:14:17.054878 Accepted new Internationalization Cleanup/optimization Normal newforms-admin   Capitalized verbose names for models There is a difference between models and forms, now the preferred format is: {{{ #!python class Contact(models.Model): email = models.CharField(verbose_name=_('email')) class ContactForm(forms.Form): email = forms.CharField(label=_('Email')) }}} Why is once 'email' and once 'Email'? I think it is quite inconsistent. But it is specially bad for translators. Example: I have a model with ten fields. I use form_for_model and form_for_instance. I realize that I need a form with seven fields from model and some new fields. So I have to translate the fields again - gettext doesn't know that 'email' is similar to 'Email'. I think it should be possible (not necessary) to use capitalized verbose names in models. It means to uncapitalized some words in admin - but it is possible, I do it in my personal branch. I thought that this kind of change should be sent to django-developers mailing list first. But there was no answer so there is a ticket. Ticket #5426 is precondition for it. I would like to create patch - if you think that it can be applied. nobody Petr Marhoun <petr.marhoun@gmail.com> admin, verbose_name, nfa-someday i18n-nofix 0 0 0 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
5745 2007-10-12 21:51:23 2015-10-24 17:06:07 2019-06-24 01:16:44.080911 Accepted new Database layer (models, ORM) New feature Normal master   MySQL Collations/Charsets and Engines Django should really have a DATABASE_CHARSET / DATABASE_COLLATION setting in the settings.py as well as a setting for the mysql database engine. It's stunning that unittests can enforce a database collation but tables not. Also an argument in the Meta section of models that allows to define the collation, charset and engine would be an important thing to have. I know that there are workarounds for those limitations but they have all disadvantages. nobody Armin Ronacher mysql 0 0 0 0 0 0
5793 2007-10-22 11:41:50 2019-03-13 10:10:22 2019-06-24 01:17:15.039635 Accepted new Database layer (models, ORM) New feature Normal master   Allow custom attributes in Meta classes In some cass it is useful to be able to store meta information on models inside the model class. In Django the Meta subclass is used to achieve this. Trying to add a custom attribute to a model's Meta inner class results in an exception though, thrown from django.db.models.options, which does indeed check any valid attribute names and raises an exception when unknown names are found. Is there any reason for this somewhat strange behaviour, not to allow a developer to add non-standard meta information to a model class (which can later on be used in eg view code)? Thanks! nobody eikke@eikke.com   0 0 0 0 0 0
5797 2007-10-22 21:15:11 2018-05-21 15:10:32 2019-06-24 01:17:17.679283 Accepted new HTTP handling Bug Normal master   decorator_from_middleware can cause middleware hooks to run out of correct order. cache_page, gzip_page, and conditional_page all use decorator_from_middleware. decorator_from_middleware wraps the view function to simulate middleware being run on a per-view basis. Here's the interesting bit: {{{ def _wrapped_view(request, *args, **kwargs): if hasattr(middleware, 'process_request'): result = middleware.process_request(request) if result is not None: return result if hasattr(middleware, 'process_view'): result = middleware.process_view(request, view_func, *args, **kwargs) if result is not None: return result try: response = view_func(request, *args, **kwargs) except Exception, e: if hasattr(middleware, 'process_exception'): result = middleware.process_exception(request, e) if result is not None: return result raise if hasattr(middleware, 'process_response'): result = middleware.process_response(request, response) if result is not None: return result return response }}} The problem is that middleware's order is important. Suppose two middleware decorators, A and B, are applied to the same view. The normal flow of middleware processing would be: A.process_request, B.process_request, A.process_view, B.process_view, view, B.process_response, A.process_response. The flow of the *decorated execution* is this: A.process_request, A.process_view, B.process_request, B.process_view, view, B.process_response, A.process_response. This is not yet a real-world issue as far as I know, but seems to be a lurking problem. I think the only reason it hasn't surfaced is that view decorators are fairly uncommon. I don't see a simple way to fix this.   jdunck cache middleware decorator gzip conditional http 0 1 1 0 0 0
5815 2007-10-25 05:20:57 2013-02-24 18:14:49 2019-06-24 01:17:29.262061 Accepted new Core (Cache system) New feature Normal master   Adds per-view cache refreshing (clearing) This patch adds the possibility to clear(refresh) cached data per view. SmileyChris sugested it would be good to add another key to the cached keys where we could keep track of all the different cache_page_key hashes, so we that can delete those then. It is possible to clear the cache for an specific view, to achieve that, you should tell your view's url path (and optionally, a key_prefix) to ``clear_cache_for_path(path, key_prefix=None)``. {{{ from django.utils.cache import clear_cache_for_path # clear the all cached data for path '/blog/posts/2/' clear_cache_for_path('/blog/posts/2/') }}} Note that it will delete every page cached from matching this path, ``Vary`` headers doesn't matter. NOTE: Thanks SmileyChris for your help and supervision with this. nobody k0001 cache refresh clear 0 1 1 1 0 0
5865 2007-11-03 01:52:35 2013-03-22 19:25:51 2019-06-24 01:18:01.474293 Accepted new Template system New feature Normal master   cycle template tag should accept a single argument When passed a single argument, the cycle tag should treat it as an iterable to cycle through. For example, with the context: {{{ #!python {'colors': ['red', 'blue', 'green']} }}} you should be able to have a template like: {{{ #!xml {% for row in mydata %} <tr class="{% cycle colors %}">...</tr> {% endfor %} }}} that would output: {{{ #!xml <tr class="red">...</tr> <tr class="blue">...</tr> <tr class="green">...</tr> <tr class="red">...</tr> ... }}} munhitsu gwilson   0 1 1 1 1 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
5929 2007-11-12 23:00:59 2018-11-04 13:12:29 2019-06-24 01:18:42.968709 Accepted new Database layer (models, ORM) New feature Normal master   Allow Fields to use multiple db columns (complex datatypes) Currently it seems that it is not possible to have complex db filds. For example: [https://dev.leipzig.freifunk.net/trac/browser/ffsomething/branches/generic/apps/management/models.py Implementation of a IP model] which actually should be a field type not a model. The implementation is not clean, because foreign key lookups for example do not work. The model maps for example: {{{ NetworkAddress.objects.filter(ip__in="192.168.0.10/16") }}} into a complex query for a ip resisting in a network range. Due the fact that model fields can only map to one db column, many complex data types can't be implemented. For example a ipv6 ip address which is a 128 bit value can't be handled by most db implementations of integer fields, so it has to be expanded to multiple columns plus a additional netmask column. Using varchar doesn't work because there is no way to search for network ranges or IPs in ranges, etc... I think a field should be able to implement lookup mappings which can be overridden to implement complex datatypes as well as use multiple db fields.   poelzi   0 0 0 0 0 0
6135 2007-12-05 16:04:43 2011-08-30 13:44:45 2019-06-24 01:20:56.446166 Accepted new Template system New feature Normal master   Introduce a short-cut for template filters that has needs_autoescape = True After the autoescaping was introduced I had to rewrite all filters to comform new requirements: put is_safe=True and needs_autoescape=True where needed. [[BR]] I have written about 25 filters that have needs_autoescape=True and absolutely of them contained contained the same strings {{{ def filter(text, autoescape=None): if autoescape: esc = conditional_escape else: esc = lambda x: x text = esc(text) # Then goes the part which is different for all filters # # return mark_safe(result) }}} I have checked the filters in django. All the same. I think it is way to much of writting. I propose to split property needs_autoescape = True on two properties:[[BR]] needs_manual_autoescape = True, then Do all the stuff above, manually.[[BR]] needs_autoescape = True, then all above steps will do template system for user. All this thinks can do a simple decorator as well. nobody anonymous autoescape 0 0 0 0 0 0
6148 2007-12-07 00:27:32 2018-06-25 19:59:55 2019-06-24 01:21:04.727061 Accepted new Database layer (models, ORM) New feature Normal master   Add generic support for database schemas There is frequently a need for Django to access data from tables in other schemas; this is especially true when building Django apps on top of legacy databases. Currently, the proposed solution is to add support for the {{{set search_path}}} command (#1051) via custom initialization sql (#6064). This is a good solution for PostgreSQL users, but it will not solve the problem in Oracle, which has no analogue of {{{set search_path}}}. Solving the problem in a generic way will require adding a per-app or per-model db_schema option, in order to issue SQL queries using the syntax {{{"schema_name"."table_name"}}}. This may also require more advanced introspection (at least in Oracle) to determine whether the table already exists when running management commands. A current workaround in Oracle is to manually create private synonyms inside the Django schema, referencing the necessary tables from other schemas. However, the management commands do not currently recognize the existence of synonyms via introspection. Additionally, the synonym solution may not be sufficiently generic in the long term. akaariai ikelly oracle postgresql mysql schemas 0 1 1 0 0 0
6343 2008-01-08 12:47:24 2011-09-11 01:56:58 2019-06-24 01:23:10.199627 Accepted new Database layer (models, ORM) Bug Normal master   % symbols not escaped in db_column column names when preparing queries Using {{{%}}} in database column names (specified using {{{db_column}}}) causes the database wrapper to fail when preparing queries. This is because the {{{%}}} symbol is not properly quoted (as {{{%%}}}), and conflicts with the usage of {{{%s}}} for passing parameters to queries. I am attaching a patch for the MySQL backend where I encountered the issue; I'm not sure if other backends exhibit this bug because it presumably depends both on whether the database's native capability to support {{{%}}} characters in column names, and on the [http://www.python.org/dev/peps/pep-0249/ Python DB-API] {{{paramstyle}}}. nobody Daniel Pope <dan@mauveinternet.co.uk>   0 1 0 1 0 0
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
6396 2008-01-16 19:33:17 2017-06-02 13:28:16 2019-06-24 01:23:44.942074 Accepted new contrib.admin Cleanup/optimization Normal master   Remove customization-unfriendly admin template tags The admin interface makes use of various template tags that are opaque, and make customization difficult. An example from `admin/change_list.html`: {{{ {% block result_list %}{% result_list cl %}{% endblock %} }}} This calls an `inclusion_tag` called `result_list` that is used exactly once in the admin (i.e., here); that `inclusion_tag` drops in some extra context variables before rendering `admin/change_list_results.html`. This doesn't work with the common `[app_label]/[object_name]/template.html` magic, since `inclusion_tag` sets the template names upon registration. If there's a good reason for using a template tag here, I'm not seeing it. `:)` The attached patch pulls the template code from `change_list_results.html` into `change_list.html`, and updates the latter's context with the extra context variables from the former. I intend to start yanking out similar uses of one-off template tags as I come across them in the admin, so I'll be dropping updated patches on this ticket as I go along. The rearranging of the functions `result_headers`, etc., is to avoid some circular import nastiness; I dropped them after `ChangeList`, which seems to make the most sense. nobody korpios nfa-someday 0 1 1 0 0 0
6489 2008-01-28 16:17:07 2019-01-09 21:41:29 2019-06-24 01:24:46.084343 Someday/Maybe new contrib.admin New feature Normal master   Add selected and enabled_from for JS calendar Add two parameters to the JS calendar class: highlighting a selected date, and disabling dates before a specified one. nobody Bastian Kleineidam <calvin@debian.org>   0 1 1 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
6870 2008-03-24 17:10:26 2018-11-29 18:53:54 2019-06-24 01:28:57.341881 Accepted new Database layer (models, ORM) Bug Normal master   pre_delete should be sent before collecting ForeignKey relationships If you have: {{{ #!python class MyModel(Model): user = ForeignKey(User, related_name='my_models', null=True) }}} You can't use a pre_delete signal to set user.my_models.clear() because the check for the related models is done before the signal is sent. It would be great if that were done after sending the signal. nobody wkornewald pre_delete signals related 0 1 1 0 1 0
6933 2008-03-31 21:52:58 2019-03-01 13:05:01 2019-06-24 01:29:38.142783 Accepted new contrib.admin New feature Normal newforms-admin   You cannot search with spaces if search_fields is declared with "^" That is. When search_fields is declared to "starts with" you cannot perform queries with spaces. File contrib/admin/views/main.py; Line 326: {{{ for bit in self.query.split(): or_queries = [models.Q(**{construct_search(field_name): bit}) for field_name in self.search_fields] other_qs = QuerySet(self.model) (...) qs = qs & other_qs }}} So, if for example i'm looking for "Hey dud" query will be: {{{ qs.filter(field__startswith="Hey") & qs.filter(field__startswith("dud")) }}} diafour Martín Conte Mac Donell <Reflejo@gmail.com> nfa-someday yandex-sprint ep2008 0 1 0 1 1 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
7018 2008-04-14 15:57:59 2016-02-06 20:31:12 2019-06-24 01:30:34.463830 Accepted new Forms New feature Normal master   Make ModelForm multiple inheritance possible If I have two ModelForm: {{{ class AForm(ModelForm): class Meta: model = A class BForm(ModelForm): class Meta: model = B class CForm(AForm, BForm): pass }}} This doesn't work because of the code: {{{ declared_fields = get_declared_fields(bases, attrs, False) }}} in ModelFormMetaclass. I can to this to make it work: {{{ # Because ModelFormMetaclass will call get_declared_fields method with # with_base_fields=False, we modify it with True. from django.newforms import models as nmodels gdf = nmodels.get_declared_fields nmodels.get_declared_fields = \ lambda bases, attrs, with_base_fields: gdf(bases, attrs, True) }}} But it will be nice if this behavior is default behavior. Thanks. nobody bear330   0 0 0 0 0 0
7497 2008-06-18 18:03:33 2013-11-28 19:43:50 2019-06-24 01:35:43.816360 Accepted new contrib.admin New feature Normal master   AppAdmin class for customizing app listing in admin index See http://code.djangoproject.com/wiki/DjangoSpecifications/NfAdmin/FlexibleAppHandling for details. This '''supplements''' the `app` directive. As discussed with `brosner` and `jkocherhans` in #django-dev: {{{ <brosner> it looks reasonable, but haven't spent much time thinking about it <jkocherhans> mrts: I think this is clearly backwards incompatible with the current nfa api and has to go in pre 1.0 if it goes in at all <jkocherhans> I'm a big -1 on the order attribute and -0 on models (maybe just a different syntax), but the other stuff seems reasonable <mrts> jkocherhans: what's wrong with ordering? <jkocherhans> it just feels like the wrong place to specify it <jkocherhans> it's a global issue, and an issue any particular app should handle <mrts> my use case: I have a lot of functionality exposed to somewhat dumb users <mrts> and they have trouble finding the right bits in the admin interface ordering is only used in context of admin index I would like to put the important apps to top and collapse the rest <jkocherhans> exactly. what should 3rd party apps put there? therein lies my objection. <mrts> well, I'd say decouple admin from models (as nfa already does) and don't specify any admin options at all -- users are free to customize things with AppAdmin <jkocherhans> I guess not if using a AppAdmin class is optional. I was originally thinking it would replace model registration with an admin site. <mrts> jkocherhans: yeah, that's what I kinda meant... it looks more coherent this way jkocherhans: and it may solve some of the issues register() currently has <jkocherhans> mrts: I'm gonna have to let it sit for awhile. I'm trying to think of what else an AdminApp class would do besides being a coathanger for a few attributes, nothing is coming to mind. <mrts> jkocherhans: but jezdez has a point -- it would also provide easy bridging for app instances }}} Example syntax follows. {{{ class BarModelAdmin(admin.ModelAdmin): description = 'A bar is a bar is a bar' ... … nobody mrts   0 0 0 0 0 0
7537 2008-06-25 15:17:46 2013-03-14 20:26:27 2019-06-24 01:36:09.468112 Accepted new Core (URLs) New feature Normal master   Make RegexURLResolver easier to subclass Referencing [http://groups.google.com/group/django-developers/browse_thread/thread/e16bcd24f9e27062 the django-developers discussion], here's some simple patches to make the URL resolver easier to customize. First is a nearly minimal patch to convert the url_patterns property to an accessor, get_url_patterns, to ease subclassing, and make the other methods use that consistently instead of duplicating its functionality. With only this patch you can make your own URL resolver without duplicating code, but it's still not clean. The second patch cleans up the situation by abstracting the core functionality of a regex URL resolver into {{{BaseRegexURLResolver}}}. The third patch is an example of how newforms-admin might use this for URL dispatching. I don't have a deep understanding about what's going on, so treat what I did just as an example. Perhaps the cleanest way to accomplish some of what the old ad-hoc resolver did is to override {{{resolve}}}, and if {{{super().resolve}}} returns None, do the ad-hoc stuff. You'd use a custom resolver in your urlconf like this: {{{ urlpatterns += [AdminSite(r'^admin/')] }}} i.e., like a normal {{{include}}} (at least, what that {{{include}}} looks like under the hood). The newforms-admin change would be backwards-incompatible, so if people think it's a good idea, it should get a separate ticket. About the accessor: properties don't inherit well. Could add a {{{url_patterns = property(lambda self: self.get_url_patterns())}}} if that's not too ugly. nobody kcarnold url, urlpatterns, resolver 0 1 0 1 0 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
7623 2008-07-03 15:23:26 2019-03-20 09:59:22 2019-06-24 01:37:04.731800 Accepted new Database layer (models, ORM) New feature Normal master   Multi-table inheritance: Add the ability create child instance from existing parent As it exists now, multi-table inheritance does not allow for the creation of a child model instance that inherits from an existing parent model instance. For example: Parent Class- {{{ class Place(models.Model): name = models.CharField(max_length=50) address = models.TextField(max_length=150) }}} Child Classes- {{{ class Restaurant(Place): place = models.OneToOneField(Place, parent_link=True) cuisine = models.CharField(max_length=75) rating = models.IntegerField() class Bar(Place): parent = models.OneToOneField(Place, parent_link=True) happy_hour = models.BooleanField() beers_on_tap = models.ManyToManyField("Beers", null=True, blank=True) }}} Sample Use-case- When the system is first deployed, a restaurant instance is created. Later, the restaurant adds a bar to increase revenue, and we now want to create a Bar model instance for the parent Place for the restaurant. I would propose the following interface for doing so: {{{ parentPlace = Restaurant.objects.get(name__iexact="Bob's Place").parent barInstance = Bar(parent=parentPlace, happy_hour=True) }}} However, if you attempt to create an instance in this manner now, you receive a DatabaseIntegrityError, saying that a Place object with that id already exists.   brooks.travis@gmail.com model-inheritance, multi-table-inheritance 0 1 1 1 0 0
7664 2008-07-07 20:02:01 2013-07-12 15:30:15 2019-06-24 01:37:31.221474 Accepted new Forms New feature Normal master   MultiWidget to support named sub widgets It would be nice if MultiWidget would support names for its sub widgets. Currently if {{{ widgets = (TextInput(attrs=attrs), TextInput(attrs=attrs)) }}} you get something like this: {{{ <input type="text" name="name_0"><input type="text" name="name_1"> }}} Which is a bit ugly. I would like to see something like one of these: {{{ widgets = (TextInput(attrs=attrs), TextInput(attrs=attrs)) names = ('date', 'time') }}} or {{{ widgets = (('date', TextInput(attrs=attrs)), ('time', TextInput(attrs=attrs))) }}} These would render to something like this: {{{ <input type="text" name="name_date"><input type="text" name="name_time"> }}} nobody CollinAnderson multiwidget 0 1 0 0 1 0
7732 2008-07-12 14:30:08 2019-05-15 15:41:02 2019-06-24 01:38:14.388991 Accepted new Database layer (models, ORM) New feature Normal master   Oracle Backend with SessionPool This new backend uses Oracle session pool to improve database performance in threaded environment. Overall speedup for large amounts of small queries is 2-3 times.   halturin yandex-sprint oracle session pool 0 1 1 1 1 0
7835 2008-07-19 14:41:05 2019-06-03 04:20:49 2019-06-24 01:39:20.481426 Accepted new Testing framework New feature Normal master   Provide the ability for model definitions that are only availably during testing A current limitation of the unit test framework is that there is no capacity to define 'test models' - that is, models that are only required for the purposes of testing. A regular installation would not know anything about these models - only a test database would have access to them. There are several existing applications that have a need for this capability: For example: * contrib.admin: you can't test the way admin handles models without some models to handle. * contrib.databrowse: you can't test the way the browser works without having models to browse * Django Evolution: you can't evolve models without having some models to evolve. The easiest way to work around this at present is to have a standalone test project which exercises the required functionality. However, these tests aren't integrated into the automated test suite, so they. Another option is to do some app_cache munging during the test - this works, but is very messy. Django should provide a way for model definitions to be defined as part of the test definition, synchronized as part of the test setup, populated and manipulated during test execution, and destroyed along with the test database. nobody russellm feature test models 0 0 0 0 0 0
8122 2008-08-05 15:15:18 2014-06-13 18:03:04 2019-06-24 01:42:33.522681 Accepted new contrib.sessions Cleanup/optimization Normal master   Better way of testing for cookies While trying to get the cookie test in the login form working again by default (see ticket #8061) I think I found a way to get rid of the {{{set_test_cookie()}}} / {{{test_cookie_worked()}}} dance. The attached patch makes the session middleware set an ''empty'' cookie if the session does not yet have any variables set. This makes it possible to check whether the browser accepts cookies without poluting the session store. You can check for cookies using {{{accepts_cookies()}}} method. The old methods are marked deprecated but still work. nobody jcassee   0 1 1 0 0 0
8165 2008-08-08 18:24:35 2016-12-01 18:41:21 2019-06-24 01:43:02.864245 Accepted new Forms New feature Normal master   When using can_order=True on formset, ordered_forms is not avaible when formset.is_valid() is false IMO ordered_forms attribute needs to be available even then the formset.is_valid() result to false in order to return the formset in order for re-inputting purpose nobody James Chua <james_027@yahoo.com> formsets 0 0 0 0 0 0
8264 2008-08-12 20:10:47 2013-03-14 22:04:05 2019-06-24 01:44:07.917403 Accepted new Core (URLs) New feature Normal master   Replace get_absolute_url with more sane alternative See http://code.djangoproject.com/wiki/ReplacingGetAbsoluteUrl simon simon   0 0 0 0 0 0
8307 2008-08-14 07:05:43 2014-02-23 14:12:53 2019-06-24 01:44:36.206379 Accepted new File uploads/storage Cleanup/optimization Normal master   ImageFile use of width_field and height_field is slow with remote storage backends im attaching a patch that could make it work jacob sebastian.serrano@gmail.com imagefile height width 0 1 0 0 1 0
8408 2008-08-19 07:09:11 2018-08-18 16:09:54 2019-06-24 01:45:42.507790 Accepted new contrib.admin New feature Normal master   Add a new meta option: don't do count(*) in admin Hello, everytime when I use Admin to view a table, the Admin count the rows in the table. if the database is mysql+innodb, this step is very slow, how about add an option in Meta to prevent this, such as {{{ #!python class A(models.Model): class Meta: do_not_count = True }}} thanks tchaumeny lidaobing   0 1 1 1 0 0
8467 2008-08-21 06:39:08 2016-09-23 14:51:33 2019-06-24 01:47:10.100765 Accepted new Database layer (models, ORM) New feature Normal master   For ManyToMany manager, we should convert objects being added or removed to the pk type if they are not. For example: {{{ class A(models.Model): name = models.CharField(blank=True) class B(models.Model): a = models.ManyToManyField(A) a = A(name='aaa') a.save() b = B() b.save() # This line works fine: b.a.add('1') # But this one will raise 'Duplicate entry' error: b.a.add('1') }}} This is caused by {{{ '1' }}} is not an integer, the duplication checking code in {{{ add() }}} fails when checking the string type {{{'1'}}}. The same problem is applied to the {{{ remove() }}} method. If we convert the objects to its pk type of the model, code will run correctly. And my patch is attached. nobody Wonlay Duplicate entry, add, remove, ManyToManyField 0 1 1 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
8760 2008-09-01 12:49:54 2018-04-04 20:35:23 2019-06-24 01:50:21.781123 Accepted new Forms Cleanup/optimization Normal master   forms.ModelMultipleChoiceField should use "invalid_list" as error message key The MultipleChoiceField uses "invalid_list", but ModelMultipleChoiceField uses "list" as the key for the similar error message. nobody durdinator forms 0 1 1 0 0 0
8912 2008-09-06 04:33:49 2016-11-16 15:03:54 2019-06-24 01:52:00.188867 Accepted new File uploads/storage New feature Normal 1.0   File storage and save/commit=False Background: I noticed this when playing with save_formset() on ModelAdmin in order to modify the data for a FileField on an inline model before it gets sent to S3 via a custom filestorage backend. In admin.py {{{ def save_formset(self, request, form, formset, change): instances = formset.save(commit=False) for instance in instances: if not instance.id: raise Exception('testing file creation') instance.save() formset.save_m2m() }}} Now, when saving a new inline instance which has a file field, the exception is raised before that instance gets save()'d. I kept noticing, however, that I would still get the full uploaded file with the proper name in my S3 account. So, I raised an exception in the _save() on my custom backend and walked it back to the formset.save(commit=False) call. It seems to me that the commit=False should keep file writes from happening; it doesn't. Looking in django/db/models/fields/files.py, the save() takes a save argument but doesn't use it when dealing with the save call to the storage backend. If the argument was passed along to the save on the storage backend, then it could decide whether or not to actually write the file.   shadfc   0 0 1 0 1 0
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
9025 2008-09-10 22:25:56 2018-09-20 14:10:14 2019-06-24 01:53:11.244960 Accepted new contrib.admin New feature Normal master   Nested Inline Support in Admin Currently, admin.TabularInline and admin.StackedInline do not support inlines themselves. This would allow nested inlines to happen.   pixelcort   0 1 1 0 0 1
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
9076 2008-09-13 20:27:26 2017-03-13 21:36:22 2019-06-24 01:53:43.469843 Accepted new Forms Bug Normal 1.0   Inline forms can result in a "Please correct the errors below." message with no errors listed. This error can reproduced with the poll app in the tutorial with a minor change. Remove the choice field from the Choice model (file attached). Edit a poll by adding two choices; enter any numbers in the votes fields. Any subsequent save will result in the "Please correct the errors below." message with no highlighted errors. The problem occurs in BaseModelFormSet._construct_form where an index access on the queryset is returning duplicate pks. This in turn leads to validation failing in BaseModelForm.validate_unique. The error occurs in 1.0 and the trunk, probably introduced around the time core=True was removed. nobody coady   0 0 0 0 0 0
9093 2008-09-15 19:02:59 2014-06-30 22:34:34 2019-06-24 01:53:54.369918 Accepted new Template system New feature Normal 1.0   Extend inclusion tag syntax to allow custom templates Currently, inclusion tags are not very reusable since they are bound to a template at registration time. For example, the only way to customize Djagno admin's `change_list_results.html` template is to ensure your template of the same name is found first. I propose extending the inclusion tag syntax so that all inclusion tags can be called like so: {% show_results poll using "custom/results.html" %} If the "using ..." part is omitted, the template specified during registration will be used. (The keyword decided upon, 'using' in this case, is not important.) The only problem: this could break existing apps that use the keyword ('using' in this case) as a variable name. But we can make this behavior well-defined. nobody exogen@gmail.com inclusion 0 1 1 0 0 0
9107 2008-09-16 18:06:39 2009-02-26 04:09:40 2019-06-24 01:54:03.772741 Accepted new contrib.admin New feature Normal master   URL arguments to set values of fields in admin don't work for inlines Though it works just fine to set the value of a field in the admin with URL arguments (i.e. adding '?title=foo' to your URL sets the value of the field 'title' to 'foo'), this doesn't work if the field you're trying to set is in an inline. In such a case the syntax would presumably be something along the lines of '?inlinemode_set-0-fieldname' if you were trying to set the value fo the first instance of the inline model. This, however, doesn't work nor does any other variation I was able to think of. nobody josh@dydxtech.com admin inline 0 0 0 0 0 0
9173 2008-09-22 14:07:21 2019-01-09 21:40:56 2019-06-24 01:54:46.366795 Someday/Maybe new Template system New feature Normal master   Conditional content of template blocks It will be very good if there is some possibility to mark sort of "conditional content" of the template blocks ({% block .. %}), that is the content that is displayed only if in a child template the block has some content. For instance, we have 2 templates: {{{ parent.html <table> <tr> <td>{% block firstcol %}{% endblock %}</td> <td>{% block secondcol %}{% endblock %}</td> {% block thirdcol %}<td>{% blockcontent %}</td>{% endblock %} </tr> </table> }}} {{{ child.html {% extends 'parent.html' %} {% block firstcol %} 1 {% endblock %} {% block firstcol %} 2 {% endblock %} }}} We should have such an output text: {{{ <table> <tr> <td> 1 </td> <td> 2 </td> </tr> </table> }}} but not the following: {{{ <table> <tr> <td> 1 </td> <td> 2 </td> <td></td> </tr> </table> }}} nobody while0pass   0 1 1 0 0 0
9198 2008-09-24 14:03:37 2017-01-07 00:16:20 2019-06-24 01:55:02.318448 Accepted new Template system Cleanup/optimization Normal 1.0   Make the {% include %} strip a trailing newline If I have a template {{{ # template1.html Line 1 Line 2 }}} And I include this template in other one using templatetag include: {{{ # template2.html {% include template1.html %} Line 3 }}} The output must be: {{{ # template2.html # template1.html Line 1 Line 2 Line 3 }}} But the actual output is: {{{ # template2.html # template1.html Line 1 Line 2 Line 3 }}} This behavior is particularly annoying when it renders a template including JSON. nobody versae   0 0 0 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
9318 2008-10-07 10:25:58 2017-04-28 21:18:33 2019-06-24 01:56:19.213221 Accepted new Core (Other) New feature Normal 1.0   "Virtual" behaviour for signal dispatcher and model inheritance In presence of model inheritance, we need to propagate signal not only to handlers, attached to the Child classes, but also to handlers, attached to the Parent class. Please, see unittests in the patch, for example of such model inheritance.   svetlyak40wt model inheritance, signals, dispatch, proxy, subclass 0 1 1 0 0 0
9338 2008-10-10 07:01:29 2011-01-31 12:13:49 2019-06-24 01:56:32.150899 Accepted new contrib.admin New feature Normal master   admin-interface: inline formset should have can_order=True when using order_with_respect_to when using order_with_respect_to, the inline formset should have can_order=True, but it hasn´t. this is important if one tries to hack the admin-interface, e.g. for implementing drag/drop-functionality with edit-inlines. nobody patrickk   0 1 1 0 0 0
9357 2008-10-13 17:05:06 2014-03-20 21:32:15 2019-06-24 01:56:44.201125 Accepted new Forms New feature Normal 1.0   Unable to subclass form Media class In essence, I'm simply trying to add a new media type to a number of custom widgets. However, I'm finding that I have to re-implement large parts of Media and MediaDefiningClass, and I even have to do the same on large parts of the Form as well. The main reason behind this is that everything is referencing 'Media()' explicitly, overriding my custom classes. nobody Tarken   0 0 0 0 0 0
9363 2008-10-14 15:13:30 2016-10-04 12:03:42 2019-06-24 01:56:47.963520 Accepted new Database layer (models, ORM) New feature Normal 1.0   Add a traceback to each query in CursorDebugWrapper I'm not a python wizard, so I'm just suspecting the following is possible: When you examine {{{connection.queries}}}, it would be great to write out the file and the line, from the Query comes from. Ok, one must define where the query created (the first time you say filter on a manager, the last time ...), but this should help greatly figuring out why certain queries are executed. nobody pihentagy debug , query 0 1 1 0 0 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
9433 2008-10-23 16:47:26 2013-05-04 20:56:18 2019-06-24 01:57:33.479803 Accepted new File uploads/storage Bug Normal master   File locking broken on AFP mounts File locking does not work on volumes mounted using AFP on Mac OS X 10.5 django/core/files/locks.py assumes that the presence of fcntl module implies a posix system and that for a posix system fcntl.lockf works for every file accessible on the file system. This is not the case on a Mac OS X box for files on a volume mounted using AFP: {{{ [taquet:~] iihm% uname -mprs Darwin 9.5.0 Power Macintosh powerpc [taquet:~] iihm% python Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:16) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import django >>> django.VERSION (1, 0, 'final') >>> from django.core.files import locks >>> f = open("/Volumes/Web/test.txt", "w") >>> locks.lock(f, locks.LOCK_EX) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Library/Python/2.5/site-packages/django/core/files/locks.py", line 57, in lock fcntl.lockf(fd(file), flags) IOError: [Errno 45] Operation not supported }}} A workaround is to revert [8675]. I know this is not acceptable since it fixes #8403, but it is still a fact that from a Mac OS X user perspective, [8675] introduce a regression. anonymous rndblnch   0 1 1 0 0 0
9435 2008-10-24 03:43:35 2016-12-29 19:14:22 2019-06-24 01:57:34.782314 Accepted new Core (Other) Bug Normal 1.0   Check out behaviour of wsgi backend with PATH_INFO being an empty string Transferring a side-issue from #3414 (comment 23 over there): Note: the WSGI spec allows PATH_INFO to be empty or missing; specifically: "This may be an empty string, if the request URL targets the application root and does NOT have a trailing slash." (emph. added) And WSGI servers are allowed to omit PATH_INFO (and various other variables) if they are an empty string. IIUC, this means that [8105] doesn't correctly handle the case where someone goes to "foo.com/django" (no trailing '/'), because it wrongly assumes that a missing PATH_INFO is a '/'. Per the WSGI spec, a missing PATH_INFO is in fact an empty string. That means that relative URLs at the root of a Django site would not work correctly under servers that omit an empty PATH_INFO. Whether the OP issue here is a configuration problem is irrelevant to this piece: it is perfectly legal for a WSGI server to omit PATH_INFO if it's an empty string, and its omission means that it's an EMPTY string, not a '/'. Conversely, if a WSGI server is ommitting PATH_INFO when PATH_INFO should be a "/" (i.e. the URL was "foo.com/django/" with a trailing "/"), then that server is seriously broken and should be fixed. (But I'm not seeing anything here that suggests this is actually the case.) Either way, however, the code that's defaulting a missing PATH_INFO to "/" appears to be quite wrong: either creating a bug or masking one somewhere else.   mtredinnick   0 1 1 0 0 0
9519 2008-11-04 19:53:07 2016-11-22 16:25:16 2019-06-24 01:58:28.725964 Accepted new Database layer (models, ORM) New feature Normal master   Add QuerySet.bulk_delete() that issues only a single SQL query Example: {{{ #!python from django.db import models class MyModel(models.Model): my_id = models.IntegerField(primary_key=True) col1 = models.IntegerField() col2 = models.CharField(max_length=1) col3 = models.TextField() class Meta: unique_together = ('my_id', 'col1', 'col2') # "Fake" a multi-part primary key # This works for creating all 3, as force_insert is used in create() MyModel.objects.create(my_id=1, col1=5, col2='a', col3='foo') MyModel.objects.create(my_id=1, col1=5, col2='b', col3='bar') MyModel.objects.create(my_id=1, col1=10, col2='a', col3='baz') MyModel.objects.filter(my_id=1, col1=5).delete() }}} This deletes all of the objects created above, since deletion is done only based on model._meta.pk. This is fine, except when you are using multi-part primary keys and emulating that pkey as suggested in #373. In my opinion, the delete operation should be executed with respect to the filter(), extra(), etc which were previously performed on the QuerySet. This is, in a way, a part of ticket #373, but I believe it can be viewed as a completely separate issue. In some cases, you do want to delete based on columns other than the primary key. Why build a list of all of those primary keys when you've already specified all of the qualifiers in a filter()? nobody Tarken database, queryset, delete 0 0 0 0 0 0
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
9631 2008-11-19 06:20:05 2019-01-09 22:07:55 2019-06-24 01:59:42.610508 Design decision needed new File uploads/storage Cleanup/optimization Normal 1.11   FieldFile assumes efficient Storage.size FieldFile's _get_size, like many of its methods, passes the operation on to its Storage object. However, in this case, assuming that a storage mechanism can easily discover the size of a file by name is rather rash. If the file is compressed, for instance, it may be necessary to decompress the entire file to determine the size. Remote storage could suffer from similar issues. Fortunately, FieldFile has a File object provided by the storage. The Storage derivative is responsible for returning a valid File object, which means it must be able to correctly report its size. By asking the File object for its size directly, we provide opportunities for caching so that a size request followed by a read operation need not trigger two independent retrievals of the data. nobody psagers file upload compression 0 1 1 0 0 0
9682 2008-11-24 18:51:32 2015-09-20 23:24:02 2019-06-24 02:00:15.527948 Someday/Maybe new Database layer (models, ORM) Bug Normal 1.0   icontains can be case-sensitive on MySQL Firstly, this is a known problem, see groups.google.com/group/django-users/browse_thread/thread/2936ad3387c4b369. Secondly, I disagree with the ‘You set the database collation and Django respects that’ approach shown there. For icontains and MySQL, Django generates ‘x LIKE '%y%'’. So, the programmer has told Django explicitly, ‘I want case-insensitive comparison’, and Django tells MySQL, ‘We want default comparison’. This is not field_icontains but rather some field_''usingdefaultsettings''contains. In fact, here’s how Django defines operators for the MySQL backend: {{{ operators = { 'exact': '= %s', 'iexact': 'LIKE %s', 'contains': 'LIKE BINARY %s', 'icontains': 'LIKE %s', 'regex': 'REGEXP BINARY %s', 'iregex': 'REGEXP %s', 'gt': '> %s', 'gte': '>= %s', 'lt': '< %s', 'lte': '<= %s', 'startswith': 'LIKE BINARY %s', 'endswith': 'LIKE BINARY %s', 'istartswith': 'LIKE %s', 'iendswith': 'LIKE %s', } }}} So, case-sensitivity is explicitly requested, while case-insensitivity is implied. The aforementioned thread says that ‘case-sensitive matching with the default utf_*_ci collations’ and overall making ‘things like that work regardless of collation’ is ‘really, really hard’. That sounds strange, because case-sensitive matching is no harder than a simple memcpy, it’s case-insensitive matching that is problematic. However, MySQL doesn’t seem to implement the Unicode collation trickery correctly. It thinks that 'ı' is LIKE 'i' and 'groß' is not LIKE 'GROSS'. (It does perform LOWER('COMMITTED' COLLATE utf8_turkish_ci) correctly, however.) What about altering the above table, making it 'COLLATE utf8_general_ci LIKE %s' for cases where the default collation isn’t case-insensitive? You’re right Unicode is quite hard to implement properly. However, for something_icontains the database does have to determine some collation, and if the default collation is case insensitive, som… nobody to.roma.from.djbug@qwertty.com   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
9757 2008-12-04 17:50:47 2013-06-05 20:40:36 2019-06-24 02:01:04.138998 Accepted new Template system Cleanup/optimization Normal 1.0   Make IfNode a baseclass for other if nodes to subclass Right now any other `if` type node that wants to exist needs to re-implement all the rendering logic of the if tag, in addition to the conditional it wants to use. To simplify this we could make IfNode do all of the logic to determine whether it evalueates true or not into a seperate method, and then subclasses could just overide the __init__ and that mehtod. nobody Alex   0 0 0 0 0 0
9762 2008-12-05 21:54:11 2012-12-14 00:07:58 2019-06-24 02:01:07.375271 Accepted new Template system Bug Normal master   template filter |date:"r" not valid RFC 2822 formatted when LANGUAGE_CODE different than english Documentation says template filter date with argument 'r' returns a valid RFC 2822 formatted date. But setting a LANGUAGE_CODE different than english makes the date returned not valid because the day abbreviation is translated into the LANGUAGE_CODE language. Perhaps there should be two arguments for this: one for valid RFC 2822 dates and another one for the actual 'r' argument (RFC 2822 translated). kgrandis amele date template filter 0 1 1 0 0 0
9976 2009-01-06 14:55:07 2016-04-22 05:13:18 2019-06-24 02:03:26.006432 Accepted new contrib.admin New feature Normal master   Generic Foreign Keys should have a nice widget(ala raw_id) It would be nice if generic foreign keys could have a nice widget for the admin, right now they aren't very usable.   Alex design_ux raw_id_fields 0 1 1 0 0 1
9990 2009-01-08 11:59:28 2012-09-12 01:36:12 2019-06-24 02:03:35.181846 Accepted new Core (Management commands) Bug Normal master   Management shell autocomplete breaks PYTHONSTARTUP autocomplete * create a PYTHONSTARTUP file setting up autocompletion with readline * run manage.py shell * neither the PYTHONSTARTUP's autocomplete nor the shell command default's one work (tested on ubuntu linux and gentoo linux with Python 2.5.x) The problem seems to come from the fact that the shell command install autocompletion _before_ executing the PYTHONSTARTUP. The attached patch reverse the order of operations, and check readline.get_completer before trying to install it's own completer. Worksforme, *but* requires that the PYTHONSTARTUP script pass globals() to the completer (else we'd be back to #5082). It also just ignore the use_plain flag except to tell wether to use IPython or the default shell(cf #5936). There's perhaps something better to do to get the whole thing right (perhaps passing a 'DJANGO_SHELL=1') option to execfile ???), but this is a design decision so I leave it to you guys. nobody bruno management shell command 0 1 1 0 0 0
10060 2009-01-18 06:44:38 2019-06-17 08:09:34 2019-06-24 02:04:20.795771 Accepted new Database layer (models, ORM) Bug Normal master   Multiple table annotation failure Annotating across multiple tables results in wrong answers. i.e. {{{ In [110]: total = Branch.objects.all().annotate(total=Sum('center__client__loan__amount')) In [111]: total[0].total Out[111]: 3433000 In [112]: repaid = Branch.objects.all().annotate(repaid=Sum('center__client__loan__payment_schedule__payments__principal')) In [113]: repaid[0].repaid Out[113]: 1976320.0 In [114]: both = Branch.objects.all().annotate(total=Sum('center__client__loan__amount'),repaid=Sum('center__client__loan__payment_schedule__payments__principal')) In [115]: both[0].repaid Out[115]: 1976320.0 In [116]: both[0].total Out[116]: 98816000 ^^^^^^^^^^^ }}} Compare the output of total in 116 vs. 111 (the correct answer).   svsharma@intellecap.net   0 0 0 0 0 0
10070 2009-01-19 19:41:46 2019-04-15 23:50:28 2019-06-24 02:04:27.264183 Accepted new Database layer (models, ORM) Bug Normal master   Named parameters not working on raw sql queries with sqlite The following code shows the problem when using sqlite: {{{ $ python manage.py shell Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from django.db import connection >>> c = connection.cursor() >>> c.execute("select name from inventory_host where id=%(id)s",{'id':'1'}) Traceback (most recent call last): File "<console>", line 1, in <module> File "/usr/lib/python2.5/site-packages/django/db/backends/util.py", line 19, in execute return self.cursor.execute(sql, params) File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 167, in execute query = self.convert_query(query, len(params)) File "/usr/lib/python2.5/site-packages/django/db/backends/sqlite3/base.py", line 179, in convert_query return query % tuple("?" * num_params) TypeError: format requires a mapping >>> >>> import django >>> django.VERSION (1, 0, 2, 'final', 0) }}} {{{ $ sqlite3 --version 3.5.9 }}} When using Mysql or Postgres, that works (not tested by me, but by others on django-users). nobody msurdi   0 1 0 1 0 0
10088 2009-01-21 22:12:38 2018-09-03 19:49:57 2019-06-24 02:04:39.244170 Accepted new Database layer (models, ORM) New feature Normal 1.0   for_share() as well as for_update() addition to Model.QuerySet Ticket #2705 is a very good idea I think. PostgreSQL supports SELECT ... FOR SHARE locking mode, which is basically the same as FOR UPDATE mode but it does not conflicts with other transaction having obtained FOR SHARE mode for the row. (see http://www.postgresql.org/docs/8.3/static/sql-select.html#SQL-FOR-UPDATE-SHARE) It very useful if you need to be sure that your selected rows are not modified since you have read them (which is true for almost every complex transaction). I am not sure if MySQL has this feature but in PostgreSQL it first-class citizen so I believe for_share() and for_update() has to be implemented together.   epandurski   0 0 0 0 0 0
10191 2009-02-04 10:22:41 2014-06-06 00:01:16 2019-06-24 02:05:46.537581 Accepted new contrib.admin New feature Normal master   Fix / Add support for radiobuttons after adding item with popup in Django Admin The following patch adds support for dynamically adding radiobutton items to the admin page. Without this patch the newly added item through the popup menu does not get added to the page and the user must reload the page before being able to select the new item. The patch adds an extra case to dismissAddAnotherPopup in RelatedObjectsLookup.js which creates and appends the necessary html to the list of radiobuttons on the page. Tested with django.contrib.redirects and a slightly modified version of django-podcast. Works (for me) on Firefox, IE and Opera. bodiddlie trbs admin, radio, radiolist, dismissAddAnotherPopup, popup 0 1 1 1 0 1
10227 2009-02-10 17:40:21 2019-03-20 16:05:30 2019-06-24 02:06:09.824684 Accepted new Database layer (models, ORM) New feature Normal master   Support a related_default on OneToOne fields EDIT: scroll to comment 13 to see what this ticket is about. Referencing a {{{OneToOneField}}} with {{{null=True}}} (i.e. it's optional) when there is no value set will return {{{None}}}, as expected. However, referencing the reverse side of the relation does not follow this behavior and raises a {{{DoesNotExist}}} exception. For example, in the following situation where {{{Shop}}}s have optionally a {{{Place}}} (e.g. webshops need not have a physical location): {{{ class Place(models.Model) address = models.CharField(max_length=80) class Shop(models.Model) place = models.OneToOneField(Place, null=True) name = models.CharField(max_length=50) website = models.URLField() }}} This ''does'' work as expected: {{{ >>> s1 = Shop.objects.create(name='Shop', website='shop.com') >>> print s1.place None }}} But this ''doesn't'' work as expected: {{{ >>> p1 = Place.objects.create(address='123 somestr') >>> p1.shop ... [exception stack trace] ... DoesNotExist: Shop matching query does not exist. }}} I would expect this to be {{{None}}} when {{{null}}} is allowed on the {{{OneToOneField}}}. Please correct my if I'm wrong. I have attached a patch to fix this (checking if {{{null}}} is allowed and returning {{{None}}} or raising the exception appropriately), including tests. Unfortunately this is slightly backwards incompatible, since someone may currently rely on the exception being thrown. nobody rvdrijst onetoone related expection null 0 0 0 0 0 0
10244 2009-02-12 14:40:54 2016-10-25 14:22:22 2019-06-24 02:06:21.025075 Accepted new Database layer (models, ORM) Bug Normal 1.0   FileFields can't be set to NULL in the db Saving FileFields with a none value sets the field to a empty string in the db and not NULL as it should. nobody oyvind filefield NULL empty 0 1 0 1 1 0
10305 2009-02-19 19:55:56 2015-10-09 23:38:02 2019-06-24 02:07:00.317157 Accepted new contrib.admin New feature Normal master   Add a form instantiation hook for contrib.admin add/change views `add_view` and `change_view` have the following code: {{{#!python ModelForm = self.get_form(request) ... form = ModelForm(request.POST, request.FILES) }}} or: {{{#!python form = ModelForm(initial=initial) }}} or: {{{#!python form = ModelForm(request.POST, request.FILES, instance=obj) }}} I would propose: {{{#!python if isinstance(ModelForm, ModelFormMetaclass): form = ModelForm(request.POST, request.FILES) else form = ModelForm }}} This way gives the flexibility to override the function `get_form(self, request, obj=None, **kwargs)`, which could return a `modelform_factory(self.model, **defaults)` or an instance of a model form. nobody ctao add_view, change_view, ModelForm 0 0 0 0 0 0
10327 2009-02-22 00:27:35 2013-03-06 09:23:34 2019-06-24 02:07:14.802053 Accepted new contrib.admin Bug Normal master   Pass document.domain to popup windows in admin Some applications require Javascript collaboration between views and scripts from the static media location. When these are served from different domains collaboration fails because of the [http://en.wikipedia.org/wiki/Same_origin_policy same origin policy] implemented in browsers. Scripts can still work together if they are served from subdomains with a common parent (for example, `www.example.com` and `media.example.com`) by setting the `document.domain` variable to that common parent (in the example, `example.com`). Unfortunately, the `document.domain` variable is not automatically passed to newly opened windows. The attached patch passes the variable to popup windows in the admin interface. Currently it is always passed, but may be nicer to do so only if it is different from the real server name. There are also currently no tests; I'm unsure how to test this functionality. The patch was tested with the TinyMCE editor, which uses the above trick for its own popup windows. The patch allows, for example, the `raw_id_fields` functionality to work again for pages with TinyMCE editors (when static files are served from a different domain). nobody jcassee   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
10449 2009-03-09 15:44:36 2018-11-13 22:19:07 2019-06-24 02:08:34.134698 Accepted new Internationalization Bug Normal 1.0   HTML accents not escaped out when using forms When passing a translated string to a select box using a Forms Select widget, the output string still contains accent HTML entity codes. For example: "Problemas para el Inicio de Sesi&oacute;n o relacionados con la Cuenta My code is set up as follows: Models.py {{{ from django.utils import translation from django.utils.translation import ugettext_lazy as _ SUBJECT = ( (10, _('Log-in or Account related problems')), (20, _('General enquiry')), (30, _('Other feedback')), ) }}} This is then used in a form: {{{ class HelpFeedbackForm(forms.Form): #form for user to submit their feedback when not logged in subject = forms.CharField(widget=forms.Select(choices=SUBJECT)) }}} This is then presented in the template as: {{ form.subject }} which produces: "Problemas para el Inicio de Sesi&oacute;n o relacionados con la Cuenta" as mentioned above. The translations are returned from the django.po file, but all of the HTML entity codes are returned as is, in the Select box in the template. Also, use of the safe template filter tag does affect this and the string is still rendered with accents. nobody tipan accents, newforms 0 0 0 1 1 0
10621 2009-03-25 09:35:49 2011-04-02 02:25:30 2019-06-24 02:10:25.946658 Accepted new Database layer (models, ORM) New feature Normal     Add a way to have an aggregate() result as a queryset If one is trying to construct a complex queryset, involving nesting other querysets, there's currently no way to include the results of an `aggregate()` call. For example, consider {{{ #!python class Item(models.Model): name = models.CharField(max_length=10) }}} If I want to include the number of Items in some other queryset, such as {{{ #!python Foo.objects.filter(items__in=[...]).annotate(num=Count("items").filter(num=item_count) }}} We can't write item_count (which would be `Items.objects.aggregate(Count("id"))`) as an inner queryset here, since the `aggregate()` call returns a dictionary, not a queryset. The return value of `aggregate()` is fine, but this ticket is about adding a version that does return a queryset. Right now, there's no way to fake this with `annotate(...).values(...)` since that always introduces a `GROUP BY` clause and the whole point is not to group by anything. Not sure whether adding a parameter to `aggregate()` is the right idea, or adding something to the `annotate()` route to specify "no grouping whatsoever". This is all 1.2 timeframe stuff, but it's something to think about. nobody mtredinnick   0 0 0 0 0 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
10743 2009-04-05 23:08:42 2016-05-29 13:51:24 2019-06-24 02:11:46.025451 Accepted new contrib.admin New feature Normal master   Support lookup separators in ModelAdmin.list_display As with #3400, supporting the `__` lookup separator in `ModelAdmin.list_display` is useful as it avoids calling `__unicode__` bluntly, giving users more control over the output: * display several fields from the same related model, * as listed in #3400, traverse several levels of relations. One could argue that most of this can be achieved with `__unicode__` by cramming the information to its output. However, there's a larger problem with deferred fields (deferring is exemplified in [http://code.djangoproject.com/ticket/10712#comment:3 this comment]) -- namely, that couples admin code to the implementation of `__unicode__` in related models. That is, knowledge of what fields are referred to in `__unicode__` is required to write proper deferred statements. A case to illustrate how changes in `__unicode__` can have dramatic, unintentional impact: * assume the related objects are large and complex, * to keep the admin changelist view snappy, the developer looks which fields are referred to in their `__unicode__` and writes the `ModelAdmin.queryset()` method correspondingly, selecting only these fields with `only()`, * a single query is all that is needed to display the data in changelist view, admin is snappy, there is much rejoicing, * a second person keeps hacking at the related models, unknowing the impact changes to `__unicode__` could have to admin, adds another field to it, * suddenly rendering the changelist results in `n` queries, each of which pulls in the whole object. All that can be avoided with explicit `__` support. nobody mrts efficient-admin, list_display 0 1 0 1 1 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 3160.184ms