42 rows where "changetime" is on date 2017-01-18

View and edit SQL

Suggested facets: changetime, stage, component, type, severity, version, resolution, owner, reporter, easy, has_patch, needs_better_patch, needs_tests, needs_docs, created (date), last_pulled_from_trac (date)

changetime (date)

  • 2017-01-18 · 42
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
13110 2010-03-13 23:31:22 2017-01-18 03:09:50 2019-06-24 02:37:31.250220 Accepted closed contrib.syndication New feature Normal master fixed Allow multiple enclosures in Atom feeds For now, Feed.item_enclosure_url represents a single enclosure for an item. It should be nice to support many enclosures per item. Something like that: {{{ class ExampleFeed(Feed): def item_enclosure_url(self, item): return [video.url for video in item.videos] }}} unaizalakain Piaume multiple, enclosures, atom, feed 1.9 0 1 0 0 0 0
14153 2010-08-22 19:23:55 2017-01-18 21:51:03 2019-06-24 02:48:52.121266 Design decision needed closed Contrib apps Uncategorized Normal 1.2 invalid Redirects fail if URL has appended query string The redirect middleware obtains the path of the current request with {{{path = request.get_full_path()}}}, then tries to find a match in the Redirect table.[[BR]] If there is an appended query string, it will include this when querying the Redirect table (and so fail to find a match).[[BR]] Shouldn't we use {{{path = request.path}}} instead? nobody richardb redirect 0 0 0 1 0 0
15053 2011-01-11 19:09:40 2017-01-18 03:09:49 2019-06-24 02:58:33.986039 Ready for checkin closed Template system New feature Normal master fixed Make templates more reusable by Improving template loading algorithm to avoid extending infinite recursion Many times when we use a django application we need to adapt it a little bit. Often this adaptation is just a little change in the html. So we have to copy the application template into our project templates. It would be awesome that the template loading algorithm let us to overwrite just the template blocks we want to change. For example: If we use [http://code.google.com/p/django-profile/ django profile] and we want to modify the title of the [http://code.google.com/p/django-profile/source/browse/trunk/userprofile/templates/userprofile/account/login.html?r=457 login] template from "User login" to "Login" we have to copy and paste 51 lines of code. If we want to add a new javascript resource we have to copy and paste 51 lines of code and so on. But if we could adapt the template loading system so it could use the order of the loaders to avoid extending cycles, we could do the above example with a template (in our project directory) like this: Template: userprofile/account/login.html {{{ {% extends "userprofile/account/login.html"%} {% comment %} this doesn't extend itself but the application template {% endcomment %} {% load i18n%} {% block title%} {% trans "Login"%} {% endblock%} }}} {{{ TEMPLATE_LOADERS = ( 'django.template.loaders.filesystem.Loader', 'django.template.loaders.app_directories.Loader', # 'django.template.loaders.eggs.Loader', ) }}} We have an [http://code.google.com/p/django-smart-extends/ implementation] that works on Django 1.2 and Django 1.1. But if we set TEMPLATE_DEBUG = True in settings.py we need to patch Django: * Django 1.2 (trunk r15173) attachment * [http://code.google.com/p/django-smart-extends/source/browse/trunk/patches/patch1.2.diff Django 1.2] * [http://code.google.com/p/django-smart-extends/source/browse/branches/django_1.1.X/patches/patch1.1.X.diff Django 1.1] This also works with others template loaders. unaizalakain pmartin   0 1 0 0 0 0
18651 2012-07-20 04:42:46 2017-01-18 03:09:49 2019-06-24 03:37:35.558900 Accepted closed Template system New feature Normal 1.4 fixed Assignment tags should allow optional assignments Assignment tags should allow optional assignments, so that if `as` part is missing, they output the result. Otherwise store it into variable. Tim Graham <timograham@gmail.com> mitar   0 1 0 0 0 0
19567 2013-01-05 10:01:04 2017-01-18 03:09:51 2019-06-24 03:47:29.268404 Ready for checkin closed Internationalization New feature Normal master fixed Make javascript i18n view as CBV and more extensible. The current view populates a global namespace (see https://code.djangoproject.com/ticket/18231) but also is very monolitic. My proposal is create a CBV. I don't understand the use of templates for rendering a view (related ticket). Now, the initial code is available on this file: https://github.com/niwibe/django-jsgettext/blob/master/djsgettext/views.py If the proposal is accepted, I will create a patch. claudep niwi i18n javascript 0 1 0 0 0 0
19738 2013-02-04 18:02:24 2017-01-18 03:09:49 2019-06-24 03:49:18.350052 Ready for checkin closed Database layer (models, ORM) Bug Normal master fixed "manage.py shell" on a fresh project raises RuntimeWarning about naive datetime, if IPython is installed IPython uses SQLite internally to store shell session history. At the beginning and end of every shell session, it issues a SQLite query to get/save the history. For some reason this query includes a (timezone-naive) datetime. Django's SQLite DB backend registers a global datetime adapter function which issues a warning in case it receives a naive datetime when timezone support is activated. In combination, this means that on a fresh `startproject` if you fire up `manage.py shell` without making a single change to settings, if IPython is installed you'll get "RuntimeWarning: SQLite received a naive datetime (2013-02-04 17:14:13.070091) while time zone support is active." on shell startup and exit. That's an ugly experience for a newcomer to Django - it _looks_ to them as if Django is shipping a broken setup by default. Probably this is Django's fault for registering a potentially-noisy process-global SQLite adapter, and we should consider whether to just remove that warning in the adapter. The model layer will already warn about naive datetimes, so this warning is only needed for raw SQL. aaugustin carljm   0 1 0 0 0 0
20223 2013-04-08 21:12:17 2017-01-18 03:09:50 2019-06-24 03:54:29.828135 Accepted closed Utilities New feature Normal master fixed Allow allow_lazy to be used as a decorator `allow_lazy` cannot be used as a decorator for now, at least not in @-notation, because *resultclasses is required argument for this function. Decorator with arguments are functions, which accept arguments, returning function, which decorates source function. In allow_lazy signature arguments and function are mixed. So, proposal is to distinguish on type: if first argument of allow_lazy is of type `type`, then treat it like a three-def-decorator, while allowing current two-def-decorator behaviour if first argument is a function. yakky void   0 1 0 0 0 0
21127 2013-09-19 23:56:51 2017-01-18 03:09:49 2019-06-24 04:04:13.693111 Accepted closed Database layer (models, ORM) New feature Normal master fixed on_delete should be a required parameter for ForeignKey (Update: consensus below was to make `on_delete` a required argument, rather than twiddling with its defaults.) This wasn't done when we added the `on_delete` feature due to concerns about breaking backwards-compatibility with the previous always-cascade-deletes behavior. But if you set aside legacy considerations, it seems intuitively obvious (to me anyway) that SET_NULL is a superior default for a nullable FK than CASCADE. And even if others might have a different intuition, the consequences of your intuition being wrong are far from symmetrical: one way you get a model instance with a null FK hanging around that you didn't expect to still have, the other way you get data loss. The trick, of course, is that changing default values is hard to do with a deprecation process. For a deprecation warning to catch the people it needs to catch, you have to warn anytime an explicit value is not specified. So you have to force everybody to stop relying on the default in order to silence the deprecation warnings, which reduces the value of having a new default, in the short run anyway. I think it's still worth doing for the long run, though. We could also consider doing it without a deprecation process, just a backwards-incompatible note in the release notes. Since the consequences are the opposite of data loss, that might be ok. Thoughts? fcurella carljm   0 1 0 0 0 0
22993 2014-07-10 14:45:00 2017-01-18 03:09:49 2019-06-24 04:24:28.619570 Accepted closed contrib.auth Cleanup/optimization Normal master fixed Drop skipIfCustomUser decorator With the test discovery changes in 1.6, the tests for `django.contrib` apps are no longer run as part of user's project. For this reason I believe we no longer need to decorate tests in `contrib.auth` with `@skipIfCustomUser`. chrisjluc timo   1 1 0 0 0 0
23832 2014-11-15 12:34:42 2017-01-18 03:09:51 2019-06-24 04:33:41.516254 Accepted closed File uploads/storage New feature Normal master fixed Storage API should provide a timezone aware approach Per #23827, the Storage API is effectively (and once the patch there is merged, explicitly) timezone naive. We should provide a way of using Storage objects that returns suitable aware objects instead. A suggestion by Russell Keith-Magee is to introduce an optional parameter to these calls, with a tri-state value to select between naive and aware returns, with a default of `None` initially meaning "naive", but a deprecation path for this through to `None` meaning "aware". jaylett jaylett   0 1 0 0 0 0
23957 2014-12-03 16:59:29 2017-01-18 03:09:52 2019-06-24 04:35:02.988352 Accepted closed contrib.auth Cleanup/optimization Normal master fixed Start a deprecation path toward requiring session verification From Carl in comments of #23939: "Is there a use case for a long-term simple way to disable this behavior? Or is it just a way to preserve sessions across the upgrade that we need? I think we should be on a deprecation path to making [session verification] always-on; I think it's fine if you have to write your own `AuthenticationMiddleware` if you don't want it." As far as I know, the only-use case for disabling it was to provide an upgrade path. The deprecation path could look like this: 1.8: Raise `RemovedInDjango20Warning` if `AuthenticationMiddleware` but not `SessionAuthenticationMiddleware` is in `MIDDLEWARE_CLASSES` (because session verification will be mandatory in 2.0) 2.0: It's now safe to remove `SessionAuthenticationMiddleware` from `MIDDLEWARE_CLASSES` since the behavior can't be turned off. Raise `RemovedInDjango22Warning` if it's there so we can eventually remove the class. timgraham timgraham   0 1 0 0 0 0
23960 2014-12-05 00:08:32 2017-01-18 03:09:49 2019-06-24 04:35:04.907251 Ready for checkin closed HTTP handling Cleanup/optimization Normal 1.9 fixed HTTP standard no longer requires the Location header to be an absolute URI RFC 2616 required the `Location` header (in redirect responses) to be an absolute URI. In Django, we have `django.http.utils.fix_location_header()` to unconditionally ensure this. RFC 2616 has now been superseded by RFC 7231, which allows relative URIs in `Location` (recognizing the actual practice of user agents, almost all of which support them): http://tools.ietf.org/html/rfc7231#section-7.1.2 We should remove `django.http.utils.fix_location_header()`. Since user agents almost universally allow relative `Location` (I'm not aware of any that don't), I don't believe this change requires a deprecation path, but it should of course be noted in the release notes. claudep carljm   0 1 0 0 0 0
24046 2014-12-23 21:45:11 2017-01-18 03:09:52 2019-06-24 04:36:00.665964 Accepted closed Utilities Cleanup/optimization Normal master fixed Deprecate the "escape" half of django.utils.safestring Since any data that isn't explicitly marked as safe must be treated as unsafe, I don't understand why we have `EscapeData` and its subclasses nor the `mark_for_escaping` function. It seems to me that we could keep only the "safe" half of django.utils.safestring and deprecate the "escape" half. As a matter of fact the "escape" isn't used meaningfully anywhere in Django. nobody aaugustin   0 1 0 0 0 0
24126 2015-01-11 18:36:13 2017-01-18 03:09:50 2019-06-24 04:36:52.165491 Accepted closed contrib.auth Cleanup/optimization Normal master fixed Consider deprecating the current_app argument of auth views All views defined in `django.contrib.auth.views` have the following structure: {{{ def view(request, ..., current_app=None, ...): ... if current_app is not None: request.current_app = current_app return TemplateResponse(request, template_name, context) }}} As of Django 1.8 `current_app` is set on the `request` object. (This is debated but no other concrete proposal has been made at this time.) For consistency the auth views should require the caller to set it on the `request` instead of passing it in a separate argument. That would also avoid the risk of conflicts between a `current_app` set on the `request` and another `current_app` passed in argument. Currently the latter overrides the former. lukawoj aaugustin current_app 0 1 0 0 1 0
24154 2015-01-15 06:33:07 2017-01-18 03:09:49 2019-06-24 04:37:10.186692 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal 1.8alpha1 fixed Fix check_aggregate_support for Expressions The existing check_aggregate_support does not recursively check all sub-expressions. Further, there is currently no way for non-aggregate expressions to opt-in to backend checks. Expressions should call a check_backend_support method (on the compiler or connection) passing itself. It should also pass all sub-expressions (get_source_expressions), so that we can recursively check for support. Most expressions can be a no-op if they know for certain that all backends will have support, like for the Col and Ref expressions. This will improve performance by removing quite a bit of method call overhead. The backend will then throw an exception if there is no support for a particular combination. jarshwah jarshwah   0 1 1 0 0 0
24205 2015-01-23 00:21:01 2017-01-18 03:09:48 2019-06-24 04:37:42.997762 Accepted closed Core (Other) Cleanup/optimization Normal master fixed Remove or deprecate weak parameter to Signal.disconnect() The parameter has no effect. I'm in favor of simply removing it and documenting it as a backwards incompatible change. A deprecation seems to simply add overhead. A library that attempts to support multiple versions of Django can remove the parameter without any backwards compatibility concerns. Any opposition to that? nobody timgraham   0 1 0 0 0 0
24215 2015-01-24 15:34:35 2017-01-18 03:09:49 2019-06-24 04:37:49.376468 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Refactor of lazy model operations I dealt with `add_lazy_relation()` a few months ago working on Mezzanine and I thought it could use some detangling. Now that the list of pending operations is stored in the `Apps` class, it makes sense to put the related methods on that class as well. Running a function when a model is loaded seems an appropriate job for the app registry object. I've introduced a more generic API, whereby a user-supplied function can be called once any number of models are ready, with those freshly-loaded models as its arguments (plus optional kwargs), a helper function for related models, and the old `add_lazy_relation()` reimplemented in terms of the new API with a deprecation warning. New pull request, now targeting master rather than 1.8, at https://github.com/django/django/pull/4130 nobody AlexHill   0 1 0 0 0 0
24219 2015-01-25 15:43:49 2017-01-18 03:09:49 2019-06-24 04:37:51.933882 Ready for checkin closed Forms Cleanup/optimization Normal master fixed Deprecate django.forms.extras and move SelectDateWidget with the other widget. The content of `django.forms.extras` has hardly changed since it was introduced and `SelectDateWidget` is its only member, let's keep all widgets together and deprecate that package. The `tests/forms_tests/tests/test_extra.py` has accumulated a bunch of misplaced tests and needs cleaning up too. loic loic   0 1 0 0 0 0
24716 2015-04-27 20:00:31 2017-01-18 03:09:50 2019-06-24 04:43:17.264522 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Deprecate Field._get_val_from_obj Redundant method, called only by `Field.value_to_string`. ovangle ovangle   0 1 0 0 0 0
24728 2015-04-29 17:04:32 2017-01-18 03:09:49 2019-06-24 04:43:25.102685 Ready for checkin closed contrib.syndication Cleanup/optimization Normal master fixed feedgenerator classes still use "mime_type" instead of "content_type" The `mimetype` argument to `HttpResponse` and others was deprecated in v1.5 and removed in v1.7 in favor of `content_type` to be more semantically aligned with the HTTP header it represents. However, the feedgenerator classes `django.utils.feedgenerator.RssFeed` and `django.utils.feedgenerator.Atom1Feed` still use a `mime_type` attribute. This leads to slightly ungainly semantics like: {{{#!python response = HttpResponse(content_type=feed.mime_type) }}} Might be aesthetically nicer to make this more consistent by using `content_type` across the board. raphaelm yourcelf   0 1 0 0 0 0
25079 2015-07-07 19:42:06 2017-01-18 03:09:52 2019-06-24 04:47:17.560821 Accepted closed Template system Cleanup/optimization Normal 1.8 fixed Warn if both TEMPLATES and TEMPLATE_DIRS are defined Since the addition of the pluggable template backends, the `TEMPLATE_DIRS` setting has been deprecated in favour of the `TEMPLATES` list of dicts. If `TEMPLATES` is not defined, it will be constructed using the value of `TEMPLATE_DIRS`. However, `TEMPLATES` is created automatically by the default project template; and in this case Django does not use the value in `TEMPLATE_DIRS`. This means that users following pre-1.8 tutorials (for example, the very popular Tango with Django) will be instructed to add `TEMPLATE_DIRS` to a settings file that ignores that value, and then will be surprised that their templates are not found. This has hit quite a few users on StackOverflow, for example: http://stackoverflow.com/questions/31108314/templatedoesnotexist-error-in-django/31109213 http://stackoverflow.com/questions/30844500/django-templatedoesnotexist-error-on-windows-machine http://stackoverflow.com/questions/30740700/django-templatedoesnotexist-at-home-html http://stackoverflow.com/questions/26176267/django-template-loader-cant-find-template/30588425#30588425 and so on. Django should explicitly warn in this case, telling users to move their directories settings to `TEMPLATES`. PR: https://github.com/django/django/pull/4959 nobody danielr   0 1 0 0 0 0
25120 2015-07-13 19:49:31 2017-01-18 03:09:50 2019-06-24 04:47:43.987942 Accepted closed Template system Cleanup/optimization Normal master fixed Deprecate template.loaders.eggs.Loader [https://groups.google.com/d/topic/django-developers/60E1uUuK2yU/discussion django-developers thread] James: The problem of providing a single-file, no-build-step format for distributing and installing Python packages has been solved by wheels, and wheels also don't cause the pile of weirdness that comes with using eggs. So Django should really stop encouraging/supporting the use of eggs. At a minimum, this should involve Django 1.9 starting the deprecation process for the egg template loader, and any other parts of Django which contain special-case workarounds to deal with eggs. Marc & Preston T: +1 Donald: I’m fine with this, but just be warned that it does mean anything that ships a Django app will need a `zip_unsafe=True` or else they no longer support being installed with easy_install. See [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature Deprecating a Feature] for the checklist of what needs to be done. nobody timgraham   0 1 0 0 0 0
25135 2015-07-17 12:06:08 2017-01-18 03:09:50 2019-06-24 04:47:53.524952 Ready for checkin closed contrib.admin Cleanup/optimization Normal master fixed Deprecate admin list_display allow_tags I've noticed that setting `allow_tags` on a `list_display` function is not necessary if it already returns a safe string (by using `mark_safe` or `format_html`). The docs on `allow_tags` mention: If the string given is a method of the model, ModelAdmin or a callable, Django will HTML-escape the output by default. If you’d rather not escape the output of the method, give the method an `allow_tags` attribute whose value is `True`. However, to avoid an XSS vulnerability, you should use `format_html()` to escape user-provided inputs. To push people to actually do that, deprecating `allow_tags` and pointing to `format_html`/`mark_safe` could be a good thing. olasitarska jaap3   0 1 0 0 0 0
25184 2015-07-28 12:41:23 2017-01-18 03:09:49 2019-06-24 04:48:26.205547 Ready for checkin closed GIS New feature Normal master fixed Add support for MaxMind GeoLite2 database format Django currently supports the [http://dev.maxmind.com/geoip/legacy/geolite/ GeoLite Legacy format] (IPv4 only). There's a patch to add IPv6 legacy support (#18349), but it seems better to add support for the [http://dev.maxmind.com/geoip/geoip2/geolite2/ GeoLite2 format] instead and possibly deprecate support for the legacy format (could be a separate ticket). fcurella timgraham   0 1 0 0 0 0
25190 2015-07-29 15:05:13 2017-01-18 03:09:50 2019-06-24 04:48:30.043337 Accepted closed Testing framework Cleanup/optimization Normal master fixed Deprecate callable_obj parameter to assertRaisesMessage It was deprecated in Python in https://hg.python.org/cpython/rev/ac13f0390866 and those warnings were fixed in c2bc1cefdcbbf074408f4a4cace88b315cf9d652. Then I realized `callable_obj` was a documented parameter so I added backwards compatibility in e89c3a46035e9fe17c373a6c9cd63b9fd631d596 and updated the docs in a0175724b086127a4e13612042961d3ba88d6bd9. timgraham timgraham   0 1 0 0 0 0
25466 2015-09-25 17:30:08 2017-01-18 03:09:50 2019-06-24 04:51:28.200988 Accepted closed Template system Bug Release blocker 1.9a1 fixed django.template.loader.LoaderOrigin was removed without proper deprecation #15053 caused the removal of `django.template.loader.LoadOrigin` (and `django.template.StringOrigin`), in favor of `django.template.base.Origin`, for Django 1.9. These APIs were new and documented as of Django 1.7: https://docs.djangoproject.com/en/1.7/ref/templates/api/#template-origin Even in the 1.8 branch, there is no DeprecationWarning for this class: https://github.com/django/django/blob/stable/1.8.x/django/template/loader.py#L14 nobody tarkatronic   0 1 0 0 0 0
25550 2015-10-13 11:01:55 2017-01-18 03:09:50 2019-06-24 04:52:23.808352 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Deprecate direct assignment to the reverse side of a related set As [https://groups.google.com/d/topic/django-developers/RVivKK3vUnE/discussion proposed by Ansii] on django-developers: {{{ >>> obj.reverse_fk_set = RelatedObj.objects.all() }}} What happens is that the `RelatedObj.objects.all()` queryset is iterated and each object of the queryset is saved with the fk changed to point to the `obj`. An implicit save. Now, I don't like the implicit saves at all. A variable assignment should not cause a database save. So, I would like to deprecate the current behavior. Assignment to `reverse_fk_set` (and I guess this goes for m2m, too) is no longer allowed. Instead you will need to explicitly do: {{{ >>> obj.reverse_fk_set.set(RelatedObj.objects.all()) }}} Now you are calling a method, and saving in this situation is OK and analogous to other related manager methods. Lets raise a deprecation warning on direct assignment to the `reverse_fk_set` and remove it. The message would be something like "Direct assignment to the reverse side of a related set is deprecated. Use .set() instead." nobody timgraham   0 1 0 0 0 0
25665 2015-11-03 09:01:15 2017-01-18 03:09:50 2019-06-24 04:53:36.667311 Ready for checkin closed GIS Cleanup/optimization Normal master fixed deprecate public getters/setters for properties of `GEOSGeometry` and its subclasses   sir-sigurd sir-sigurd   0 1 0 0 0 0
25773 2015-11-19 03:24:09 2017-01-18 03:09:50 2019-06-24 04:54:47.117150 Accepted closed GIS Cleanup/optimization Normal master fixed deprecate `MultiPolygon.cascaded_union` in favor of `GEOSGeometry.unary_union` GEOS 3.3 deprecates `GEOSUnionCascaded` in favor of `GEOSUnaryUnion` so similar changes should be done for Django. sir-sigurd sir-sigurd   0 1 0 0 0 0
25838 2015-11-30 12:06:57 2017-01-18 03:09:51 2019-06-24 04:55:28.756544 Accepted closed Core (Management commands) Cleanup/optimization Normal master fixed ./manage.py shell creates unnecessary nested exceptions Steps to reproduce (using Python 3): * Open a python shell with ./manage.py shell * raise an exception with `raise Exception` Notice how the exception is nested with another one: {{{#!py >>> raise Exception Traceback (most recent call last): File "./django/core/management/commands/shell.py", line 67, in handle raise ImportError ImportError During handling of the above exception, another exception occurred: Traceback (most recent call last): File "<console>", line 1, in <module> Exception }}} nobody bmispelon   0 1 0 0 0 0
25847 2015-12-02 11:25:26 2017-01-18 03:09:51 2019-06-24 04:55:34.551623 Accepted closed contrib.auth New feature Normal master fixed Make User.is_authenticated() and User.is_anonymous() "callable properties" There's an inconsistency between `is_authenticated` and `is_superuser`. The former is a method and the latter is a property, leading many people to do: {{{ if request.user.is_authenticated: return sensitive_information }}} which is, of course, always executed. I propose that is_authenticated be turned into a property, while it can also be a callable, for backwards-compatibility. jlaine skorokithakis 1.10 0 1 0 0 0 0
26013 2015-12-30 12:47:05 2017-01-18 03:09:51 2019-06-24 04:57:22.499432 Accepted closed Core (URLs) Cleanup/optimization Normal master fixed Move django.core.urlresolvers to django.urls As part of the [https://groups.google.com/d/topic/django-developers/WD_mPzvGMZI/discussion URL dispatching work] targeted for Django 1.10, `django.core.urlresolvers` is moved to `django.urls`. I'd like this code move submitted as a separate pull request to make review easier. knbk timgraham   0 1 0 0 0 0
26058 2016-01-08 13:30:52 2017-01-18 03:09:52 2019-06-24 04:57:51.668529 Accepted closed File uploads/storage Cleanup/optimization Normal 1.9 fixed Custom storage backend's not entirely decoupled from FileField Let me start by saying that I've implemented custom FileFields that can handle Numpy objects, to provide some convenience methods to access the typed objects. Later, when implementing a custom storage backend for Azure Storage, I encountered some issues when handling filenames. Cloud storage doesn't behave like local file system storage does. Most of Django's code is agnostic of this problem, except for a small section of FileField: https://github.com/django/django/blob/77b8d8cb6d6d6345f479c68c4892291c1492ba7e/django/db/models/fields/files.py#L306-L320 In Azure, blobs are stored in containers, and are optionally stored in subfolders (known as prefixes in Azure-speak). To be able to use the upload_to property, I need to be able to pass the full path, e.g.: container/blob container/sub/blob container/sub/sub/blob Unfortunately, FileField strips the directory part and only passes the blob name to my custom storage backend's get_valid_name implementation, where I really need to validate the whole string. I ended up subclassing FileField: {{{ class CloudStorageFileField(FileField): """ Provides some overrides to enable cloud storage backends """ def get_directory_name(self): return force_text(datetime.datetime.now().strftime(force_str(self.upload_to))) def get_filename(self, filename): return filename def generate_filename(self, instance, filename): if callable(self.upload_to): filename = self.upload_to(instance, filename) filename = self.storage.get_valid_name(filename) return filename return self.get_directory_name() + self.storage.get_valid_name(filename) }}} As you can see, all I did was remove the local file system related logic. Unfortunately, my custom file fields need to inherit from this class to work with Azure storage, and when I switch to local storage in a different environment, they have to inherit from the regular FileField! This is obviously an undesirable situation,… nobody Korijn custom storage filefield 0 1 0 0 0 0
26154 2016-01-29 16:31:45 2017-01-18 03:09:51 2019-06-24 04:58:53.467419 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Deprecate CommaSeparatedIntegerField As [https://groups.google.com/d/topic/django-developers/wfp9qNpNpaQ/discussion proposed on django-developers], `CommaSeparatedIntegerField` could be replaced with `CharField(validators=[validate_comma_separated_integer_list])`. The only database storage difference is on Oracle: {{{ 'CharField': 'NVARCHAR2(%(max_length)s)', 'CommaSeparatedIntegerField': 'VARCHAR2(%(max_length)s)', }}} There are some upgrade considerations described on the mailing list that'll need to be mentioned for Oracle users. See [https://docs.djangoproject.com/en/dev/topics/migrations/#considerations-when-removing-model-fields the migration topic guide] for an explanation of how to deprecate the field, as well as the [https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#deprecating-a-feature deprecating a feature guide]. Brobin timgraham   0 1 1 0 0 0
26226 2016-02-16 21:02:19 2017-01-18 03:09:51 2019-06-24 04:59:40.104733 Ready for checkin closed Database layer (models, ORM) Bug Normal master fixed Related managers should honor the queryset used for prefetching their results. This is a variation of #26211 which does not involve multiple calls to `order_by`. Given these models: {{{ class Parent(models.Model): pass class Child(models.Model): saved_dt = models.DateTimeField(auto_now_add=True) parent = models.ForeignKey(Parent) }}} why does this return `False`?: {{{ >>> Parent.objects.prefetch_related(Prefetch('child_set', Child.objects.order_by('saved_dt'))).first().child_set.all().ordered False }}} it looks like the SQL queries generated do actually have the sort logic, but the query set does not reflect this fact: {{{ SELECT "prefetch_parent"."id" FROM "prefetch_parent" ORDER BY "prefetch_parent"."id" ASC LIMIT 1; args=() SELECT "prefetch_child"."id", "prefetch_child"."saved_dt", "prefetch_child"."parent_id" FROM "prefetch_child" WHERE "prefetch_child"."parent_id" IN (1) ORDER BY "prefetch_child"."saved_dt" ASC; args=(1,) }}} nobody cancan101 prefetch 0 1 0 0 0 0
26230 2016-02-17 14:51:10 2017-01-18 03:09:51 2019-06-24 04:59:42.758867 Accepted closed Database layer (models, ORM) Bug Normal master fixed RelatedField.related_query_name should default to _meta.default_related_name if defined. If I attach a `default_related_name` for my model using the name in a model lookup fails. For example, if I have the following models: {{{ from django.db import models class Foo(models.Model): a = models.IntegerField(default=0) class Bar(models.Model): foo = models.ForeignKey(Foo, related_name='bars') class Boo(models.Model): foo = models.ForeignKey(Foo) class Meta: default_related_name = 'boos' }}} And the following tests: {{{ from django.test import TestCase from .models import Foo, Bar, Boo class Test(TestCase): def setUp(self): self.foo = Foo.objects.create() def test_related_name_on_field___all_is_fine(self): instance = Bar.objects.create(foo=self.foo) # get related set self.assertEqual(instance, self.foo.bars.first()) # filter foos through lookup self.assertEqual(self.foo, Foo.objects.get(bars=instance)) def test_related_name_is_default___lookup_fails(self): instance = Boo.objects.create(foo=self.foo) # get related set self.assertEqual(instance, self.foo.boos.first()) # filter foos through lookup self.assertEqual(self.foo, Foo.objects.get(boos=instance)) }}} I get the following error: {{{ django.core.exceptions.FieldError: Cannot resolve keyword 'boos' into field. Choices are: a, bars, boo, id }}} This shows I can use `boos` as a property for `Foo` objects but when i try to use it in a lookup it is expecting `boo` rather than `boos` chenesan OmegaDroid   0 1 1 0 0 0
26263 2016-02-22 18:24:40 2017-01-18 03:09:51 2019-06-24 05:00:04.760059 Ready for checkin closed Template system Cleanup/optimization Normal master fixed Deprecate the template Context.has_key() method Considering that: * `Context` is essentially documented as a dict-like object * `dict.has_key()` exists on Python 2 * this method has been around "forever" Aymeric favors a deprecation even though it's not documented. timgraham timgraham   0 1 0 0 0 0
26320 2016-03-03 23:21:38 2017-01-18 03:09:51 2019-06-24 05:00:47.329974 Ready for checkin closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Deprecate implicit OneToOneField parent_link Suppose we have these models: {{{#!python class Parent(Model): pass class Child(Parent): parent_ptr2 = OneToOneField(Parent, null=True, related_name='+') }}} `Child` should have two `OneToOneField`s, `parent_ptr` and `parent_ptr2`. Unfortunately, Django has a critical issue where it merges these two fields into this: {{{#!python parent_ptr2 = OneToOneField(Parent, primary_key=True, null=True, related_name='+') }}} And of course, a nullable primary key is impossible, so we can’t even do a migration: `fields.E007` is raised. But defining without multi-table inheritance exactly the same model – in terms of database definition – works just fine: {{{#!python class WorkingModel(Model): parent_ptr = OneToOneField(Parent, primary_key=True, related_name='+') parent_ptr2 = OneToOneField(Parent, null=True, related_name='+') }}} So multi-table inheritance is probably what causes this confusion. This bug is present on all supported Django versions, from 1.8 to 1.9.3. I guess this can be seen as a release blocker, there is no regression but this is quite critical (and blocking, in my case). nobody BertrandBordage   0 1 0 0 0 0
26509 2016-04-15 16:29:07 2017-01-18 03:09:51 2019-06-24 05:02:52.167677 Accepted closed GIS Cleanup/optimization Normal master fixed Deprecate the precision_wkt() contrib.gis function The `precision_wkt()` function in `django/contrib/gis/utils/wkt.py` is untested, unused, undocumented and came in with the original GIS branch in 2008 and has been untouched since. Claude says it's worth testing and documenting. nobody timgraham   1 1 0 0 0 0
26533 2016-04-23 15:40:24 2017-01-18 03:09:51 2019-06-24 05:03:07.467136 Accepted closed Forms Cleanup/optimization Normal master fixed Rename Widget._format_value() to format_value() This is a cleanup extracted from Preston's [https://github.com/django/django/pull/4848 template-based widget rendering] branch. nobody timgraham   0 1 0 0 0 0
26601 2016-05-09 16:16:53 2017-01-18 03:09:52 2019-06-24 05:03:55.708927 Ready for checkin closed HTTP handling New feature Normal master fixed DEP5 implementation: Improved middleware The existing Django "middleware" abstraction suffers from a lack of strict layering and balanced in/out calls to a given middleware. This DEP proposes an improved abstraction for wrapping the request cycle in layered pre-view and post-view actions. [https://github.com/django/deps/blob/master/draft/0005-improved-middleware.rst DEP] [https://groups.google.com/d/topic/django-developers/8LMJ44KAxWI/discussion django-developers discussion] timgraham timgraham   0 1 0 0 0 0
27740 2017-01-17 19:34:17 2017-01-18 15:20:08 2019-06-24 05:16:18.086073 Unreviewed closed contrib.contenttypes New feature Normal 1.10 wontfix Allow content_type or object_id of GenericForeignKey to be field on related model I would like to specify a related model field as the values of content_type or object_id of GenericForeignKey. For example: {{{ class Widget(models.Model): content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE) class Gadget(models.Model): widget = models.ForeignKey(Widget, on_delete=models.CASCADE) object_id = models.PositiveIntegerField() content_object = GenericForeignKey('widget__content_type', 'object_id') }}} If I tried to use this now, I would get the error: {{{ Traceback (most recent call last): File "django/db/models/options.py", line 617, in get_field return self.fields_map[field_name] KeyError: 'widget__content_type' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "django/contrib/contenttypes/fields.py", line 224, in __get__ f = self.model._meta.get_field(self.ct_field) File "django/db/models/options.py", line 619, in get_field raise FieldDoesNotExist('%s has no field named %r' % (self.object_name, field_name)) django.core.exceptions.FieldDoesNotExist: Gadget has no field named 'widget__content_type' }}} One use case for this is a generic custom attribute system, where attribute fields can be created for any other model. The "fields" model has the content_type field. The "values" model has the object ID and value fields. The developer would like to query the object that the "values" record references: value.content_object nobody cmorbitzer   0 0 0 0 0 0

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