29,846 rows sorted by id descending

View and edit SQL

Suggested facets: created (date), last_pulled_from_trac (date)

id ▲ created changetime last_pulled_from_trac stage status component type severity version resolution summary description owner reporter keywords easy has_patch needs_better_patch needs_tests needs_docs ui_ux
30588 2019-06-23 17:24:12 2019-06-23 17:35:20 2019-06-24 06:04:32.051352 Unreviewed new Uncategorized Bug Release blocker 2.2   ipdb breaks the autoreloader Using ipdb within Django causes an error: {{{ File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", line 249, in watched_files yield from iter_all_python_module_files() File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", line 103, in iter_all_python_module_files return iter_modules_and_files(modules, frozenset(_error_files)) File "/usr/local/lib/python3.7/site-packages/django/utils/autoreload.py", line 120, in iter_modules_and_files sys_file_paths.append(module.__file__) AttributeError: module '__main__' has no attribute '__file__' }}} ipython seems to patch __main__: https://github.com/ipython/ipython/blob/7b42de99c651de35f487adea3f57824ad97bcd74/IPython/testing/globalipapp.py#L115 nobody orf   0 1 0 0 0 0
30587 2019-06-23 14:47:48 2019-06-23 17:44:06 2019-06-24 06:04:31.392692 Unreviewed new Uncategorized New feature Normal 2.2   Exceptions thrown by 'get_object_or_404()' shortcut method When we use get_object_or_404() method to query an object, sometimes due to invalid inputs it will through exceptions. Instead can it raise 404 directly? Ex: Models: >>class Test1(models.Model): >> c2 = models.CharField(max_length=10) >>class Test2(models.Model): >> c1 = models.UUIDField(primary_key=True, default=uuid.uuid4) >> c2 = models.CharField(max_length=10) query: 1. Below statement raises valueError: >> get_object_or_404(Test1, pk='test') >> - invalid literal for int() with base 10: 'test' 2. Below statement raises ValidationError: >> get_object_or_404(Test2, pk="test") >> - 'test' is not a valid UUID. So this method will throw diffrent exceptions in diffenrent scenario. So would it be possible to raise 404 exceptions even if it finds invalid values. nobody Killer-I   0 0 0 0 0 0
30586 2019-06-23 09:42:43 2019-06-23 09:42:43 2019-06-24 06:04:30.746024 Unreviewed new Database layer (models, ORM) Bug Normal 2.2   Django 2.2 Compatibility with PyMySQL Regarding unexpected return result on using PyMySQL with Django 2.2.x: Django 2.1.x used to cast every query into "str" like below https://github.com/django/django/blob/stable/2.1.x/django/db/backends/mysql/operations.py#L134 Django 2.2.x they changed the code by using query.decode instead of force_text method. https://github.com/django/django/blob/stable/2.2.x/django/db/backends/mysql/operations.py#L140 Reference as a proposed solution is discussed right here: https://github.com/PyMySQL/PyMySQL/issues/790#issuecomment-484201388 Thanks. nobody suthat PyMySQL 0 1 0 0 0 0
30585 2019-06-21 16:56:15 2019-06-22 12:59:56 2019-06-24 06:04:30.059750 Unreviewed closed Internationalization New feature Normal 2.2 wontfix Add support for "translate" and "blocktranslate" tags We'd like to add aliases for the `trans` and `blocktrans` template tags which do not have connotations to the transgender community. An initial proposal would be to add `translate` and `blocktranslate` as aliases. I've created https://github.com/django/django/pull/11500 as a starting point with a focus on minimizing changes to the Django code initially. Depending on people's thoughts, we're happy to do the work if people would prefer these to be the defaults throughout the codebase. nobody mwhansen   0 1 0 0 0 0
30584 2019-06-21 13:44:03 2019-06-21 13:44:03 2019-06-24 06:04:29.377420 Unreviewed new Core (Management commands) Bug Normal 2.2   call_command doesn't recognize subparsers for parameter validation If a management command contains subparsers: {{{#!python class Command(BaseCommand): def add_arguments(self, parser): subparsers = parser.add_subparsers(title="subcommands", dest="subcommand", required=True) foo = subparsers.add_parser("foo") foo.set_defaults(method=self.on_foo_command) foo.add_argument("--bar") }}} In Django, 1.11, this could be called using {{{#!python call_command('mycommand', 'foo', bar=True) }}} With the additional argument validation in call_command, this generates `ValueError: min() arg is an empty sequence` at line 124 in `django/core/management/__init__.py` because the `_SubParsersAction.option_strings` is an empty array. {{{#!python parse_args += [ '{}={}'.format(min(opt.option_strings), arg_options[opt.dest]) for opt in parser._actions if opt.required and opt.dest in options ] }}} If the subcommand parser is not tagged as required, `TypeError: Unknown option(s) for mycommand command: bar` occurs downstream. The same occurs if the subcommand is passed as an option: {{{#!python call_command('mycommand', subcommand='foo', bar=True) }}} nobody bparquet   0 0 0 0 0 0
30583 2019-06-21 12:42:38 2019-06-21 13:37:05 2019-06-24 06:04:28.734177 Accepted new Core (Serialization) Bug Normal master   XML serializer doesn't handle JSONFields. I have code: {{{ data = serializers.serialize("xml", queryset, fields=fields) }}} if I choose specific fields, which are not JSONField, it is ok. But if I choose field, which is JSONField, I receive error {{{ File "/Users/ustnv/PycharmProjects/fpg_nko/venv/lib/python3.6/site-packages/django/core/serializers/__init__.py", line 128, in serialize s.serialize(queryset, **options) File "/Users/ustnv/PycharmProjects/fpg_nko/venv/lib/python3.6/site-packages/django/core/serializers/base.py", line 107, in serialize self.handle_field(obj, field) File "/Users/ustnv/PycharmProjects/fpg_nko/venv/lib/python3.6/site-packages/django/core/serializers/xml_serializer.py", line 79, in handle_field self.xml.characters(field.value_to_string(obj)) File "/Users/ustnv/PycharmProjects/fpg_nko/venv/lib/python3.6/site-packages/django/utils/xmlutils.py", line 25, in characters if content and re.search(r'[\x00-\x08\x0B-\x0C\x0E-\x1F]', content): File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/re.py", line 182, in search return _compile(pattern, flags).search(string) TypeError: expected string or bytes-like object }}} nobody ustnv   0 0 0 0 0 0
30582 2019-06-20 15:27:03 2019-06-21 08:52:23 2019-06-24 06:04:28.010735 Unreviewed closed HTTP handling New feature Normal master wontfix Redirect by using 307/308 instead of 301/302. Now, Django uses 301/302 to redirect. This status codes' behaviors are undefined because of historical reason. RFC-7231 and RFC-7238 introduce new status code 307/308 for more strict usage. These status codes don't allow changing method during redirection. If Django users mistake form POST URL (and if the URL doesn't end with "/"), Django returns 301 to redirect new URL with trailing slash. But common browsers change method and send GET request to the new URL. Then user gets weird status code "405 Method Not Allowed" with GET. If Django uses 308 instead 301, users will get more meaningful status code like 404 or 201 (if trailing slash would be collect). Unfortunately, Only IE 11 on Windows 7/8/8.1 don't support 307/308 now (IE11 on Windows 10 supports). And Windows 8.1 lives until 2023. So I made patch that checks user-agent and return 307/308 or 301/302. * [https://stackoverflow.com/questions/42703671/which-browsers-support-307-308-redirects-and-how-do-they-handle-them?rq=1 307/308 Browser Support on stack overflow] * [https://gist.github.com/shibukawa/52502ceb5462b6bf6ea6c5704be6659b My Patch] nobody shibukawa redirect statuscode 0 0 0 0 0 0
30581 2019-06-20 09:14:51 2019-06-20 09:14:51 2019-06-24 06:04:27.309114 Accepted new Database layer (models, ORM) New feature Normal 2.2   Allow constraints to be used for validation (in Python) Follow-up from #30547, where we documented how database constraints relate to validation. **Executive summary**: In general they don't. Instead you get an `IntegrityError` on `save()`. Except, `UniqueConstraint` is able to tie-in to the existing `validate_unique()` logic, so you will get a `ValidationError` on `full_clean()`. It would be **nice** if all constraints could (in principle) be used for Python-level validation, in addition to setting up the database constraint. (We might image `ModelForm`, say, being able to extract correct validation logic from the model definition, and so on.) Initial thought is that Python validators could be inferred from `Q` objects: {{{ CheckConstraint(check=Q(age__gte=18), name='age_gte_18') }}} Looks like it maps to a simple `lambda age: age > 18`, for example. More complex examples will cause issues. Discussion: * [https://github.com/django/django/pull/10796#discussion_r244216763 PR #10796 (comment)] * [https://github.com/django/django/pull/388#issuecomment-8863209 PR #388 (comment)] So we **might** be able to do **some** auto-generation but first goal here should (I guess) be an optional hook on `BaseConstraint` that **if implemented** can be picked up for use in validation. (Or similar.) I'll create this as Accepted, since existing discussions imply that. nobody carltongibson constraints, validation 0 0 0 0 0 0
30580 2019-06-19 18:52:18 2019-06-19 21:42:05 2019-06-24 06:04:26.668018 Unreviewed closed Migrations Bug Normal 2.2 needsinfo django.db.migrations.optimizer error in indention The command "makemigrations" yields operations in wrong order; base class gets created later than ones depending on it. After tracing the issue we are certain that the error comes from django.db.migrations.optimizer. In the file optimizer.py method optimizer_inner,the "else" clause is clearly misaligned. We currently disable the optimization to get the migration operations in correct order. nobody sijianlin   0 0 0 0 0 0
30579 2019-06-19 14:18:32 2019-06-19 16:39:10 2019-06-24 06:04:26.014676 Unreviewed closed Migrations New feature Normal master wontfix Add management command to delete all tables. Please add management command to delete all tables from the DB. Currently I need to drop the DB, create it again, and then configure (e.g. create PostgreSQL extensions) it again. That's very inconvenient. nobody vporton   0 0 0 0 0 0
30578 2019-06-19 01:17:54 2019-06-21 06:12:09 2019-06-24 06:04:25.374175 Accepted assigned Forms Bug Normal master   SelectDateWidget doesn't use DATE formats properly when settings.USE_L10N=False. I think I found a bug in Django related to L10N. I'm using a SelectDateWidget in my ModelForm and want it displayed in the order <day, month, year> at the frontend. Therefore, I set {{{ #!div style="font-size: 80%" {{{#!python USE_L10N=False }}} }}} in settings.py so that my custom order specified in DATE_FORMAT takes precedence. In my case, I defined it in settings.py as {{{ #!div style="font-size: 80%" {{{#!python DATE_FORMAT="d M Y" }}} }}} Moreover, I also set {{{ #!div style="font-size: 80%" {{{#!python DATE_INPUT_FORMATS = [ "%d.%m.%Y", ] }}} }}} However, validating any dates on the server yielded invalid dates and my custom clean method for my field wasn't called. When looking at the source code for SelectDateWidget, I found value_from_datadict(): {{{ #!div style="font-size: 80%" {{{#!python def value_from_datadict(self, data, files, name): y = data.get(self.year_field % name) m = data.get(self.month_field % name) d = data.get(self.day_field % name) if y == m == d == '': return None if y is not None and m is not None and d is not None: if settings.USE_L10N: ###### <-- This is the line input_format = get_format('DATE_INPUT_FORMATS')[0] try: date_value = datetime.date(int(y), int(m), int(d)) except ValueError: pass else: date_value = datetime_safe.new_date(date_value) return date_value.strftime(input_format) # Return pseudo-ISO dates with zeros for any unselected values, # e.g. '2017-0-23'. return '%s-%s-%s' % (y or 0, m or 0, d or 0) return data.get(name) }}} }}} Shouldn't the highlighted if condition be instead? {{{ #!div style="font-size: 80%" {{{#!python if not settings.USE_L10N: }}} }}} As far as I understand the code, without the added negation above… CruxBox fensta Locale, SelectDateWidget 0 1 0 1 0 0
30577 2019-06-18 22:37:17 2019-06-19 08:10:13 2019-06-24 06:04:24.657516 Unreviewed closed contrib.admin New feature Normal 2.2 needsinfo feature request: custom rendering for readonly fields in admin The new view permission is extremely useful, and encourages more use of the Django Admin tool. It has highlighted a limitation in the rendering of `readonly_fields` that can be easily addressed. At the moment, `readonly_fields` (or all fields when the user has only `can_view`) can only have custom rendering or formatting if they are custom properties or new fields (created in the ModelAdmin), existing fields can't be changed. In my use-case I have a number of rich text enhanced `TextField`s, which when rendered as read-only show up as HTML and can't be marked safe. In this case creating a custom field in the `ModelAdmin` where the Field can be output with `mark_safe()` doesn't work as the original field needs to exist for users with change permissions, the only other way is to include the field twice which creates UX issues. If, in ModelAdmin, you could override the formatting/output of a read-only field it would address this issue. Alternatively, as mentioned in the comments of #14802, the idea of Fields having a method that is called by admin to handle the read-only HTML rendering would also do the trick as is related. nobody dwasyl   0 0 0 0 0 0
30576 2019-06-18 14:59:07 2019-06-19 05:26:56 2019-06-24 06:04:23.965643 Unreviewed closed Documentation Bug Normal master worksforme Code not working on Django Tutorial part 6. In the section "Adding a background-image" (Part 6 of Django tutorial) teaches how to add a background image by editing style.css as follows: {{{#!css body { background: white url("images/background.gif") no-repeat; } }}} However, this won't work because it doesn't reference the actual location of the image file. The following change fixes the issue (add **''/static/''**): {{{#!css body { background: white url("/static/images/background.gif") no-repeat; } }}} nobody javiercmh django, tutorial, background, image 1 0 0 0 0 0
30575 2019-06-18 09:03:08 2019-06-21 06:10:06 2019-06-24 06:04:23.300861 Unreviewed closed Database layer (models, ORM) Bug Normal master wontfix Union of TruncBase annotations with different tzinfo apply `convert_value` of last tzinfo. {{{#!python class Message(models.Model): timestamp = models.DateTimeField(auto_now=True) # PostgreSQL, USE_TZ=True msg = models.CharField(max_length=254) timezone = models.CharField(max_length=64, default="UTC", help_text="pytz name") }}} {{{#!python def test_demo_bug(self): from ..models import Message import pytz from django.db.models.functions import Trunc, TruncSecond import mock from django.utils import timezone with patch.object(timezone, 'now', return_value=pytz.utc.localize(datetime(2017, 1, 1, 0, 0))): # we have info Message.objects.create( msg = "bar", timezone = 'UTC') Message.objects.create( msg = "foo", timezone = 'America/Los_Angeles') # we want to get it with "localized" timestamps: qs = Message.objects.all() partitions = [] # partition by timezones for tzname in ['UTC', 'America/Los_Angeles']: tz = pytz.timezone(tzname) _qs = qs.filter(timezone=tzname) # was but in test hardcoded "UTC" instead of `tzname` _qs = _qs.annotate(trunc_local_time=TruncSecond('timestamp', tzinfo=tz)) # could be Trunc_anything_ partitions.append(_qs) qs1, qs2 = partitions result = list(qs1.union(qs2)) for x in result: tz = pytz.timezone(x.timezone) print(x.msg) x.timestamp_trunc = x.timestamp.replace(microsecond=0) x.expected = x.timestamp_trunc.astimezone(tz) # this is the working way (but I wanted to get localization in DB layer) assert x.trunc_local_time == x.expected, "Error (msg: '{x.msg}'): {x.trunc_local_time} != {x.expected}".format(x=x) }}} Problem - different TZ offsets {{{ Failure Traceback (most recent call last): File "/home/jurgis/dev/new/tableair/sync_tableair-cloud/ta/api/bookables/tests/test_endpoints.py", line 689, i… nobody dz0 timezone, TruncBase, Union, PostgreSQL 0 0 0 0 0 0
30574 2019-06-18 03:55:51 2019-06-18 05:24:47 2019-06-24 06:04:22.552942 Unreviewed closed Database layer (models, ORM) New feature Normal master invalid Support join tables query over two tables without foreign key. support sql like {{{ SELECT * FROM ROLE INNER JOIN user_role ON ROLE . ID = user_role.role_id }}} or {{{ SELECT * FROM role r, user_role ur WHERE r.id = ur.role_id }}} thanks. nobody sazima orm 0 0 0 0 0 0
30573 2019-06-17 14:54:29 2019-06-17 15:08:39 2019-06-24 06:04:21.835434 Accepted assigned Documentation Cleanup/optimization Normal master   Don't assume that things are "easy"/"obvious"/"simple" in the docs. Telling people in documentation that something is "easy" or "obvious" when it isn't to them is very frustrating: It implies that the reader should have a level of understanding they don't have, and doesn't add anything of value in return. There are many occurrences of more-or-less obvious instances of this pattern in the Django docs, and I'd like to reduce the occurrence of this pattern. nobody rixx   0 1 0 0 0 0
30572 2019-06-17 12:30:35 2019-06-19 08:45:49 2019-06-24 06:04:21.107667 Ready for checkin closed Database layer (models, ORM) Bug Normal master fixed Composed queries cannot change the list of columns with values()/values_list(). Composed queries cannot change the list of columns when `values()/values_list()` is evaluated multiple times, e.g. {{{ >>> ReservedName.objects.create(name='a', order=2) >>> qs1 = ReservedName.objects.all() >>> print(qs1.union(qs1).values_list('name', 'order').get()) ('a', 2) >>> print(qs1.union(qs1).values_list('order').get()) ('a', 2) }}} (see [https://github.com/django/django/blob/6e8303d49ba55e7393c7ef5553b240ae0d2f0c00/django/db/models/sql/compiler.py#L428-L433 compiler.py#L428-L433]). felixxm felixxm   0 1 0 0 0 0
30571 2019-06-17 08:34:33 2019-06-18 11:27:49 2019-06-24 06:04:19.863478 Accepted closed Documentation Cleanup/optimization Normal 2.2 invalid Incorrect value of kwargs in pre_init signal documentation. I was working on a follower-following system for users. Model - {{{ class Follower(models.Model): follower = models.ForeignKey( User, on_delete=models.CASCADE, related_name='following') following = models.ForeignKey( User, on_delete=models.CASCADE, related_name='followers') follow_time = models.DateTimeField(auto_now=True) class Meta: unique_together = ('follower', 'following') }}} I created this `pre_init` signal (to prevent a user from following self, but details excluded)- {{{ @receiver(signals.pre_init, sender=user_models.Follower) def prevent_user_following_self(sender, *args, **kwargs): print(kwargs) }}} After this, I tried the following in Django shell - {{{ >>> import django >>> django.__version__ '2.2.2' >>> from django.contrib.auth.models import User >>> from users.models import Follower >>> a = User.objects.get(pk=1) >>> Follower(follower=a, following=a) {'signal': <django.db.models.signals.ModelSignal object at 0x7f431561dc88>, 'args': (), 'kwargs': {'follower': <User: admin>, 'following': <User: admin>}} }}} Here, `kwargs` contains the actual `kwargs` under a nested name. While according to the [https://docs.djangoproject.com/en/2.2/ref/signals/#pre-init documentation], the `print` here should give {{{ {'kwargs': {'follower': <User: admin>, 'following': <User: admin>} }}} hramezani singhpratyush signals 1 1 0 0 0 0
30570 2019-06-16 12:49:16 2019-06-17 09:58:50 2019-06-24 06:04:19.087123 Unreviewed closed Migrations Bug Normal master invalid Integrity errors in Django project with custom User model. I am setting up a new django(version 2.2) project and want to use custom user model. When I load fixtures data, it failed with error like below: django.db.utils.IntegrityError: Problem installing fixtures: insert or update on table "doctors_doctor" violates foreign key constraint "doctors_doctor_user_ptr_id_ba968804_fk_doctors_user_id" DETAIL: Key (user_ptr_id)=(1) is not present in table "doctors_user". From django document - https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#using-a-custom-user-model-when-starting-a-project I realized I did 'python manage.py migrate' before changing AUTH_USER_MODEL in settings.py. So I tried to delete all tables and redo 'python manage.py migrate', but it still hit this problem. I can see there is another ticket - https://code.djangoproject.com/ticket/23297 complaining the same issue, I follow the solution for it but not working. No idea why. nobody siriuslan   0 0 0 0 0 0
30569 2019-06-16 08:04:49 2019-06-16 11:48:18 2019-06-24 06:04:18.374617 Unreviewed closed Database layer (models, ORM) Bug Normal master duplicate Count and Sum annotation interfere with each other. While constructing a complex QuerySet, I ran into an issue where a Sum annotation on a relation would yield a different result whether or not another, seemingly unrelated Count annotation would be added. Everything needed to reproduce the issue is detailed here, including a dump of the database I used to illustrate the issue: https://stackoverflow.com/questions/56567841/django-count-and-sum-annotations-interfere-with-each-other nobody abey79   0 0 0 0 0 0
30568 2019-06-16 02:16:29 2019-06-17 05:44:24 2019-06-24 06:04:17.637058 Unreviewed closed Documentation Cleanup/optimization Normal master wontfix Definition of URLconf appears in tutorial 3; first mention is in tutorial 1. I believe it would be better to include this text: **A URLconf maps URL patterns to views.** in tutorial 1. nobody aboutmedicine   1 0 0 0 0 0
30567 2019-06-15 21:09:56 2019-06-17 06:00:24 2019-06-24 06:04:16.950958 Accepted new HTTP handling Cleanup/optimization Normal master   Start passing FileResponse.block_size to wsgi.file_wrapper. I noticed that Django's `FileResponse` class has a `block_size` attribute which can be customized by subclassing: https://github.com/django/django/blob/415e899dc46c2f8d667ff11d3e54eff759eaded4/django/http/response.py#L393 but it's not passed to `wsgi.file_wrapper`. Only the `filelike` object is passed: {{{ #!python response = environ['wsgi.file_wrapper'](response.file_to_stream) }}} (from: https://github.com/django/django/blob/415e899dc46c2f8d667ff11d3e54eff759eaded4/django/core/handlers/wsgi.py#L144 ) nobody cjerdonek block_size,wsgi.file_wrapper,FileResponse,wsgi 0 0 0 0 0 0
30566 2019-06-14 17:02:02 2019-06-15 21:03:16 2019-06-24 06:04:16.277291 Unreviewed closed contrib.postgres Bug Normal 2.2 wontfix Unable to do key lookup when a key is a number on PostgreSQL JSONB field Hi, Currently, if we try working for example with the following model using a JSONField (jsonb): {{{#!python from django.contrib.postgres.fields import JSONField from django.db import models class MyProduct(models.Model): attributes = JSONField(default=dict, blank=True) }}} With some dummy JSON data and a lookup the keys: {{{#!python json_data = {"123": ["82"], "hello": ["82"]} MyProduct.objects.create(attributes=json_data) MyProduct.objects.filter(attributes__123__has_key="82").first() # We get None, but we expect to match the product MyProduct.objects.filter(attributes__hello__has_key="82").first() # We get a match to the product }}} The two queries generated: {{{#!sql SELECT * FROM "product_myproduct" WHERE ("product_myproduct"."attributes" -> 123) SELECT * FROM "product_myproduct" WHERE ("product_myproduct"."attributes" -> 'hello') }}} So in the SQL queries we notice django passed the `123` lookup value as an integer instead of a string. Which, in PostgreSQL means that we want the JSONB value of the 123rd key–which is not what we want. I would expect that the lookup actually sends everything as a string, no matter what. And instead, having to use another lookup to get a key by index, e.g. `Q(field__key_at__1="something")`. The same thing happens for the `->>` operator (which inherits the issue from `->`). This issue happens at `django.contrib.postgres.fields.jsonb.KeyTransform`: {{{#!python class KeyTransform(Transform): operator = '->' nested_operator = '#>' def __init__(self, key_name, *args, **kwargs): super().__init__(*args, **kwargs) self.key_name = key_name def as_sql(self, compiler, connection): key_transforms = [self.key_name] previous = self.lhs while isinstance(previous, KeyTransform): key_transforms.insert(0, previous.key_name) previous = previous.lhs lhs, params = compiler.compile(previous) if len(key_transforms) >…   NyanKiyoshi json, jsonb, postgres 0 0 0 0 0 0
30565 2019-06-14 05:59:54 2019-06-20 09:50:41 2019-06-24 06:04:15.553044 Ready for checkin closed HTTP handling Bug Normal master fixed HttpResponseBase.close not called when using FileResponse / WSGI "file wrapper" object See [https://code.djangoproject.com/timeline?from=2019-06-15T02%3A26%3A50-05%3A00&precision=second comment #6] further down for the correct, updated description for this ticket. This ticket is to suggest doing for `StreamingHttpResponse` what #25725 did for `HttpReponse`, namely to close the underlying content iterator after it has been iterated over. Currently, if creating a `StreamingHttpResponse` from a file-like object, it doesn't seem like there's an obvious way to close the underlying file after the file has been streamed. And as [https://code.djangoproject.com/ticket/25725#comment:1 one of the comments] in #25725 pointed out, trying to do this in `StreamingHttpResponse.close()` isn't a good solution because WSGI servers can't be relied upon to call `close()`. I believe an alternative, more reliable solution may be to call `close()` immediately after the iterator has been exhausted (if `hasattr(value, 'close')` is true, as #25725 does). This is essentially what #25725 did for non-streaming `HttpResponse` objects. Here is that code: {{{ #!python def content(self, value): # Consume iterators upon assignment to allow repeated iteration. if hasattr(value, '__iter__') and not isinstance(value, (bytes, str)): content = b''.join(self.make_bytes(chunk) for chunk in value) if hasattr(value, 'close'): try: value.close() except Exception: pass else: content = self.make_bytes(value) }}} (from https://github.com/django/django/blob/1564e42ad397021093585147875a21dae1a3b3fc/django/http/response.py#L310-L319 ) In the streaming case, the content `value` argument could be wrapped something like so (inside `StreamingHttpResponse._set_streaming_content(value)`): {{{ #!python def iter_content(): yield from value if hasattr(value, 'close'): try: value.close() except Exception: pass new_value = iter_content() }}} Here is the current code for… cjerdonek cjerdonek HttpResponse, streaming, StreamingHttpResponse 0 1 0 0 0 0
30564 2019-06-12 18:50:48 2019-06-13 19:26:11 2019-06-24 06:04:14.918514 Unreviewed closed Database layer (models, ORM) Bug Normal master invalid Cannot create custom field that returns a queryset AND uses pre_save(). I tried creating a custom field that would store a string that was a list of pks, then return that as a queryset. (yes, I could probably have done it using a many2many field, but I was (am) trying to reduce the number of db queries for this. In any case, all seems to work OK until I implemented a def pre_save(self, model_instance, add) method on my custom field. What seems to be happening is that when the queryset comes back from the pre-save, it is run through the SQLInsertCompiler.prepare_value, which checks the value to see if it has a "resolve_expression" attrubute, which it assumes is then a SQL expression and then tries checking for "contains_column_references"... The QuerySet object DOES have the "resolve_expression" attribute, but does NOT have the others that are in the SQL expression objects. I suspect this doesn't come up much. My trace back Error Traceback (most recent call last): {{{ File "C:\Users\strohl\Documents\Project\Who\who_db\who_db_tests\test_model_methods.py", line 101, in setUp self.M1 = MixinTest.objects.create(name='M1') File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-packages\django\db\models\manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-packages\django\db\models\query.py", line 422, in create obj.save(force_insert=True, using=self.db) File "C:\Users\strohl\Documents\Project\Who\who_db\models.py", line 132, in save super(MixinTest, self).save(*args, **kwargs) File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-packages\django\db\models\base.py", line 741, in save force_update=force_update, update_fields=update_fields) File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-packages\django\db\models\base.py", line 779, in save_base force_update, using, update_fields, File "C:\Users\strohl\Documents\VirtualEnv\Who\lib\site-packages\django\db\models\base.py", line 870, in _save_table result = se… nobody dstrohl   0 0 0 0 0 0
30563 2019-06-12 16:37:00 2019-06-20 15:04:19 2019-06-24 06:04:14.288778 Accepted new Forms Cleanup/optimization Normal master   Optimize django.forms.widgets.Media.__add__. While working with another project that make extensive use of `django.forms.widgets.Media` I discovered that the fix for ticket #30153 has unintended consequences on the performance of `Media.__add__`. If the number of Media objects added grows beyond a certain point (not sure it may be machine specific) then the performance of all subsequent `Media.__add__` calls becomes terrible. This was causing page load times of several minutes on my development machine. I agree that you need to delay as long as possible as #30153 intends but it seems that there probably should be an upper bound on this so that performance does not suddenly decrease. Here is some sample code that can reproduce the issue: {{{ from django.forms import Media import datetime def create_media(MediaClass): '''Creates a simple Media object with only one or two items.''' return MediaClass(css={'all': ['main.css']}, js=['main.js']) start = datetime.datetime.now() media = create_media(Media) for i in range(100000): media = media + create_media(Media) print('100000 additions took: %s' % (datetime.datetime.now() - start)) }}} On my machine several runs of this code result in times between 1:35 - 1:44 (eg. 1 minute 35 seconds to 1 minute 44 seconds). However, taking away one zero from the number of media objects runs in under a second. Near as I can tell this has to do with the memory used to store these arrays and when it gets past a certain point the performance is awful. Since I am not sure if it is machine specific, for reference my machine is a i7-8700 with 64 GB RAM. Here is a sample that has a modified Media class that does not have theses issues: {{{ from django.forms import Media import datetime def create_media(MediaClass): '''Creates a simple Media object with only one or two items.''' return MediaClass(css={'all': ['main.css']}, js=['main.js']) class CustomMedia(Media): def __add__(self, other): combined = CustomMedia() if len(self._css_lists) + len(ot… nobody didorothy media 0 0 0 0 0 0
30562 2019-06-12 09:06:40 2019-06-12 09:06:40 2019-06-24 06:04:13.627177 Accepted new Documentation Cleanup/optimization Normal master   Document MariaDB support for GIS spatial lookups. I doc'd MariaDB support for GIS database functions in this [https://github.com/django/django/pull/11469 PR]. We should also check and document MariaDB support for spatial lookups (see [https://mariadb.com/kb/en/library/mysqlmariadb-spatial-support-matrix/ mariadb-spatial-support-matrix]). nobody felixxm   0 0 0 0 0 0
30561 2019-06-12 05:43:26 2019-06-12 07:44:40 2019-06-24 06:04:12.995396 Unreviewed closed Uncategorized New feature Normal 2.2 invalid Time for peppering user passwords in Django? Peppering passwords has been a controversial topic widely discussed in many stack overflow questions. Having ran my 20+ personal email addresses through HIBP page the findings are clear: all emails/passwords of mine that had been leaked fall in the following categories: SQL injections, mis-configured databases, exposed database admin panels or strayed database backup files. And that’s exactly what a pepper value in the hashing process is protecting from. Breaching the whole server with physical access to the file system is rather rare nowadays. According to this NIST document [ Digital Identity Guidelines Authentication and Lifecycle Management] https://pages.nist.gov/800-63-3/sp800-63b.html : “In addition, verifiers SHOULD perform an additional iteration of a key derivation function using a salt value that is secret and known only to the verifier.” So, why not in Django? nobody linluc   0 0 0 0 0 0
30560 2019-06-11 21:02:36 2019-06-12 05:21:57 2019-06-24 06:04:12.346432 Unreviewed closed Uncategorized Bug Normal master invalid Error: Submission rejected as potential spam. The spam filter is rejecting my actual ticket, message: Akismet says content is spam SpamBayes determined spam probability of 72.31% Everyone is getting oversensitive nowadays... nobody linluc   0 0 0 0 0 0
30559 2019-06-11 13:36:40 2019-06-11 15:03:34 2019-06-24 06:04:11.620489 Unreviewed closed Utilities Bug Normal 2.2 needsinfo Django 2.2 | Auto-reload doesn't detect changes in new apps. Just created a new project with Django CLI. My project split into multiple apps so the structure is like this: {{{ project app1/ .. migrations/ views/ __init__.py apps.py urls.py core/ .. migrations/ views/ __init__.py apps.py urls.py project/ settings/ __init__.py common.py development.py __init__.py urls.py wsgi.py }}} I'm using Docker to build the environment and make sure that both apps registered in the INSTALLED_APPS property. The problem is that the Django doesn't listen to app1 app, but only to core app. Also, if I add another folder under the core app, it's doesn't listen to this folder as well. I've changed the BASE_DIR property to support the new structure: {{{ BASE_DIR = os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) }}} Any suggestions? nobody ronzilca   0 0 0 0 0 0
30558 2019-06-11 12:46:58 2019-06-11 18:17:00 2019-06-24 06:04:09.797144 Unreviewed closed contrib.admin Cleanup/optimization Normal master duplicate Autocompletion should be disabled in the "Add user" form. In the admin: Home > Authentication and Authorization > Users > Add user There is a form with a "username", "password" and "password confirmation" input fields. In my case, the browser automatically fills in the first two inputs with my own username and password every time i need to create a new user. I think the HTML input elements in this form should have `autocomplete="off"` attribute set. I observe this in Django 1.11.21. Currently have no possibility to test in newer versions. I failed to find an existing ticket related to this issue. nobody vakorol admin, autocomplete, user 0 0 0 0 0 0
30557 2019-06-08 17:16:30 2019-06-20 04:44:57 2019-06-24 06:04:09.141268 Accepted assigned Database layer (models, ORM) Bug Normal master   order_by() a parent model crash when Meta.ordering contains expressions. Hi friends, During testing I discovered a strange bug when using a query expression for ordering during multi-table inheritance. You can find the full write up as well as reproducible test repository https://github.com/JonnyWaffles/djangoordermetabug. The bug occurs because the field is an OrderBy object, not a string, during get_order_dir. The linked stacktrace should make the issue obvious, but what I don't understand is why it only fails during test db setup, not during repl or script use. I wish I could help more and come up with a real solution. Hopefully, this is enough for someone wiser to find the culprit. ekeydar JonnyWaffles ordering 0 1 1 0 0 0
30556 2019-06-08 08:05:06 2019-06-10 09:32:11 2019-06-24 06:04:08.429804 Accepted closed contrib.auth Cleanup/optimization Normal master fixed ModelBackend.authenticate() shouldn't make a database query when username is None It's easier to explain my issue by adding a comment in the current implementation of `ModelBackend.authenticate()`: {{{ def authenticate(self, request, username=None, password=None, **kwargs): if username is None: username = kwargs.get(UserModel.USERNAME_FIELD) # At this point, username and password can be None, # typically if credentials are provided for another backend. # Continuing makes a useless database query and runs # the password hasher needlessly (which is expensive). try: user = UserModel._default_manager.get_by_natural_key(username) except UserModel.DoesNotExist: # Run the default password hasher once to reduce the timing # difference between an existing and a nonexistent user (#20760). UserModel().set_password(password) else: ... }}} ---- My suggestion is to shortcut with: {{{ if username is None or password is None: return }}} ---- I noticed this when writing assertNumQueries tests in django-sesame, which provides another authentication backend. I saw this query: {{{ sql = SELECT "auth_user"."id", "auth_user"."password", "auth_user"."last_login", "auth_user"."is_superuser", "auth_user"."username", "auth_user"."first_name", "auth_user"."last_name", "auth_user"."email", "auth_user"."is_staff", "auth_user"."is_active", "auth_user"."date_joined" FROM "auth_user" WHERE "auth_user"."username" IS NULL params = () }}} which doesn't make sense: username isn't a nullable field. ---- I thought about timing issues. `authenticate()` attempts to mask timing differences between existing and non-existing users. I don't think that concern extends to different authentication backends. Since they run different code, they will have timing differences anyway. Currently, in the scenario I'm describing, users are paying the time cost of `UserModel().set_password(password)`, then of their other auth… aaugustin aaugustin   0 1 0 0 0 0
30555 2019-06-08 06:12:03 2019-06-10 08:20:13 2019-06-24 06:04:07.794606 Unreviewed closed Migrations Bug Normal 2.2 wontfix Migration files generated do not follow PEP8 E501 rule Migration files, which are automatically created by Django on running `python manage.py makemigrations`, do not seem to follow PEP8 guidelines completely. The rule **E501 line too long** is not respected in the file. I have attached a file to support my arguments. nobody algomaster99   0 0 0 0 0 0
30554 2019-06-07 15:15:25 2019-06-10 17:27:33 2019-06-24 06:04:07.138727 Unreviewed closed Core (Other) Uncategorized Normal 2.2 invalid Excessive logging by autoreload in v 2.2.1 and 2.2.2 With these two versions I get over 3000 lines of logging by autoreload.py. It looks like this:: {{{ DEBUG 2019-06-07 09:47:15,927 autoreload Watching dir /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/import_export/locale with glob **/*.mo. DEBUG 2019-06-07 09:47:15,939 autoreload Watching dir /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/imagekit/locale with glob **/*.mo. DEBUG 2019-06-07 09:47:15,945 autoreload Watching dir /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/django_social_share/locale with glob **/*.mo. DEBUG 2019-06-07 09:47:15,953 autoreload Watching dir /Users/phoebe/Development/skorie/obstacles/locale with glob **/*.mo. System check identified no issues (0 silenced). June 07, 2019 - 09:47:18 Django version 2.2.2, using settings 'config.settings' Starting development server at http://127.0.0.1:8000/ Quit the server with CONTROL-C. DEBUG 2019-06-07 09:47:18,990 autoreload File /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_decimal.cpython-36m-darwin.so first seen with mtime 1545635091.0 DEBUG 2019-06-07 09:47:18,996 autoreload File /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/tablib/packages/__init__.py first seen with mtime 1559667881.475002 DEBUG 2019-06-07 09:47:18,996 autoreload File /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/reportlab/pdfbase/ttfonts.py first seen with mtime 1559667875.595854 DEBUG 2019-06-07 09:47:18,996 autoreload File /Users/phoebe/venv/skorie3/lib/python3.6/site-packages/stripe/api_resources/sku.py first seen with mtime 1559667881.135201 }}} 3000 more lines like this follow. Downgrading back to 2.2 and the logging is not displayed. The change was made here to add logging: https://github.com/django/django/commit/6754bffa2b2df15a741008aa611c1bb0e8dff22b Is there a way, or could a way be added, to turn this logging off? nobody phoebebright   0 0 0 0 0 0
30553 2019-06-07 12:34:07 2019-06-10 13:19:36 2019-06-24 06:04:06.519757 Ready for checkin closed Documentation Cleanup/optimization Normal master fixed Misleading logging documentation about disable_existing_loggers default value. In the documentation it's stated that: "If the disable_existing_loggers key in the LOGGING dictConfig is set to True (which is the default) ..." But we can see in [https://github.com/django/django/blob/master/django/utils/log.py] (master branch commit 10b44e4 at the time of writting) that it is set to False instead: {{{ ... DEFAULT_LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'filters': { ... }}} Moving "(which is the default)" in the paragraph should be enough: "If the disable_existing_loggers key in the LOGGING dictConfig is set to True then all loggers from the default configuration will be disabled. Disabled loggers are not the same as removed; the logger will still exist, but will silently discard anything logged to it, not even propagating entries to a parent logger. Thus you should be very careful using 'disable_existing_loggers': True; it’s probably not what you want. Instead, you can set disable_existing_loggers to False (which is the default) and redefine some or all of the default loggers; or you can set LOGGING_CONFIG to None and handle logging config yourself." Swat009 darthdragon disable_existing_loggers logging 1 1 0 0 0 0
30552 2019-06-07 09:20:07 2019-06-07 10:40:57 2019-06-24 06:04:05.907709 Accepted new GIS Bug Normal master   GEOSGeometry.reverse() loses SRID. Following code reproduces the bug. Haven't tested if it persists on Django 2.2. {{{ from django.contrib.gis.geos import GEOSGeometry linestring = GEOSGeometry('LINESTRING(0 1, 1 2)', srid=4326) assert linestring.srid == 4326 linestring.reverse() assert linestring.srid == 4326, 'SRID data is lost!' }}} nobody ssrebelious SRID, geometry, GIS 0 0 0 0 0 0
30551 2019-06-07 06:35:32 2019-06-07 09:18:23 2019-06-24 06:04:05.263953 Unreviewed closed Utilities Bug Normal master wontfix urlize on URL with incomplete query string adds equal sign. If one uses urlize in a template {{ work_urls|urlize }} on URLs such as http://www.isfdb.org/cgi-bin/pl.cgi?284309 an equal sign will be added http://www.isfdb.org/cgi-bin/pl.cgi?284309= The resulting URL fails at that site. Granted, I suspect that this is likely not a standard conform use of '?' by that site, but still unwanted behaviour. nobody jochengcd   0 0 0 0 0 0
30550 2019-06-07 00:53:55 2019-06-07 04:40:46 2019-06-24 06:04:04.361171 Accepted closed Testing framework Bug Normal master fixed TestClient's response.json() should decode content using the response charset. Right now, response.json() always decodes using utf-8. https://github.com/django/django/blob/8ba20d9071e9e1b8f2c81d4df977db4278342085/django/test/client.py#L646-L654 {{{ response._json = json.loads(response.content.decode(), **extra) }}} While this is frequently correct, the response may be any encoding. If it is a non-UTF-8 encoding, the content should be decoded as such. jdufresne jdufresne   0 1 0 0 0 0
30549 2019-06-06 15:18:16 2019-06-06 16:24:30 2019-06-24 06:04:03.431332 Unreviewed closed Error reporting Bug Normal 2.2 invalid Error while saving the user. Hello, community, I was creating a new user by the custom form with a custom author model inheriting default user model. I encountered this error while I was saving the user in database. Here are my all relevant files. **blograms/settings.py** {{{ """ Django settings for blograms project. Generated by 'django-admin startproject' using Django 2.2.1. For more information on this file, see https://docs.djangoproject.com/en/2.2/topics/settings/ For the full list of settings and their values, see https://docs.djangoproject.com/en/2.2/ref/settings/ """ import os from decouple import config # Build paths inside the project like this: os.path.join(BASE_DIR, ...) BASE_DIR = os.path.dirname(os.path.dirname(os.path.abspath(__file__))) # Quick-start development settings - unsuitable for production # See https://docs.djangoproject.com/en/2.2/howto/deployment/checklist/ # SECURITY WARNING: keep the secret key used in production secret! SECRET_KEY = config('SECRET_KEY') # SECURITY WARNING: don't run with debug turned on in production! DEBUG = True ALLOWED_HOSTS = [] # Application definition INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'phonenumber_field', 'widget_tweaks', 'blog.apps.BlogConfig', 'user.apps.UserConfig' ] MIDDLEWARE = [ 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', ] ROOT_URLCONF = 'blograms.urls' TEMPLATES = [ { 'BACKEND': 'django.template.backends.django.DjangoTemplates', 'DIRS': [os.path…   Shritesh99 password validation 0 0 0 0 0 0
30548 2019-06-06 13:19:49 2019-06-10 18:14:55 2019-06-24 06:04:02.779502 Accepted closed Database layer (models, ORM) Cleanup/optimization Normal master fixed Improve exceptions about mixed types in Expressions. The [https://github.com/django/django/blob/661e6cc2c97d9bcb45198be787409488e1825c90/django/db/models/expressions.py#L290 source which raises the exception] has enough information to say both what types were found, and which of those were unexpected, **and** probably have a useful `repr()` In the test suite, the unexpected output types encountered seem to be `DurationField` and `IntegerField`, so a more thorough message might be something like: `Expression repr(self) contained mixed types: DateField, DurationField. DurationField was unexpected; you must set the output_field= for this Expression to either DurationField(), DateField() or ...` (''??? I dunno, some concrete explanation of what the output_field has to be/implement if you're not going to use any of the builtins'') The merit of including the repr is arguable, as the `Expression` may not what the user put in (eg: in the test suite it always seems to be a `CombinedExpression(lhs, connector, rhs)`) but it gives more of a hint in a query which contains multiple expressions (either nested or separate) as to which one is actually causing the problem vs just being told "something was wrong. Put an output_field= everywhere until it ceases, your guess is as good as mine"; at the very least the word Expression could be replaced with the class name which is actually raising it. CruxBox kezabelle expressions orm 1 1 0 0 0 0
30547 2019-06-06 10:51:08 2019-06-20 08:46:09 2019-06-24 06:04:02.133460 Ready for checkin closed Documentation Cleanup/optimization Normal 2.2 fixed Document what happens during model validation with Meta.constraints. The current [https://docs.djangoproject.com/en/2.2/ref/models/constraints/ constraints reference] does not mention whether or not a **ValidationError** is raised during model validation if a constraint fails. The documentation only mentions that a database constraint is created. However, for the soon to be deprecated `unique_together`, there is a reference to model validation. As far as I can see, a `UniqueConstraint` causes `validate_unique()` to check for uniqueness and raises a **ValidationError**. But a `CheckConstraint` does not cause a **ValidationError** when the model is validated. I believe it's important to mention this in the documentation. Swat009 deegeenl constraints, UniqueConstraint 1 1 0 0 0 0
30546 2019-06-05 10:34:52 2019-06-06 06:45:08 2019-06-24 06:04:01.504909 Accepted closed Utilities Bug Normal master wontfix isinstance() call on SimpleLazyObject doesn't swallow evaluation exceptions on Python3. When running this little script: {{{ from django.utils.functional import * def a_func(): raise Exception('naah') slo = SimpleLazyObject(a_func) assert not isinstance(slo, type) }}} I'd expect the assertion to pass. It works as I'd expect it to work on Django 1.11 and Python 2.7. However, it does blow up with the {{{naah}}} exception on both Django 1.11 and 2.2 on Python 3.5 (also on Python 3.6 and 3.7) with the following traceback: {{{ Traceback (most recent call last): File "<input>", line 1, in <module> assert not isinstance(slo, type) File "... /lib/python3.5/site-packages/django/utils/functional.py", line 238, in inner self._setup() File "... /lib/python3.5/site-packages/django/utils/functional.py", line 386, in _setup self._wrapped = self._setupfunc() File "<input>", line 2, in a_func raise Exception('naah') Exception: naah }}} I'm not sure if this is by design, but the behaviour is certainly inconsistent on Py3 vs. Py2. I found this problem while trying to run our test suite on Python 3. Unittest framework does an obvious {{{if isinstance(obj, type) and issubclass(obj, case.TestCase):}}} check when collecting the test suite (see https://github.com/python/cpython/blob/v3.5.7/Lib/unittest/loader.py#L122), so when we have a module-level {{{SimpleLazyObject}}} (obviously it wraps a different function than the one I've given here, but also a failing one) it gets unexpectedly evaluated and raises an exception, which prevents us from even gathering the tests on Python 3. I'm not really sure why this is happening. After some brief debugging, it looks like {{{isinstance}}} function on Python 3 is accessing the {{{__class__}}} attribute (which is wrapped with the {{{new_method_proxy}}} function - see https://github.com/django/django/blob/2.2.2/django/utils/functional.py#L348) causing evaluation of the underlying function, whereas on Python 2.7 {{{isinstance}}} doesn't seem to do that. nobody slafs SimpleLazyObject lazy evaluation 0 0 0 0 0 0
30545 2019-06-05 09:59:16 2019-06-05 10:08:45 2019-06-24 06:04:00.871725 Unreviewed closed contrib.admin Bug Normal master duplicate admin.E108 is raised on fields accessible only via instance. As part of startup django validates the ModelAdmin's list_display list/tuple for correctness (django.admin.contrib.checks._check_list_display). Having upgraded django from 2.07 to 2.2.1 I found that a ModelAdmin with a list display that used to pass the checks and work fine in admin now fails validation, preventing django from starting. A PositionField from the django-positions library triggers this bug, explanation why follows. {{{ from django.db import models from position.Fields import PositionField class Thing(models.Model) number = models.IntegerField(default=0) order = PositionField() }}} {{{ from django.contrib import admin from .models import Thing @admin.register(Thing) class ThingAdmin(admin.ModelAdmin) list_display = ['name', 'order'] }}} Under 2.2.1 this raises an incorrect admin.E108 message saying "The value of list_display[1] refers to 'order' which is not a callable...". Under 2.0.7 django starts up successfully. If you change 'name' to 'no_name' or 'order' to 'no_order' then the validation correctly complains about those. The reason for this bug is commit https://github.com/django/django/commit/47016adbf54b54143d4cf052eeb29fc72d27e6b1 which was proposed and accepted as a fix for bug https://code.djangoproject.com/ticket/28490. The problem is while it fixed that bug it broke the functionality of _check_list_display_item in other cases. The rationale for that change was that after field=getattr(model, item) field could be None if item was a descriptor returning None, but subsequent code incorrectly interpreted field being None as meaning getattr raised an AttributeError. As this was done **after** trying field = model._meta.get_field(item) and that failing that meant the validation error should be returned. However, after the above change if hasattr(model, item) is false then we no longer even try field = model._meta.get_field(item) before returning an error. The reason hasattr(model, item) is false in the case of a PositionField is its __get__ method throws an e… nobody ajcsimons   0 1 0 0 0 0
30544 2019-06-05 09:37:11 2019-06-05 09:51:39 2019-06-24 06:04:00.255617 Unreviewed closed Documentation Cleanup/optimization Normal 2.1 duplicate Django 2.1 release notes don't mention the BooleanField(blank=False) default change. In https://github.com/django/django/commit/5fa4f40f45fcdbb7e48489ed3039a314b5c961d0#r30206325 the `blank=True` default for `BooleanField` was removed, effectively turning it into `blank=False` because of the super class. This change is not mentioned in the Django 2.1 release notes. My tests caught it because I have some introspection going on, I don't think it will break any actual usage, but it left me wondering why that test started failing. nobody sergei-maertens booleanfield, documentation, release notes 1 0 0 0 0 0
30543 2019-06-05 06:58:13 2019-06-06 08:22:41 2019-06-24 06:03:59.609974 Accepted assigned Core (System checks) Bug Normal master   admin.E108 is raised on fields accessible only via instance. As part of startup django validates the ModelAdmin's list_display list/tuple for correctness (django.admin.contrib.checks._check_list_display). Having upgraded django from 2.07 to 2.2.1 I found that a ModelAdmin with a list display that used to pass the checks and work fine in admin now fails validation, preventing django from starting. A PositionField from the django-positions library triggers this bug, explanation why follows. {{{ from django.db import models from position.Fields import PositionField class Thing(models.Model) number = models.IntegerField(default=0) order = PositionField() }}} {{{ from django.contrib import admin from .models import Thing @admin.register(Thing) class ThingAdmin(admin.ModelAdmin) list_display = ['number', 'order'] }}} Under 2.2.1 this raises an incorrect admin.E108 message saying "The value of list_display[1] refers to 'order' which is not a callable...". Under 2.0.7 django starts up successfully. If you change 'number' to 'no_number' or 'order' to 'no_order' then the validation correctly complains about those. The reason for this bug is commit https://github.com/django/django/commit/47016adbf54b54143d4cf052eeb29fc72d27e6b1 which was proposed and accepted as a fix for bug https://code.djangoproject.com/ticket/28490. The problem is while it fixed that bug it broke the functionality of _check_list_display_item in other cases. The rationale for that change was that after field=getattr(model, item) field could be None if item was a descriptor returning None, but subsequent code incorrectly interpreted field being None as meaning getattr raised an AttributeError. As this was done **after** trying field = model._meta.get_field(item) and that failing that meant the validation error should be returned. However, after the above change if hasattr(model, item) is false then we no longer even try field = model._meta.get_field(item) before returning an error. The reason hasattr(model, item) is false in the case of a PositionField is its __get__ method throw… ajcsimons ajcsimons   0 1 0 1 0 0
30542 2019-06-04 20:22:27 2019-06-05 07:18:25 2019-06-24 06:03:58.964805 Accepted closed Database layer (models, ORM) Bug Release blocker 2.2 fixed Float-valued aggregations and annotations with filters fail with AttributeError When any float-valued aggregation or annotation (`Avg`, `StdDev`, `Variance`) is used with the `filter=` keyword argument, the following exception is raised: {{{ AttributeError: 'WhereNode' object has no attribute 'output_field' }}} For example, these queries all fail with this error: {{{#!python Speaker.objects.annotate(average=Avg('speakerscore__score', filter=Q(speakerscore__ghost=False))) Speaker.objects.annotate(average=StdDev('speakerscore__score', filter=Q(speakerscore__ghost=False))) Team.objects.annotate(average=Avg('debateteam__teamscore__score', filter=Q(debateteam__teamscore__forfeit=False))) }}} The error seems to be raised irrespective of what's in the database (''e.g.'', it's raised even for an empty database). However, it doesn't affect aggregations like `Sum`, `Max` or `Min` that don't use `NumericOutputFieldMixin`. Also, queries that don't use the `filter=` keyword in the aggregation work fine. The exception in question is raised from line 46 of django/db/models/functions/mixins.py, which looks for an `output_field` attribute of every element of `self.get_source_expressions()`, where `self` is the object containing `NumericOutputFieldMixin`, in this case `Avg` or some other subclass of `Aggregate`. But `Aggregate.get_source_expressions()` includes `self.filter` in its list, and (post-compilation) `self.filter` is a `WhereNode`, which doesn't have an `output_field` attribute. This issue is new in version 2.2. Everything works fine in version 2.1 (where I believe `NumericOutputFieldMixin` didn't exist, or at least wasn't on the MRO for `Avg`, `StdDev` or `Variance`). === Minimal reproducible example In a blank (or any) project, insert in models.py: {{{#!python from django.db.models import Model, FloatField, BooleanField class Book(Model): price = FloatField() fiction = BooleanField() }}} then run migrations and in `python manage.py shell`: {{{ $ python manage.py shell Python 3.6.7 (default, Oct 22 2018, 11:32:17) [GCC 8.2.0] on linux Type "help", "co… tienne-B czlee aggregation, annotation, filter 0 1 0 0 0 0
30541 2019-06-04 13:28:16 2019-06-05 06:01:26 2019-06-24 06:03:58.345968 Unreviewed closed Testing framework Bug Normal master invalid Django MultiDB tests not loading fixtures as expected. I've recently upgraded from Django 2.0 to Django 2.2 and have found the fixture loading logic appears to have changed. The core issue seems to be related to the introduction of `databases` Given the following test case: {{{ class BaseTestCase(TestCase, TestUtilsMixin): databases = '__all__' fixtures = [ 'data_x1.default.yaml', 'data_x2.default.yaml', 'data_x3.default.yaml', 'data_x4.default.yaml', 'data_x5.default.yaml', 'data_x6.default.yaml' ] }}} I would expect data_xx fixtures to only to be loaded into the 'default' alias, but it appears to be loading into all connections defined in `DATABASES`, resulting in the following error {{{ Error Traceback (most recent call last): File "django/db/backends/utils.py", line 84, in _execute return self.cursor.execute(sql, params) File "django/db/backends/oracle/base.py", line 510, in execute return self.cursor.execute(query, self._param_generator(params)) cx_Oracle.DatabaseError: ORA-00942: table or view does not exist The above exception was the direct cause of the following exception: Traceback (most recent call last): File "django/core/serializers/pyyaml.py", line 73, in Deserializer yield from PythonDeserializer(yaml.load(stream, Loader=SafeLoader), **options) File "django/core/serializers/python.py", line 147, in Deserializer obj = base.build_instance(Model, data, using) File "django/core/serializers/base.py", line 266, in build_instance default_manager.db_manager(db).get_by_natural_key(*natural_key).pk File "managers.py", line 15, in get_by_natural_key return self.get(name=name) File "django/db/models/manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "django/db/models/query.py", line 402, in get num = len(clone) File "django/db/models/query.py", line 256, in __len__ self._fetch_all() File "django/db/models/query.py", line 1242, in _fetch_all … nobody VackarAfzal   0 0 0 0 0 0
30540 2019-06-03 12:37:21 2019-06-03 13:41:35 2019-06-24 06:03:57.738704 Unreviewed closed Database layer (models, ORM) Bug Normal master invalid Django left join with AND condition. I have 4 models Category, Product,Photo,ProductLikeDislike. I am left joining 3 of them except Category. **Models:** {{{ class Category(models.Model): name = models.CharField(max_length = 200, db_index = True) slug = models.SlugField(max_length = 200, db_index = True, unique = True) class Meta: ordering = ('name',) verbose_name = 'category' verbose_name_plural = 'categories' class Product(models.Model): category = models.ForeignKey(Category ,on_delete=models.CASCADE) name = models.CharField(max_length = 200, db_index = True) slug = models.SlugField(max_length = 200, db_index = True) description = models.TextField(blank = True) price = models.DecimalField(max_digits = 10, decimal_places = 2 ) created = models.DateTimeField(auto_now_add=True) updated = models.DateTimeField(auto_now=True) contact= models.BigIntegerField(default=None,blank=True, null=True) created_by = models.CharField(max_length = 200, default=None,blank=True, null=True) uploaded_by_id = models.IntegerField(default=0) status = models.IntegerField(default=0) mark_as_sold = models.IntegerField(default=0) class Meta: ordering = ('-created',) index_together = (('id','slug'),) class Photo(models.Model): reference_id = models.ForeignKey(Product, null=True,on_delete=models.CASCADE) photo_type = models.CharField(max_length = 70, db_index = True) file = models.FileField(upload_to='photos/',default='NoImage.jpg') cover_photo_flag = models.CharField(default=0,max_length = 5, db_index = True) uploaded_at = models.DateTimeField(auto_now_add=True) uploaded_by_id = models.IntegerField(default=0) status = models.IntegerField(default=0) class Meta: ordering = ('-uploaded_at',) class ProductLikeDislike(models.Model): product_id = models.ForeignKey(Product,models.SET_DEFAULT,default=0) product_liked_by_id = models.Foreig… nobody chiragsoni2401 FilteredRelation 0 0 0 0 0 0
30539 2019-06-03 05:05:56 2019-06-03 05:49:39 2019-06-24 06:03:57.133178 Unreviewed closed Template system Bug Normal master worksforme Django - “with / as” to fill block is not working. I am trying to not repeat myself in Django, but use the same content for 2 blocks. The content is static so I would rather have in in my templates than sending them through views. This was the solution I found : {{{ {% with "My title" as title %} {% block TitleOne %}{{ title }}{% endblock TitleOne %} {% block TitleTwo %}{{ title }}{% endblock TitleTwo %} {% endwith %} }}} In a templates that extends a second one that uses the blocks TitleOne and TitleTwo . But it does not work. If I write it like : {{{ {% block TitleOne %}"My title"{% endblock TitleOne %} {% block TitleTwo %}"My title"{% endblock TitleTwo %} }}} It works perfectly. But of course it s not DRY. If I write it like : {{{ {% with "My title" as title %} {% block TitleOne %}"My title"{% endblock TitleOne %} {% block TitleTwo %}{{ title }}{% endblock TitleTwo %} {% endwith %} }}} Only the 1st one displays right. But not DRY as well. Tried another way suggested in Django's docs : https://docs.djangoproject.com/en/2.2/ref/templates/builtins/#with {{{ {% with title="My title" %} {% block TitleOne %}"My title"{% endblock TitleOne %} {% block TitleTwo %}{{ title }}{% endblock TitleTwo %} {% endwith %} }}} Only the 1st one displayed too.. (I am using Django 2.2.1, Python 3.7.3) nobody Jay-Dai templates, blocks, with 0 0 0 0 0 0
30538 2019-06-02 16:51:23 2019-06-03 07:32:29 2019-06-24 06:03:56.498428 Unreviewed closed Utilities Bug Normal master wontfix Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin. Hi everyone. I wanted to highlight an inconsistent slug generation behaviour that I noticed. So, for generating slugs, there are two ways I can go about doing it. One way is by using the [https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/utils/text.py#L393 django.utils.text.slugify()] function to create a slug. This behaviour allows us to create a default for a model field by modifying the save() function, etc. Another way, if you are using Model Admin, is by using the [https://docs.djangoproject.com/en/2.2/ref/contrib/admin/#django.contrib.admin.ModelAdmin.prepopulated_fields prepopulated_fields] to generate a slug. The relevant javascript function seems to be found [https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/contrib/admin/static/admin/js/urlify.js#L161 here]. Interestingly, and pretty obviously after viewing the differences between the two codes, they result in slightly different slugs. For a string like `How To Maintain Coke Diet` will have the following inconsistencies: Via [https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/utils/text.py#L393 django.utils.text.slugify()]: `how-to-maintain-coke-diet` Via prepopulated_fields: `how-maintain-coke-diet` On closer analysis, it seems that this was the case because of the following code in [https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb5859ffff2ceb5/django/contrib/admin/static/admin/js/urlify.js#L161 django/contrib/admin/static/admin/js/urlify.js]: {{{ // Remove English words only if the string contains ASCII (English) // characters. if (!hasUnicodeChars) { var removeList = [ "a", "an", "as", "at", "before", "but", "by", "for", "from", "is", "in", "into", "like", "of", "off", "on", "onto", "per", "since", "than", "the", "this", "that", "to", "up", "via", "with" ]; var r = new RegExp('\\b(… nobody nomenklature slugify prepopulated fields 0 0 0 0 0 0
30537 2019-06-02 15:42:50 2019-06-03 05:20:51 2019-06-24 06:03:55.758093 Unreviewed closed Database layer (models, ORM) Bug Normal 2.0 duplicate ForeignKey: inconsistent handling of referenced obj. id. In short: if referenced obj. is saved after attaching to a referencing obj. its id field (i.e. ''<refrerenced_obj>''_id) there remains None. In details: {{{ class ReferencedObj(Model): ... class ReferencingObj(Model): referenced_obj = ForeignKey(ReferencedObj) ... x = ReferencedObj() y = ReferencingObj() y.referenced_obj = x x.save() y.save() -----→ NOT NULL constraint failed: ..._referencingobj.referenced_obj_id }}} Thats happens because **referenced_obj_id** field is not bound to the underlying **referenced_obj.id** nobody AliakseiMi ORM, ForeignKey, NOT NULL constraint, inconsistency 0 0 0 0 0 0
30536 2019-06-01 19:15:12 2019-06-23 20:54:32 2019-06-24 06:03:54.982667 Accepted new Core (Other) New feature Normal master   Allow running custom logic in django.setup(). Make django.setup() idempotent, and add setting DJANGO_SETUP_CALLABLE so that actual setup operations can be overridden in a project. This is especially useful when testing, since test runners (eg. pytest-django) often configure the framework by themselves, before the end user can patch it with mockups and other early-time tweaks. nobody pakal setup 0 1 1 0 0 0
30535 2019-06-01 11:59:58 2019-06-03 05:11:20 2019-06-24 06:03:54.286155 Unreviewed closed Internationalization Bug Normal master invalid Czech plural-forms is incorrect in translations. The plural czech translations for "This password is too short. It must contain at least %(min_length)d character." are broken in django versions 2.1.0 and higher for n >= 5. Can be easily reproduced: - create django project - set LANGUAGE_CODE = 'cs-CZ' and USE_I18N = True - open shell - import django.utils.translation.ngettext - run ngettext("This password is too short. It must contain at least %(min_length)d character.", "This password is too short. It must contain at least %(min_length)d characters.", 5) - returns original english message instead of the localized one Translations for n <= 4 work correctly. I thing this bug was introduced in https://github.com/django/django/commit/3e01aab5335394201701710d7fcd67f523878c5b#diff-59a8943fbf4bd5fd330ef8d22e40bd3f , but am not completely sure, since the commit was created after the 2.1.0 release. Could this be backported? Frankly, I'm not even sure why this change was necessary - in czech there are only 3 forms of the message needed - they differ in the last word 'znak' (which means character) thusly: - 1 znak - 2, 3, 4 znaky - 5 and more znaků and also 0 znaků I tested this behavior on python 3.6.8 and 3.7.3 and django 2.1.0 and 2.1.8. nobody Incanus3   1 0 0 0 0 0
30534 2019-05-31 16:06:44 2019-06-04 06:59:19 2019-06-24 06:03:53.676325 Accepted closed Forms Bug Normal master fixed Allow `cleaned_data` to overwrite fields' default values. See comments here: https://github.com/django/django/pull/7068/files#r289432409 Currently, when submitting a form, if 'some_field' isn't in the data payload (e.g. it wasn't included in the form, perhaps because its value is derived from another field), and 'some_field' has a default value on the model, it cannot be overwritten with 'self.cleaned_data'. This does not really follow the paradigm of modifying data in 'cleaned_data'. It requires the user to copy and overwrite the raw data submitted with the form. RobertAKARobin RobertAKARobin forms, models 1 1 0 0 0 0
30533 2019-05-31 11:47:23 2019-06-03 06:34:06 2019-06-24 06:03:53.058303 Unreviewed closed Database layer (models, ORM) Bug Normal master wontfix Delete cascade on large tables can cause process termination on PostgreSQL. == Scenario - Model A has a foreign key to model B with on_delete=CASCADE - many B objects - execute `B.objects.delete()` Expected result: - deletion works Actual result: - when there are many B objects to delete (in our case it was 14M rows), the database process gets killed before completion: {{{ 2019-05-28 19:17:42.237 CEST [1]: [2-1] db=,user= LOG: server process (PID 12911) was terminated by signal 9: Killed 2019-05-28 19:17:42.238 CEST [1]: [3-1] db=,user= DETAIL: Failed process was running: DELETE FROM "a" WHERE "a"."b_id" IN (17271, 17272, 17273, 17274, 17275, <truncated enormous list> }}} - with a smaller database it worked (2M rows) == Analysis It seems the related objects A get deleted in one query with an unbound `IN (...)` list of B objects. In fact this pattern already lead to an issue with the sqlite backend ([#link0]: sqlite supports only 999 parameters per query) This was fixed in django 1.8 by adding batch query [#link1], [#link2] with a size specified per backend: - sqlite: 999 [#link3] - oracle: 64k [#link4] - all others (base): not limited [#link5] == Workaround As a temporary workaround we monkey patched the `connection` instance own `bulk_batch_size` and limit to 64k. {{{#!python import types def monkey_patch_connection_bulk_batch_size(connection): def limited_bulk_batch_size(self, fields, objs): """ PostgreSQL can crash with too many parameters in a query e.g. 'DELETE FROM x WHERE x.y IN (...large list...)' => limit to 64k """ return 2**16 connection.ops.bulk_batch_size = types.MethodType(limited_bulk_batch_size, connection.ops) }}} It worked great in our case: we used it in a migration. workaround limitations: - no idea where to monkey patch for global usage - no idea how to choose the bulk size value - didn't handle the more complex computation using `fields` and `objs` parameters (Related remark: this is for deleting the related objects, then for the main objects deletion django al… nobody thomas-riccardi queryset delete cascade batch bulk_batch_size postgresql crash 0 0 0 0 0 0
30532 2019-05-30 20:02:10 2019-05-30 20:19:09 2019-06-24 06:03:52.427049 Unreviewed closed Database layer (models, ORM) Cleanup/optimization Normal master duplicate Union queryset should raise on filter() and exclude(). If a queryset results from a union() it would help to have filter() and exclude() raise instead of return unpredictable results. I propose a _is_union_result bool flag on querysets to track this. /charles thayer https://www.google.com/search?q=django+unions+filter+bug+site:stackoverflow.com&sa=X&ved=2ahUKEwiksOCAg8TiAhWBop4KHXPZDMMQrQIoBDAAegQIABAM nobody cgthayer   0 0 0 0 0 0
30531 2019-05-30 14:24:12 2019-05-30 15:16:29 2019-06-24 06:03:51.823104 Unreviewed closed Database layer (models, ORM) Bug Normal 2.2 invalid Exception when creating an inherited model object with existing base The following intuitively right causes an exception: {{{ class Base(models.Model): v = models.IntegerField() class Derived(Base): base = models.OneToOneField(Base, on_delete=models.CASCADE, primary_key=True) class BugTestCase(TestCase): def setUp(self): self.base = Base.objects.create(v=0) def test_bug(self): Derived.objects.create(base=self.base) }}} Here it is: {{{ django.db.utils.IntegrityError: NOT NULL constraint failed: mytest_base.v }}} It should work in the expected way not to raise an exception. In the project I am developing now, I am going to write a workaround with a raw SQL query :-( I will attach full test source. nobody vporton   0 0 0 0 0 0
30530 2019-05-29 15:13:38 2019-05-30 11:30:09 2019-06-24 06:03:51.215616 Unreviewed closed Core (URLs) Bug Normal master wontfix url `path` accepts newlines in various places. Consider the following simplified `urls.py`. {{{ from django.http import HttpResponse from django.urls import path def path_view(request): return HttpResponse('<pre>===&gt;' + request.path + '&lt;===</pre>') def render_something(request, something): return HttpResponse('<pre>===&gt;' + something + '&lt;===</pre>') urlpatterns = [ path('hello/', path_view), path('foo/<something>/bar/', render_something), ] }}} By accessing `http://localhost:8000/hello/%0a`, it's clear that the newline is accepted in the URL. This is because the underlying logic uses a `$` in the regular expression, instead of `\Z`.. By accessing `http://localhost:8000/foo/hello%0aworld/bar/`, it's clear that the default `str` converter accepts anywhere in the segment. This is because it uses a negative match `[^/]+`, which happily accepts a newline character (both `%0a` and `%0d`). I propose changing the `$` to `\Z`, and the negative match to `[^/\r\n]+`. I would also suggest changing the documentation on the `re_path` to suggest `\Z` instead of `$`, though that may be more controversial. nobody sjoerdjob   0 0 0 0 0 0
30529 2019-05-29 12:58:44 2019-05-29 14:26:06 2019-06-24 06:03:50.597049 Unreviewed closed Database layer (models, ORM) Bug Normal 2.2 invalid SQLCompiler.as_sql should return parameters as a list (and not as a tuple) As wished by Adam (https://github.com/adamchainz/django-mysql/issues/50#issuecomment-496665473) I will give it a try and do a PR to turn those tuples into lists. Even the method comments in https://github.com/django/django/blob/master/django/db/models/sql/compiler.py all state: Return the SQL string and **list** of parameters. nobody tuky   0 0 0 0 0 0
30528 2019-05-29 12:58:01 2019-05-31 09:28:02 2019-06-24 06:03:49.970997 Unreviewed closed contrib.admin Bug Normal 2.1 duplicate Django Admin adds Javascript in different sequences Hi, we're using Django on a large scale intern company project. We found an issue with using inlines. On Creation of a new Model the Admin interface with inlines works fine (jQuery gets loaded on top of the page, inline.js follows way down in the head section). But after saving this model and reopening it, the inline.js is loaded directly after jQuery and posts following error: {{{ TypeError: undefined is not an object (evaluating '$.fn') }}} I made a little workaround with my own javascript just calling the inline.js if that didn't load. But that can't be the solution. Do you know whats the problem or what we could do? Regards Fabian nobody FreakyTea admin, inline, js 0 0 0 0 0 0
30527 2019-05-29 09:49:11 2019-06-14 12:05:09 2019-06-24 06:03:49.348446 Unreviewed closed Migrations Bug Normal master invalid Problem with creating migrations for subclassed field changes. `makemigrations` gives out 'No changes detected' for changes on a sub-subclass of CharField (only tested with this field). When creating a field as seen below (DummyCharField), a new migration only gets created if `kwargs['max_length'] = 255` is wrapped inside an `if`. {{{#!python class BaseDummyCharField(models.CharField): def __init__(self, *args, **kwargs): if 'max_length' not in kwargs: kwargs['max_length'] = 64 super().__init__(*args, **kwargs) class DummyCharField(BaseDummyCharField): def __init__(self, *args, **kwargs): # Without the if 'makemigrations' does not recognize changes. # Previous max_length (in initial migration) is 64. if 'max_length' not in kwargs: kwargs['max_length'] = 255 super().__init__(*args, **kwargs) class DummyModel(models.Model): dummy = DummyCharField() }}} (Also reproducable in version 2.0.6, maybe others as well.) nobody wfehr   0 0 0 0 0 0
30526 2019-05-29 02:42:38 2019-05-29 07:06:44 2019-06-24 06:03:48.696993 Unreviewed closed Migrations Bug Normal master invalid migration to UUID id field doesn't properly convert integers (SQLite). This may be present in other DBs, but I've noticed it with SQLite under Django 2.2.1. Steps to reproduce: 1. Start a model with an implicit integer id, and create and run the migration: {{{#!python from django.db import models class Something(models.Model): name = models.CharField(max_length=32) }}} 2. Then create one instance via the shell (`python manage.py shell`): {{{#!python from uuidbug.models import Something s = Something(name="One") s.save() }}} In the DB it looks like this (can use `python manage.py dbshell`): {{{ sqlite> .headers on sqlite> select * from uuiditem_something; name|id One|1 }}} 3. Edit the model to use UUIDs: {{{#!python import uuid from django.db import models class Something(models.Model): name = models.CharField(max_length=32) id = models.UUIDField(primary_key=True, default=uuid.uuid4, editable=False) }}} 4. After creating and running the migration, add another instance: {{{#!python from uuidbug.models import Something s = Something(name="After UUID-ization") s.save() }}} DB now looks like this: {{{ sqlite> select * from uuidbug_something; name|id One|1 After UUID-ization|693e1942d7d142289bb9fb3664f2c11a }}} Note that the id for the first instance has not been converted to a UUID properly. If you try to access the objects, you get an error: {{{#!python >>> Something.objects.all() Traceback (most recent call last): File "<console>", line 1, in <module> File "/Users/martin/Connery/opencc-backend/venv/lib/python3.7/site-packages/django/db/models/manager.py", line 82, in manager_method return getattr(self.get_queryset(), name)(*args, **kwargs) File "/Users/martin/Connery/opencc-backend/venv/lib/python3.7/site-packages/django/db/models/query.py", line 653, in first for obj in (self if self.ordered else self.order_by('pk'))[:1]: File "/Users/martin/Connery/opencc-backend/venv/lib/python3.7/site-packages/django/db/models/query.py", line 274, in __iter__ self._fetch_all() Fi… nobody kemokid UUID 0 0 0 0 0 0
30525 2019-05-28 23:57:03 2019-05-29 00:23:42 2019-06-24 06:03:48.019428 Unreviewed closed Core (Management commands) Uncategorized Normal 1.11 invalid --skip-checks management command needs backported This commit is missing from the 1.11.x branch. Please backport it. Commit: https://github.com/django/django/commit/6866c91b638de5368c18713fa851bfe56253ea55 1.11.x Branch: https://github.com/django/django/blob/stable/1.11.x/django/core/management/base.py#L326 nobody dougfultz skip-checks 1 1 0 0 0 0
30524 2019-05-28 18:48:42 2019-05-28 21:58:35 2019-06-24 06:03:47.389355 Unreviewed closed Uncategorized Bug Normal 2.2 invalid on_delete doesn't work properly with MySql. Model: {{{ class Attempt(models.Model): student = models.ForeignKey(Student, models.CASCADE, related_name='quiz_attempts',null=False) quiz = models.ForeignKey(Quiz,on_delete=models.CASCADE,related_name='quiz_attempts') score = models.FloatField() over = models.BooleanField(default=False) date = models.DateTimeField(auto_now_add=True) currquestion = models.ForeignKey(Question,null=True,default=None,on_delete=models.SET_NULL) class Meta: indexes = [ models.Index(fields=['student']), models.Index(fields=['quiz']), ] }}} Table created in MySql: {{{ CREATE TABLE `classroom_attempt` ( `id` int(11) NOT NULL AUTO_INCREMENT, `score` double NOT NULL, `over` tinyint(1) NOT NULL, `date` datetime(6) NOT NULL, `currquestion_id` int(11) DEFAULT NULL, `quiz_id` int(11) NOT NULL, `student_id` int(11) NOT NULL, PRIMARY KEY (`id`), KEY `classroom_a_student_1a21bc_idx` (`student_id`), KEY `classroom_a_quiz_id_eef64a_idx` (`quiz_id`), KEY `classroom_attempt_currquestion_id_545301ef_fk_classroom` (`currquestion_id`), CONSTRAINT `classroom_attempt_currquestion_id_545301ef_fk_classroom` FOREIGN KEY (`currquestion_id`) REFERENCES `classroom_question` (`id`), CONSTRAINT `classroom_attempt_quiz_id_e227b203_fk_classroom_quiz_id` FOREIGN KEY (`quiz_id`) REFERENCES `classroom_quiz` (`id`), CONSTRAINT `classroom_attempt_student_id_a4dc81cd_fk_classroom` FOREIGN KEY (`student_id`) REFERENCES `classroom_student` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------------------+--------------------- }}} As you can notice models.CASCADE is not applied. nobody dheeraj135 Foreign Key 0 0 0 0 0 0
30523 2019-05-28 18:20:18 2019-05-29 07:43:57 2019-06-24 06:03:46.748055 Accepted closed Utilities Bug Release blocker 2.2 fixed StatReloader does not update file times if notify_file_changed() is triggered. If notify_file_changed is triggered then the files mtime is not updated. This can cause notify_file_changed() to be triggered many times if a translation is changed. orf orf   0 1 0 0 0 0
30522 2019-05-28 16:02:37 2019-05-29 05:47:55 2019-06-24 06:03:46.110812 Unreviewed closed Database layer (models, ORM) Bug Normal master invalid How to use Custom install Sqlite3 in Django. I have installed "Python 3.6.2" and " Django 2.2.1", when I tried to do "python manage.py runserver" and I received error like below: django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is required (found 3.6.20). So I have custom installed "SQLite3 3.28.0" then set ENVs for LD_LIBRARY_PATH and LD_RUN_PATH to use the latest SQLite3. In Shell and Python IDLE or normal SQL script, am able to access "3.28.0" versions Sqlite. But when running manage.py, am getting the error below: conn = Database.connect(**conn_params) django.db.utils.NotSupportedError: URIs not supported Please try once the steps I have followed and then to consider to keep or closing the ticket by referencing "28376" 1. Custom install SQLite3 2. Set env for PATH , LD_LIBRARY_PATH and LD_RUN_PATH 3. Try accessing sqlite3 in Python scripts to check the versions. If you are able to connect, kindly share the steps to overcome the issue from our side. nobody rmananthraj sqlite 0 0 0 0 0 0
30521 2019-05-28 15:23:27 2019-06-07 06:18:25 2019-06-24 06:03:45.448429 Accepted closed Error reporting Cleanup/optimization Normal master fixed Default error webpages are not correctly-formed html pages. The default page served for the 404 error in "DEBUG=False" mode is (django 2.2.1): <h1>Not Found</h1><p>The requested resource was not found on this server.</p> I would expect that by default, a full webpage is sent to the user, thus: <html> <body> <h1>Not Found</h1><p>The requested resource was not found on this server.</p> </body> </html> In "DEBUG=True" mode, the webpage served is correct html: <!DOCTYPE html> <html lang="en"> ... </html> alej0varas RubenGarcia   1 1 0 0 0 0
30520 2019-05-28 10:53:11 2019-06-04 09:02:54 2019-06-24 06:03:44.801465 Accepted closed contrib.admin Bug Normal master fixed ModelForm with field without label crashes when used in InlineModelAdmin. As per [https://stackoverflow.com/questions/56156039/extra-field-of-modelform-without-label-does-not-render-in-inlinemodeladmin this] and [https://stackoverflow.com/questions/54511865/django-extra-fields-in-custommodelform-is-giving-unable-to-lookuup-error-i that] S.O. issues, although a ModelForm with an extra field which has no label works at the model's change view, it raises an error when the same ModelForm is used for an inline: models.py: {{{#!python class Parent(models.Model): pass class Child(models.Model): parent = models.ForeignKey(Parent, on_delete=models.PROTECT) }}} forms.py: {{{#!python class ChildForm(forms.ModelForm): extra_field = forms.CharField() class Meta: model = Child fields = '__all__' }}} admin.py: {{{#!python @admin.register(models.Child) class ChildAdmin(admin.ModelAdmin): '''The ModelForm renders as expected''' form = forms.ChildForm class ChildInline(admin.TabularInline): '''Here the ModelForm without a label in the extra field, will raise error''' model = models.Child form = forms.ChildForm @admin.register(models.Parent) class ParentAdmin(admin.ModelAdmin): inlines = (ChildInline,) }}} {{{#!python File "/home/venv/lined/lib/python3.7/site-packages/django/contrib/admin/utils.py", line 364, in label_for_field raise AttributeError(message) AttributeError: Unable to lookup 'extra_field' on Child or ChildInline }}} Full error message: https://pastebin.com/89MUGchf jonesambrosi raratiru   1 1 0 0 0 0
30519 2019-05-28 09:47:20 2019-05-28 10:03:33 2019-06-24 06:03:44.159216 Accepted new GIS Cleanup/optimization Normal master   Add sanity checks to Django RasterField deserialization for rasters that are not fully managed through Django. When using the RasterField for raster columns in PostGIS that are not fully managed by Django, the raster table could be of a type that is not supported by the GDALRaster. Examples are out-of-db rasters, or rasters that have an unsupported pixeltype (single bit rasters, 2 or 4 bit rasters). A paragraph about this could be added to the documentation, and some sanity checks could be added to the raster deserialization here: https://github.com/django/django/blob/master/django/contrib/gis/db/backends/postgis/pgraster.py This ticket is related to https://code.djangoproject.com/ticket/30489 and https://github.com/django/django/pull/11381 nobody yellowcap raster 0 0 0 0 0 0
30518 2019-05-28 09:00:22 2019-05-28 09:08:44 2019-06-24 06:03:43.517538 Unreviewed closed Database layer (models, ORM) Bug Normal master duplicate Multiple Count annotation with filter doesn't work properly. Lets have following models {{{ class User(models.Model): pass class Subscription(models.Model): user = models.ForeignKey(User, models.CASCADE) valid_to = models.DateTimeField() class SubscriptionToAuthor(models.Model): user = models.ForeignKey(User, models.CASCADE) valid_to = models.DateTimeField() }}} then annotate on only one related model works fine {{{ # this is ok User.objects.annotate( subscribed_authors=Count('subscriptiontoauthor', filter=Q(subscriptiontoauthor__valid_to__gt=now)) ) }}} or {{{ # this is ok User.objects.annotate( subscribed_newspapers=Count('subscription', filter=Q(subscription__valid_to__gt=now)) ) }}} but Count returns incorrect (too big) count numbers when both annotations are used on single query set {{{ # wrong result User.objects.annotate( subscribed_authors=Count('subscriptiontoauthor', filter=Q(subscriptiontoauthor__valid_to__gt=now)) ).annotate( subscribed_newspapers=Count('subscription', filter=Q(subscription__valid_to__gt=now)) ) }}} nobody farin annotate 0 0 0 0 0 0
30517 2019-05-28 01:44:54 2019-05-28 06:06:57 2019-06-24 06:03:42.793097 Unreviewed closed Core (Cache system) New feature Normal master wontfix Add Redis cache backend. I think that it would be best to have built-in support for Redis caching in Django, as it's getting more popular and has other use cases than just caching. And I found that most of the features overlap with memcached. So I think that it might be better to refactor BaseMemcachedCache to be base for KV engines, and use it for both Memcached and Redis, to reduce code duplication. I would like to start discussion about best approach adding Redis support into Django. Also I can work on this if approved. nobody dulmandakh redis cache 0 0 0 0 0 0
30516 2019-05-28 01:20:10 2019-05-29 06:31:08 2019-06-24 06:03:42.153655 Accepted closed Utilities Bug Release blocker 2.2 fixed Autoreloader crashes on re-raising exceptions with custom signature. How to reproduce: In apps.py, put the following code, and update __init__.py or the settings to have this app config be used. {{{ from django.apps import AppConfig class MyException(Exception): def __init__(self, value: str, other_thing: str): super().__init__(value) self.ot = other_thing class Config(AppConfig): name = "myapp" verbose_name = "My App" def ready(self): raise MyException("foo", "bar") }}} The problem is that `django.utils.autoreload.raise_last_exception` tries to construct a new exception of the same type, with 1 argument (the original exception). The consequence is that you just get a TypeError exception about ` __init__() missing 1 required positional argument: 'other_thing'` and it completely masks the original exception. Note that this behavior was changed in c8720e7696ca41f3262d5369365cc1bd72a216ca, it used to just re-raise the exception value. I don't know why it was changed. I noticed this issue as a result of https://gitlab.com/alantrick/django-vox/issues/9 orf alantrick autoreload 0 1 0 0 0 0
30515 2019-05-28 00:50:56 2019-06-07 08:11:05 2019-06-24 06:03:41.513952 Unreviewed closed Documentation Cleanup/optimization Normal master wontfix Document django.shortcuts.resolve_url. The documentation for django.shortcuts currently doesn't document `resolve_url`. However, the section for [https://docs.djangoproject.com/en/2.2/topics/http/shortcuts/#redirect redirect] pretty much explains how `resolve_url` works. It would be helpful to document `resolve_url` and state that `redirect` uses `resolve_url` in its process. nobody laymonage   1 0 0 0 0 0
30514 2019-05-27 12:59:33 2019-05-30 08:14:14 2019-06-24 06:03:40.866772 Unreviewed closed CSRF Bug Normal 2.1 needsinfo Occasional CSRF cookie not set Django 2.1 Hi all, We recently noticed an increase in the number of 403 errors we were getting in our server, mainly the `CSRF cookie not set.` We added more logging and investigated it to see if they were legitimate errors (requests that should cause a 403 error), some are, however we discovered that a lot of them aren't. There were normal requests coming from normal users, we would get around 30 of these failed requests in a given day, it would happen randomly across random devices, browsers and urls and has been quite difficult to reproduce. We Copy/Pasted the source code of `middleware.csrf` and added it to our code base as a custom middleware to add more logging and get a better traceback in sentry when the error occurs, to get more insights on issue, we learned the following: - For some reason the token was not set. `csrf_token = request.META.get('CSRF_COOKIE’)` returns `None`, - We know that if a user got the error, if they simply refresh the page things would work perfectly fine, this means that setting the token works, but sometimes it does not - We know that it is not a problem with our frontend since we also got this error in the django admin including non-login requests - We tried clearing all the expired sessions, and set `CSRF_USE_SESSIONS = True`, in hopes of it improving the situation, but nothing much has changed. With all that being said, we narrowed down the problem to the `_get_token(self, request)` method, since we set `CSRF_USE_SESSIONS = True` it tries to fetch the token from the session using `request.session.get(CSRF_SESSION_KEY)`, but that would return `None`. A very interesting thing we noticed is that the CSRF token **is** present in the actual request's header under `HTTP_X_CSRFTOKEN`. So we modified the method to fetch the CSRF token from the header as a fallback to see if it would fix the issue: {{{ def _get_token(self, request): if settings.CSRF_USE_SESSIONS: try: token_from_session = request.session.get(CSRF_SESSION_KEY) except Attribut… nobody yusuf-musleh   0 0 0 0 0 0
30513 2019-05-27 11:54:15 2019-05-27 14:36:07 2019-06-24 06:03:40.221612 Unreviewed closed Migrations Bug Normal master duplicate Impossible migration (with a change of model base) is not noticed. 1. Extract the attached Git repository. (It contains among other migrations automatically created with `makemigrations`, one of the migrations was made with choosing the option `2) Ignore for now, and let me handle existing rows with NULL myself (e.g. because you added a RunPython or RunSQL operation to handle NULL values in a previous data migration)`.) 2. Try to migrate. You see the error: {{{ django.db.utils.OperationalError: foreign key mismatch - "mytest_project" referencing "mytest_token" }}} The Django bug is that this error is noticed too late: on the stage of `migrate` not where it should have been noticed, the stage of `makemigrations`. The bug appears when I try to replace (in two stages as described by tags below, because Django does not allow to do it in one stage): {{{ class Token(models.Model): pass }}} with {{{ class BaseToken(models.Model): pass class Token(BaseToken): base = models.OneToOneField(BaseToken, on_delete=models.CASCADE, primary_key=True) }}} This happens because this change unnoticed by Django replaces what is used as the primary key for `Token`. Note that sequential stages of change in the Git repository are marked by tags `before-change`, `change-middle`, `after-change`. nobody vporton   0 0 0 0 0 0
30512 2019-05-26 16:28:41 2019-06-13 15:30:48 2019-06-24 06:03:39.579812 Ready for checkin closed Core (Mail) Cleanup/optimization Normal master fixed Update mail backend to use modern standard library parsing approach. {{{ django.core.mail.message.sanitize_address }}} uses {{{ email.utils.parseaddr }}} from the standard lib. On Python 3, {{{ email.headerregistry.parser.get_mailbox() }}} does the same, and is less error-prone. ewjoachim ewjoachim   0 1 0 0 0 0
30511 2019-05-26 13:17:41 2019-06-22 05:09:51 2019-06-24 06:03:38.919997 Accepted assigned Database layer (models, ORM) New feature Normal master   Support Identity columns on PostgreSQL. We are currently working on a Django / Postgresql 11 project. We needed an adjustment for the postgres module because of its compatibility with .NET Framework and dataset generation. In postgres 10/11 there is the new feature identity column called GENERATED AS IDENTITY instead of serial. column_name type GENERATED {ALWAYS | BY DEFAULT} AS IDENTITY [(sequence_option)] We have created a module based on db.backends.postgres that adds 2 new django model fields. I would like implement the new feature into pyodbc module or new module for postgres 10/11 useful for later versions of django. Adjustments only in base.py (line 70ff): {{{ data_types = { 'IdentityAutoField': 'integer', 'IdentityBigAutoField': 'bigint', }}} and schema.py, def column_sql () (line 178ff): {{{ # Primary key / unique outputs if field.primary_key: sql + = "PRIMARY KEY" if field.get_internal_type () in ("IdentityAutoField", "IdentityBigAutoField"): sql + = "GENERATED ALWAYS AS IDENTITY" elif field.unique: sql + = "UNIQUE" }}} I can also send our code best regards Michael Kany mischakany mischakany postgres generated identity 0 0 0 0 0 0
30510 2019-05-25 23:42:46 2019-05-27 05:27:21 2019-06-24 06:03:38.282134 Accepted assigned Database layer (models, ORM) Bug Normal master   bulk_create() crashes with mixed length arguments on LOB fields on Oracle. Consider the below model, containing one LOB field {{{ from django.db import models class Bar(models.Model): baz = models.TextField() }}} When you make a `bulk_create` request, e.g. `Bar.objects.bulk_create([b0, b1])` you will get generate a query like below. `INSERT INTO "PROJECT_BAR" ("BAZ") SELECT * FROM (SELECT :arg1 col_0 FROM DUAL UNION ALL SELECT :arg0 FROM DUAL)` This works most of the time, however at some point logic was added to automatically convert a string's type to `Database.CLOB` when it exceeded 4000 bytes from a normal string literal type. When this conversion happens for some of the arguments but not all of the arguments in the ephemeral table Oracle will complain that the type of the column of the unified table is inconsistent and fail the query. E.g. the following will fail {{{ Bar.objects.bulk_create([Bar(baz='aaa'), Bar(baz='a'*5000)]) }}} Generating the error `django.db.utils.DatabaseError: ORA-01790: expression must have same datatype as corresponding expression` Note that when both objects have a long or both have a short `baz` field this query succeeds. I'm working on a patch msg555 msg555 oracle bulk_create 0 1 0 0 0 0
30509 2019-05-25 16:19:32 2019-06-01 00:52:46 2019-06-24 06:03:37.635095 Accepted new HTTP handling Cleanup/optimization Normal master   Various FileResponse fixes and changes As I've mentioned in PR 11011 (of ticket #30196) I noticed a couple of issues with the way FileResponse is created (and other minor things), and in this ticket I'll try to list and fix them. For initial clarity, this PR consists of 2 commits. The first is a set of tests, most of which show invalid behavior in some quite specific cases based on current code. The second contains my initial proposed fixes. 1. tests: a. {{{test_file_from_buffer_absolute_name}}}:\\ test ends in an error, because {{{set_headers()}}} attempts to read the 'name' property if the filename (which can be overwritten by the custom filename) is recognized as an absolute path by os.path. b. {{{test_file_from_buffer_explicit_type1}}}, {{{test_file_from_buffer_explicit_type2}}}:\\ of these 2, first test shows the way to explicitly set {{{Content-Type}}} header of the response, while the second shows that in a case that the set value matches the beginning of the default value ({{{'text/html; charset=%s' % self.charset}}}), it will consider that value as unset and proceed to read the content type from the file. c. {{{test_file_from_named_buffer1}}}, {{{test_file_from_named_buffer2}}}:\\ tests show how you can easily 'fool' FileResponse into thinking it's dealing with an actual file, resulting in incorrect header values if such file exists (1) or an error if it doesn't (2). d. {{{test_file_from_disk_custom_name}}}, {{{test_file_from_disk_as_attachment_custom_name}}}:\\ these are just 2 missing tests to check whether giving a file a custom name even works. 2. fixes: a. ignored custom filename before setting {{{Content-Length}}} and changed the following condition a bit to fix 1.a. and the error case of 1.c. b. added a {{{self._default_content_type}}} flag to {{{HttpResponseBase.__init__()}}} to mark that there was no {{{content_type}}} explicitly set, so it should be figured out from the file, if possible, to fix 1.b. c. * added a way to tell the filelike object's size if it's neither a file nor has a {{{getbuffer}}… nobody ShingenPizza FileResponse 0 1 0 0 0 0
30508 2019-05-25 15:05:20 2019-05-27 05:15:50 2019-06-24 06:03:36.970181 Unreviewed closed Documentation Cleanup/optimization Normal master invalid Add Password Reset Via Email to documentation. Add How to do Password Reset Via Email to : [https://docs.djangoproject.com/en/2.2/howto/ How-to guides] or [https://docs.djangoproject.com Django documentation] nobody MrAli   0 0 0 0 0 0
30507 2019-05-24 10:23:59 2019-05-27 18:32:53 2019-06-24 06:03:36.121621 Ready for checkin assigned contrib.admin Cleanup/optimization Normal master   Update admin's jQuery to 3.4.X. We should bump admin's jQuery to the latest 3.4.X release before 3.0 alpha 1 release. dulmandakh felixxm   0 1 0 0 0 0
30506 2019-05-24 09:42:06 2019-06-23 13:57:06 2019-06-24 06:03:35.478441 Unreviewed closed Core (Management commands) Bug Normal master needsinfo Auto-reloading with StatReloader very intermittently throws "ValueError: embedded null byte". Raising this mainly so that it's tracked, as I have no idea how to reproduce it, nor why it's happening. It ultimately looks like a problem with Pathlib, which wasn't used prior to 2.2. Stacktrace: {{{ Traceback (most recent call last): File "manage.py" ... execute_from_command_line(sys.argv) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 381, in execute_from_command_line utility.execute() File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 375, in execute self.fetch_command(subcommand).run_from_argv(self.argv) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/base.py", line 323, in run_from_argv self.execute(*args, **cmd_options) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/commands/runserver.py", line 60, in execute super().execute(*args, **options) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/base.py", line 364, in execute output = self.handle(*args, **options) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/commands/runserver.py", line 95, in handle self.run(**options) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/core/management/commands/runserver.py", line 102, in run autoreload.run_with_reloader(self.inner_run, **options) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 577, in run_with_reloader start_django(reloader, main_func, *args, **kwargs) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 562, in start_django reloader.run(django_main_thread) File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 280, in run self.run_loop() File "/Userz/kez/path/to/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 286, in run_loop … nobody kezabelle   0 0 0 0 0 0
30505 2019-05-23 18:19:19 2019-06-04 12:58:03 2019-06-24 06:03:34.821751 Accepted closed Migrations Cleanup/optimization Normal master fixed Ordering of Field.choices is significant for makemigrations makemigrations regards the ordering of Field.choices as significant. The docs require Field.choices to be an iterable, but not to be well-ordered. If Field.choices is not well-ordered, then almost every run of makemigrations will treat the model as changed, even without changes to the code. The ordering of Field.choices is not significant anywhere else, except as a cosmetic detail in the admin. This bug even occurs in {{{ ACTIVITY_TYPES = set(['Create', 'Update', 'Delete']) [....] f_type = models.CharField( max_length=255, choices=[(x,x) for x in ACTIVITY_TYPES], ) }}} I would have expected the value of Field.choices here to be well-ordered (and sorted) but makemigrations still flags this as changed every time. I can put a test case together if you like. caioariede marnanel   0 1 0 0 0 0
30504 2019-05-23 16:56:17 2019-05-24 06:28:28 2019-06-24 06:03:34.183849 Accepted closed Documentation Cleanup/optimization Normal master fixed Order of arguments on redirect incorrect on documentation. On the documentation for the redirect shortcut at https://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect It shows `redirect(to, permanent=False, *args, **kwargs)` when it should be `redirect(to, *args, permanent=False, **kwargs)` sp1rs amrish_beauhurst redirect, documentation, parameters 1 1 0 0 0 0
30503 2019-05-23 11:25:39 2019-05-23 11:50:27 2019-06-24 06:03:33.528198 Unreviewed closed HTTP handling Bug Normal master invalid ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host. I am getting below issue while processing paytm payments and returning back to my Django application. Below is my code in views.py {{{ from django.http import HttpResponse from django.shortcuts import render from django.views.decorators.csrf import csrf_exempt from django.contrib.auth.decorators import login_required from django.conf import settings from paytm import checksum from paytm.models import PaymentHistory @login_required def payment(request): CALLBACK_URL = settings.HOST_URL + settings.PAYTM_CALLBACK_URL order_id = checksum.__id_generator__() bill_amount = request.POST['amount'] if bill_amount: data_dict = { 'MID':settings.PAYTM_MERCHANT_ID, 'ORDER_ID':order_id, 'TXN_AMOUNT': bill_amount, 'CUST_ID':request.user.email, 'INDUSTRY_TYPE_ID':settings.PAYTM_INDUSTRY_TYPE, 'WEBSITE': settings.PAYTM_WEBSITE, 'CHANNEL_ID':'WEB', 'CALLBACK_URL':CALLBACK_URL, } param_dict = data_dict param_dict['CHECKSUMHASH'] = checksum.generate_checksum(data_dict, settings.PAYTM_MERCHANT_KEY) return render(request,"paytm/payment.html",{'paytmdict':param_dict}) return HttpResponse("Bill Amount Could not find. ?bill_amount=10") @login_required @csrf_exempt def response(request): if request.method == 'GET': return render(request, 'paytm/home.html') elif request.method == "POST": data_dict = {} for key in request.POST: data_dict[key] = request.POST[key] verify = checksum.verify_checksum(data_dict, settings.PAYTM_MERCHANT_KEY, data_dict['CHECKSUMHASH']) if verify: for key in request.POST: if key == "BANKTXNID" or key == "RESPCODE": if request.POST[key]: data_dict[key] = int(request.POST[key]) else: … nobody msrajkumar95 paytm payments 0 0 0 0 0 0
30502 2019-05-23 10:19:53 2019-06-21 04:46:19 2019-06-24 06:03:32.858237 Accepted closed contrib.admin Bug Normal master invalid Admin interface hangs on models with "parentNode" field . if you have a relation named "parentNode", the django admin page gets stuck/unresponsive (eternal loop in js code?) when adding/editing a row with the problematic relation. Example model that triggers the bug: {{{#!python class Node(models.Model): name = models.CharField(max_length=255) # "parentNode" as the foreign key name causes problems with Django admin js code =( parentNode = models.ForeignKey('self', blank=True, null=True, on_delete=models.CASCADE) }}} nobody jait   0 0 0 0 0 0
30501 2019-05-23 06:37:12 2019-05-23 18:34:47 2019-06-24 06:03:32.172142 Ready for checkin closed Database layer (models, ORM) Bug Normal master fixed Queryset ordering and Meta.ordering are mutable on expressions with reverse(). Queryset order and `Meta.ordering` are mutable with `reverse()`. Bug revealed by running `./runtests.py ordering.test --reverse` (reproduced at a2c31e12da272acc76f3a3a0157fae9a7f6477ac). It seems that test added in f218a2ff455b5f7391dd38038994f2c5f8b0eca1 wasn't correct because order mutates on queryset execution in [https://github.com/django/django/blob/a2c31e12da272acc76f3a3a0157fae9a7f6477ac/django/db/models/sql/compiler.py#L253 SQLCompiler.get_order_by()]. felixxm felixxm   0 1 0 0 0 0
30500 2019-05-22 19:01:03 2019-05-31 12:44:09 2019-06-24 06:03:31.511410 Unreviewed closed Error reporting Cleanup/optimization Normal 2.2 invalid Error reporting returns a circular import error on a python formatting error, and does not restart the development server In Django 2.2.1, a python formatting error, such as a NameError or IndentationError will give the error shown below: {{{ Exception in thread django-main-thread: Traceback (most recent call last): File "/home/runner/.local/lib/python3.5/site-packages/django/urls/resolvers.py", line 581, in url_patterns iter(patterns) TypeError: 'module' object is not iterable During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3.5/threading.py", line 914, in _bootstrap_inner self.run() File "/usr/lib/python3.5/threading.py", line 862, in run self._target(*self._args, **self._kwargs) File "/home/runner/.local/lib/python3.5/site-packages/django/utils/autoreload.py", line 54, in wrapper fn(*args, **kwargs) File "/home/runner/.local/lib/python3.5/site-packages/django/core/management/commands/runserver.py", line 117, in inner_run self.check(display_num_errors=True) File "/home/runner/.local/lib/python3.5/site-packages/django/core/management/base.py", line 390, in check include_deployment_checks=include_deployment_checks, File "/home/runner/.local/lib/python3.5/site-packages/django/core/management/base.py", line 377, in _run_checks return checks.run_checks(**kwargs) File "/home/runner/.local/lib/python3.5/site-packages/django/core/checks/registry.py", line 72, in run_checks new_errors = check(app_configs=app_configs) File "/home/runner/.local/lib/python3.5/site-packages/django/core/checks/urls.py", line 13, in check_url_config return check_resolver(resolver) File "/home/runner/.local/lib/python3.5/site-packages/django/core/checks/urls.py", line 23, in check_resolver return check_method() File "/home/runner/.local/lib/python3.5/site-packages/django/urls/resolvers.py", line 398, in check for pattern in self.url_patterns: File "/home/runner/.local/lib/python3.5/site-packages/django/utils/functional.py", line 80, in __get__ res = instance.__dict__[self.name] = self.…   runner15 error reporting, error, circular import 0 0 0 0 0 0
30499 2019-05-22 14:43:23 2019-05-27 09:44:25 2019-06-24 06:03:30.754291 Accepted closed Uncategorized New feature Normal master invalid PasswordResetView should be allowed to set `domain_override`. Actually if the domain of the link sent within the mail needs to be overridden, the view `form_valid` method should be replaced or the view should subclass an own instance of PasswordContextMixin. I think allowing to inject a custom domain from `urls.py` would help with DRY in this case as the new domain can be passed when declaring `PasswordResetView.as_view(domain_override="mynew.domain.com"`) I am thinking of adding simply domain_override = None as new class attribute and adding it to opts: {{{ class PasswordResetView(PasswordContextMixin, FormView): ... domain_override = None def form_valid(self, form): opts = { 'use_https': self.request.is_secure(), 'token_generator': self.token_generator, 'from_email': self.from_email, 'email_template_name': self.email_template_name, 'subject_template_name': self.subject_template_name, 'request': self.request, 'html_email_template_name': self.html_email_template_name, 'extra_email_context': self.extra_email_context, 'domain_override': self.domain_override, } form.save(**opts) return super().form_valid(form) }}} MattBlack85 MattBlack85   0 1 0 0 0 0
30498 2019-05-22 09:07:09 2019-05-22 20:18:22 2019-06-24 06:03:30.112522 Accepted closed Utilities Cleanup/optimization Normal master fixed lazy() class preparation is not being cached correctly. Doing `self.__prepared = True` changes the instance, but the intention is to change the class variable: https://github.com/django/django/blob/888fdf182e164fa4b24aa82fa833c90a2b9bee7a/django/utils/functional.py#L82 This makes functions like gettext_lazy, format_lazy and reverse_lazy a lot slower than they ought to be. Regressed in Django 1.8 (b4e76f30d12bfa8a53cc297c60055c6f4629cc4c). Using this micro-benchmark on Python 3.7: {{{#!python import cProfile from django.utils.functional import lazy def identity(x): return x lazy_identity = lazy(identity, int) cProfile.run("for i in range(10000): str(lazy_identity(1))") }}} Before: {{{ 910049 function calls in 0.208 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.010 0.010 0.208 0.208 <string>:1(<module>) 10000 0.001 0.000 0.001 0.000 bench.py:4(identity) 10000 0.005 0.000 0.010 0.000 functional.py:105(__str__) 10000 0.004 0.000 0.188 0.000 functional.py:159(__wrapper__) 10000 0.007 0.000 0.185 0.000 functional.py:76(__init__) 10000 0.089 0.000 0.178 0.000 functional.py:83(__prepare_class__) 10000 0.004 0.000 0.005 0.000 functional.py:99(__cast) 1 0.000 0.000 0.208 0.208 {built-in method builtins.exec} 840000 0.087 0.000 0.087 0.000 {built-in method builtins.hasattr} 46 0.000 0.000 0.000 0.000 {built-in method builtins.setattr} 1 0.000 0.000 0.000 0.000 {method 'disable' of '_lsprof.Profiler' objects} 10000 0.002 0.000 0.002 0.000 {method 'mro' of 'type' objects} }}} After: {{{ 50135 function calls in 0.025 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 1 0.008 0.008 0.025 0.025 <string>:1(<module>) 10000 0.001 0.0… bluetech bluetech   0 1 0 0 0 0
30497 2019-05-22 06:54:14 2019-05-24 06:24:13 2019-06-24 06:03:29.481611 Accepted closed Testing framework Bug Normal master fixed assertXMLEqual fails on document type declaration. Prepare Django project: {{{ $ python -m venv env $ . ./env/bin/activate $ pip install django $ django-admin startproject p1 $ cd p1 }}} Create `p1/tests.py`: {{{ #!python from django.test import TestCase class MyTestCase(TestCase): def test_assert_xml_equal(self): xml1 = ''' <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root SYSTEM "example.dtd"> <root /> ''' xml2 = ''' <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE root SYSTEM "example.dtd"> <root /> ''' self.assertXMLEqual(xml1, xml2) }}} Run the tests: {{{ $ ./manage.py test Creating test database for alias 'default'... F ====================================================================== FAIL: test_assert_xml_equal (p1.tests.MyTestCase) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/yuri/_/1/env/lib/python3.7/site-packages/django/test/testcases.py", line 843, in assertXMLEqual result = compare_xml(xml1, xml2) File "/home/yuri/_/1/env/lib/python3.7/site-packages/django/test/utils.py", line 598, in compare_xml return check_element(want_root, got_root) AttributeError: 'DocumentType' object has no attribute 'tagName' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/yuri/_/1/p1/p1/tests.py", line 15, in test_assert_xml_equal self.assertXMLEqual(xml1, xml2) File "/home/yuri/_/1/env/lib/python3.7/site-packages/django/test/testcases.py", line 846, in assertXMLEqual self.fail(self._formatMessage(msg, standardMsg)) AssertionError: First or second argument is not valid XML 'DocumentType' object has no attribute 'tagName' ---------------------------------------------------------------------- Ran 1 test in 0.002s FAILED (failures=1) Destroying test database for alias 'default'... System check identified no issues (0 silen… caioariede x-yuri   0 1 0 0 0 0
30496 2019-05-21 01:54:08 2019-05-21 04:02:32 2019-06-24 06:03:28.851049 Unreviewed closed Forms Bug Normal 2.2 invalid Broken order for class Media Djnango 2.2.1, python3.7 {{{ #!python class ProductAdmin(admin.ModelAdmin): class Media: js = ['admin_ext/init.js', 'admin_ext/classes.js', 'admin_ext/common.js'] }}} I get this html {{{ <script type="text/javascript" src="/frm-admin/jsi18n/"></script> <script type="text/javascript" src="/static/admin/js/vendor/jquery/jquery.js"></script> <script type="text/javascript" src="/static/admin_ext/init.js"></script> <script type="text/javascript" src="/static/ckeditor/ckeditor/ckeditor.js"></script> <script type="text/javascript" src="/static/admin_ext/files/images_inline.js"></script> <script type="text/javascript" src="/static/admin/js/jquery.init.js"></script> <script type="text/javascript" src="/static/admin_ext/classes.js"></script> <script type="text/javascript" src="/static/admin_ext/contrib/ckeditor/widget.js"></script> <script type="text/javascript" src="/static/admin/js/core.js"></script> <script type="text/javascript" src="/static/admin_ext/common.js"></script> <script type="text/javascript" src="/static/admin/js/inlines.js"></script> <script type="text/javascript" src="/static/admin/js/admin/RelatedObjectLookups.js"></script> <script type="text/javascript" src="/static/admin/js/actions.js"></script> <script type="text/javascript" src="/static/admin/js/urlify.js"></script> <script type="text/javascript" src="/static/admin/js/prepopulate.js"></script> <script type="text/javascript" src="/static/admin/js/vendor/xregexp/xregexp.js"></script> }}} {{{"/static/admin_ext/init.js"}}} goes after {{{ "/static/admin/js/vendor/jquery/jquery.js"}}}, but i expect {{{"/static/admin/js/jquery.init.js"}}} and other django scripts django==2.1.8 - it`s ok forms.widgets.Media.merge changed in 2.2 version nobody hale01 media widget 0 0 0 0 0 0
30495 2019-05-20 23:48:04 2019-05-21 14:04:38 2019-06-24 06:03:28.230740 Unreviewed closed Template system Cleanup/optimization Normal master wontfix Use self-closing br in linebreaksbr templatetag. The HTML 5 spec says that it's OK to use self-closing tags for void elements https://dev.w3.org/html5/html-author/#void I'd like to change linebreaksbr to use the self-closing version of `br` i.e. `<br/>` so it can be used safely in more environments. As an example, I wanted to use it in a template generating RML (see https://www.reportlab.com/software/rml-reference/). This will not break any existing users but will expand the templatetag's reach ritiko ritiko   1 0 0 0 0 0
30494 2019-05-20 19:10:32 2019-05-21 05:53:19 2019-06-24 06:03:27.563334 Accepted closed Database layer (models, ORM) Bug Normal master fixed Problem with ExtractYear()+1 in queries It looks like django doesn't create a correct MySQL query when having a simple arithmetics with ExtractYear(). I have a model with two data fields: {{{ class Event(models.Model): start_date = models.DateField() finish_date = models.DateField() }}} If I want to find all rows such that the years of start_date and finish_date are equal, I can do it so: {{{ from django.db.models import F from django.db.models.functions import ExtractYear >>> print Event.objects.annotate(year=ExtractYear(F('start_date'))).filter(finish_date__year=F('year')).only('pk').query SELECT `event`.`id`, EXTRACT(YEAR FROM `event`.`start_date`) AS `year` FROM `event` WHERE EXTRACT(YEAR FROM `event`.`finish_date`) = (EXTRACT(YEAR FROM `event`.`start_date`)) }}} But if I want to find events that start and finish in consequent years, I try the following filter, and it gives me an incorrect MySQL query: {{{ >>> print Event.objects.annotate(year=ExtractYear(F('start_date'))).filter(finish_date__year=F('year')+1).only('pk').query SELECT `event`.`id`, EXTRACT(YEAR FROM `event`.`start_date`) AS `year` FROM `event` WHERE `event`.`finish_date` BETWEEN 0001-01-01 AND 0001-12-31 }}} I tried to replace `F('year')+1` with `F('year')+Value(1)` but it didn't help. Am I wrong somewhere, or does it look like a bug? charettes Spartach1985   0 1 0 0 0 0
30493 2019-05-20 15:13:22 2019-06-01 10:48:59 2019-06-24 06:03:26.924856 Accepted closed Database layer (models, ORM) Bug Normal master fixed GenericRelation and prefetch_related: wrong caching with cyclic prefetching. Hello @all! I encountered an issue with GenericRelations. Here is an example to reproduce this issue: https://github.com/FinnStutzenstein/GenericRelatedPrefetch Just do a migrate and runserver. The code showing the error is started automatically in main/apps.py. Please start with --noreload not to have the output twice. Whats the problem? I have a generic model (Tag) that have a {{{content_object}}}. Then there are multiple (in the example 2) models, Book and CD, that have exactly one tag assigned. In the real application (OpenSlides) this invariant is ensured in other places; in the example the objects are created in a way, that this invariant holds. All these content objects have a property {{{tag}}}, that should return the one assigned tag. This is done by adding a helper field {{{tags=GenericRelation(Tag)}}} and the property accesses {{{self.tags.all()[0]}}}. The {{{.all()[0]}}} instead of a simple {{{.get()}}} is required for the prefetching to work. See main/models.py in the example. Now all tags should be loaded because in OpenSlides they would be serialized. For each tag the {{{content_object}}} is accessed as well as {{{content_object.tag}}}. Because this would result in many DB queries (in the real application about 10000 Tags, and in sum 10000 content objects) the models are prefetched with: {{{Tag.objects.prefetch_related("content_object", "content_object__tag")}}} (Note: The executed code is in main/apps.py). This results in a constant amount of queries (4 in this case) instead of something proportional to the amount of objects. In the example you can set {{{N}}}, the amount of objects created, to a higher amount to verify, that the amount of queries stays constant. What is expected: If I have a tag {{{tag}}}, {{{tag.content_object.tag}}} should be equal to {{{tag}}}. Output from the example (with N=1): {{{ Got 'Tag to book0': -the content object: Book0 -the content objects tag (should be the same as 'Tag to book0'!):Tag to book0 Got 'Tag to cd0': -the content ob… cansarigol FinnStutzenstein GenericRelation prefetch_related 0 1 0 0 0 0
30492 2019-05-20 11:54:08 2019-05-20 11:59:47 2019-06-24 06:03:26.286061 Unreviewed closed Template system Bug Normal 2.2 invalid "B" seen as time-related format specifier. I have currently set DATE_FORMAT = "d B Y" in my project settings. If I try to run it like this, I get the following TypeError: The format for date objects may not contain time-related format specifiers (found 'B') However, it works with 'b' Any clue why this is happening? nobody RaduNicoara date, datetime, format, template 0 0 0 0 0 0
30491 2019-05-19 21:54:46 2019-05-28 09:29:23 2019-06-24 06:03:25.652624 Accepted closed Documentation Cleanup/optimization Normal 2.2 fixed Document changing primary key behavior in "How Django knows to UPDATE vs. INSERT" section. PR: https://github.com/django/django/pull/11390 The docs for 'How Django knows to UPDATE vs. INSERT' do not make any mention of a potentially confusing condition, which is that updating a PK followed by a call to .save() will always result in an INSERT rather than an UPDATE. While this note is present in the primary key docstring itself, it would be worthwhile to duplicate it to this section as a gotcha. See also: https://stackoverflow.com/q/56212145/7954504 bsolomon1124 bsolomon1124 save 0 1 1 0 0 0
30490 2019-05-19 18:41:52 2019-05-27 08:56:42 2019-06-24 06:03:25.018100 Unreviewed closed Uncategorized Bug Normal master wontfix migrations unique_index on (app, name). I've a django based api service. I run it in containers, in kubernetes. When I update my image, basically I run the migiration process, then start the application. With k8s for example, when I start the deployment with 2 or more replicas, actually 2 parallel running migration process will start. With the following very simple migration process, unfortunately the migration will be applied twice: {{{ from django.db import migrations from django.db.models import F import time def forward(apps, schema_editor): TT = apps.get_model('center', 'TestTable') time.sleep(10) TT.objects.all().update(value=F('value') + 1) def backward(apps, schema_editor): TT = apps.get_model('center', 'TestTable') TT.objects.all().update(value=F('value') - 1) class Migration(migrations.Migration): dependencies = [ ('center', '0007_testtable'), ] operations = [ migrations.RunPython(forward, backward) ] }}} Even if the migration process is ran in a transaction, due to the unique index missing, it will be applied multiple times. Even though my setup may be rare, I think it would really be necessary to prevent migrations to be applied more than once. Db unique_together could be utilized for that. nobody rkojedzinszky migrations parallel run 0 0 0 0 0 0
30489 2019-05-17 19:43:32 2019-06-03 08:31:06 2019-06-24 06:03:24.347781 Accepted assigned GIS Bug Normal 2.2   Django RasterField deserialization bug with pixeltype flags After inserting some raster data with raster2pgsql into a Django model table with a RasterField column, I get a `list index out of range` when querying the table with a Django Queryset. {{{ ... File "django/contrib/gis/db/models/fields.py" in from_db_value 360. return connection.ops.parse_raster(value) File "django/contrib/gis/db/backends/postgis/operations.py" in parse_raster 369. return from_pgraster(value) File "django/contrib/gis/db/backends/postgis/pgraster.py" in from_pgraster 57. pixeltype = POSTGIS_TO_GDAL[pixeltype] }}} It turns out the `pixeltype` value used is 39 while the `POSTGIS_TO_GDAL` list is only 16 elements long. The database field contains valid data but can not be deserialized with Django. **Steps for reproduction:** {{{ # Django model class RasterModel(models.Model): rast = models.RasterField(srid=4326) # raw sql, single pixel raster with nodata bit set insert into app_rastermodel values(1, REPLACE('01 0000 0100 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 E6100000 0100 0100 6 2 03 03', ' ', '')::raster); # query generating Exception RasterModel.objects.get(pk=1) }}} **Analysis**: if we look at the [https://trac.osgeo.org/postgis/wiki/WKTRaster/RFC/RFC1_V0SerialFormat Raster specification], the pixeltype is a byte of which the 4 highest bits are flags and the lowest 4 bits are the real pixeltype. Quoting the specification: {{{ Pixel type and storage flag --------------------------- Pixel type specifies type of pixel values in a band. Storage flag specifies whether the band data is stored as part of the datum or is to be found on the server's filesytem. There are currently 11 supported pixel value types, so 4 bits are enough to account for all. We'll reserve the upper 4 bits for generic flags and define upmost as storage flag: #define BANDTYPE_FLAGS_MASK 0xF0 #define BANDTYPE_PIXTYPE_MASK 0x0F #define BANDTYPE_FLAG_OFFDB (1… ivorbosloper ivorbosloper RasterField 0 1 1 0 0 0

Next page

Advanced export

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

CSV options:

CREATE TABLE "tickets_full" (
        id int primary key,
        created datetime,
        changetime datetime,
        last_pulled_from_trac datetime,
        stage text,
        status text,
        component text,
        type text,
        severity text,
        version text,
        resolution text,
        summary text,
        description text,
        owner text,
        reporter text,
        keywords text,
        easy boolean,
        has_patch boolean,
        needs_better_patch boolean,
        needs_tests boolean,
        needs_docs boolean,
        ui_ux boolean
    );