Re: Fellow Reports - December 2019

[Mariusz Felisiak]

Week ending December 15, 2019.

*Triaged:*
https://code.djangoproject.com/ticket/31074 - Errors model abstract 
testing. (invalid)
https://code.djangoproject.com/ticket/31075 - CSRF token missing or 
incorrect when File upload path not exist. (worksforme)
https://code.djangoproject.com/ticket/31073 - SplitArrayField with 
BooleanField always has widgets checked after the first True value. 
(accepted)
https://code.djangoproject.com/ticket/31076 - dbshell crashes on Windows 
and Python < 3.8. (created)
https://code.djangoproject.com/ticket/31077 - Add a safeguard to debug 
decorators (sensitive_variables/sensitive_post_parameters) to prevent 
incorrect usage. (accepted)
https://code.djangoproject.com/ticket/31078 - Problem while deleting inline 
model record in admin model. (worksforme)
https://code.djangoproject.com/ticket/31079 - Boolean not right value in 
admin page. (invalid)
https://code.djangoproject.com/ticket/25361 - Unpickling of QuerySet fails 
in presence of abstract intermediate model (fixed)
https://code.djangoproject.com/ticket/31084 - ValueError: could not convert 
string to float. (invalid)
https://code.djangoproject.com/ticket/31085 - Prevent bots from submitting 
forms. (invalid)
https://code.djangoproject.com/ticket/31086 - Improve error message for 
admin.E202. (accepted)
https://code.djangoproject.com/ticket/31088 - Added support for webquery 
search to SearchQuery() on PostgreSQL 11+. (accepted)
https://code.djangoproject.com/ticket/12679 - In admin, inlines should be 
allowed to be properties (fixed)
https://code.djangoproject.com/ticket/31087 - SpatialLite backend raises 
ValueError when getting distance parameter. (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/12188 - Fixed #31066 -- Added a 
docstring to main() function in manage.py template.
https://github.com/django/django/pull/12169 - Fixed #27430 -- Added 
-b/--buffer option to DiscoverRunner.
https://github.com/django/django/pull/12197 - Fixed #31044 -- Errored 
nicely when using Prefetch with a raw() queryset.
https://github.com/django/django/pull/12198 - Fixed #26480 -- Fixed crash 
of contrib.auth.authenticate() on decorated authenticate() methods of 
authentication backends.
https://github.com/django/django/pull/12193 - Fixed #31073 -- Prevented 
CheckboxInput.get_context() from mutating attrs.
https://github.com/django/django/pull/12196 - Fixed #31077 -- Made debug 
decorators raise TypeError if they're not called.
https://github.com/django/django/pull/12150 - Refs #28373 -- Stopped 
setting tzinfo in typecast_timestamp().
https://github.com/django/django/pull/12204 - Refs #25361 -- Added test for 
pickling queryset of abstract-inherited models with Meta.ordering.
https://github.com/django/django/pull/11894 - Fixed #30862 -- Allowed 
setting SameSite cookies flags to 'None'.
https://github.com/django/django/pull/12203 - Fixed #31069, Refs #26431 -- 
Doc'd RegexPattern behavior change in passing optional named groups in 
Django 3.0.
https://github.com/django/django/pull/12212 - Fixed #26743 -- Fixed 
UnboundLocalError crash when deserializing m2m fields and value isn't 
iterable.
https://github.com/django/django/pull/12213 - Added Algerian Arabic 
language.
https://github.com/django/django/pull/12216 - Refs #12679 -- Added test for 
using property as ModelAdmin.inlines.

*Authored:*
https://github.com/django/django/pull/12195 - Refs #23433 -- Fixed 
test_django_admin_py.DeprecationTest tests failures on Windows and Python < 
3.8.

Best regards,
Mariusz

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f03595ad-56bd-448e-b226-f6f4e2ab18b4%40googlegroups.com.

Improving error message for admin.E202

[Shubham Singh]

I am new to contributing to django, and i have picked up a ticket listed as 
easy picking #31086 . 

It states to make the admin E.202 message (admin inline having, multiple 
foreign keys to the same parent model), to recommend specifying fk_name.

To do so the error message in the ValueError raised by the 
_get_foreign_key() 

 
method must be changed. My concern is, if this change is made then whenever 
the method will raise an error the new error message recommending the 
fk_names will be used, hence the change is not restricted to the admin 
error code only. Will it cause any backward compatibility issues ?  Or is 
it safe to make this change ?

And is the format for the error message given below, is acceptable ?

'appName.ModelOne' has more than one ForeignKeys ('fk_one', 'fk_two') to 
'appName.ModelTwo'.


Thanks !

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f2b44d25-379d-4e73-9350-035051e0f392%40googlegroups.com.

Re: Improving error message for admin.E202

[Mariusz Felisiak]

It's safe to make change to warning messages.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0437aafa-9016-40df-a642-9ce64e1cc3ed%40googlegroups.com.

Suggestion: Add validators to Model Meta options

[Mathias Weirsøe Klitgaard]

Hi Django Developers,

I'm new to contributing and from what I gathered, I should ask here before 
opening a ticket.

Right now the way to validate a model as a whole is to override 
Model.clean(). I have 2 problems with this:

1) If you do multiple checks that raise ValidationErrors, it is tedious to 
accumulate them.
2) Having different models that checks almost the same, e.g. start_date 
should come before end_date, it should be easy to reuse validators.

I suggest to add a 'validators' option to Model Meta options.
This should be very similar to the 'validators' option a Field has, a list 
of callables that raises ValidationErrors, except these should take an 
object 'instance' instead of a 'value'.
It should then be Model.full_clean() responsibility to call these model 
validators in addition to what it already does.

A concern I have is the confusion that may rise between these new 'model 
validators' and regular 'field validators'. Maybe clever naming could help 
distinguish them from eachother, and maybe it's not a huge deal since they 
are so closely related.

It would be nice if some common model validators got built-in as well. For 
example a ComparisonModelValidator could take the names of two fields and 
validate if they are in the right order, it could look like

class ComparisonModelValidator(low, high, message=None, code=None)
* low - field name of the lesser field
* high - field name of the greater field
* message - if not None, overrides message
* code - if not None, overrides code

Then it could be used in the model as

class Event(models.Model):
start_date = models.DateField()
end_date = models.DateField()
...

class Meta:
validators = [ComparisonModelValidator('start_date', 'end_date')]


All feedback is appreciated.

Mathias

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/57166b63-56e6-485a-ba99-23369e7c6b1b%40googlegroups.com.

Re: Forms submitted by bots

[Matemática A3K]

On Sun, Dec 15, 2019 at 2:54 AM James Bennett  wrote:

> Since this discussion seems to be exclusively about how to use Django,
> please take it to the django-users mailing list; the django-developers list
> is not an appropriate place for this topic.
>

I agree :)


> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAL13Cg8h%2BHsZbc5oZ5rwLiOO0%2BHTiS8EKpT6OW1P6bSUj1R1pA%40mail.gmail.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CA%2BFDnh%2B4TkmjP01w%3DndvgtGXjuXkf4BQ64Vv3paPbqq6kR6KNg%40mail.gmail.com.

Adding json lines (jsonl) serializer ro django

[Ali Vakilzade]

Hey!

A few month ago I opened a ticket for adding jsonl support to django 
serializers, I have added a basic patch as the starting point but my ticket 
was closed because it needed more discussion on the mailing list, I'm 
willing to work more on my patch to reach a final state (adding more tests 
and updating docs) but before working more on it just wanted to get the 
green light or some direction from you :-)

Link to ticket: https://code.djangoproject.com/ticket/30190

Thanks

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/17a919f1-559d-4599-85c8-236a9df5cf6e%40googlegroups.com.

Suggestion to change the Logger date format to ISO 8601

[Leon Albrecht]

At the moment Django is using "DD/MMM/ hh:mm:ss", but since 1988 there 
exists an ISO to format dates like this: "YYY-DD-MM hh:mm:ss"

this is not a majot change and i've searched for to do it myself but 
according to the python logger libary this format is already in use, but 
Django apperantly changes it, somewhere I could not find it, to the 
beforementioned format.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/9536ce2f-e864-4231-99b5-66a7fde9f77c%40googlegroups.com.

Re: Forms submitted by bots

[אורי]

Hi,

On Sun, Dec 15, 2019 at 9:55 AM James Bennett  wrote:

> Since this discussion seems to be exclusively about how to use Django,
> please take it to the django-users mailing list; the django-developers list
> is not an appropriate place for this topic.
>

This is about my feature request "Prevent bots from submitting forms.":
https://code.djangoproject.com/ticket/31085

אורי

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeELxLx3MTjYaVRrYRuuaAPyzhRe9nx6qjD8dxa%2B6XN9dw%40mail.gmail.com.

Re: Forms submitted by bots

[Kye Russell]

Due to the cat-and-mouse nature inherent in this sort of request, and the 
community’s expectation of feature stability in Django, I feel that a 
third-party app is not the appropriate place for a feature like this. 

If the Django documentation doesn’t already do so, perhaps it could mention 
this issue in the Forms section, so new developers / Django users are aware of 
it. 

Kye Russell
Sent from my iPhone

> On 17 Dec 2019, at 7:36 am, אורי  wrote:
> 
> 
> Hi,
> 
>> On Sun, Dec 15, 2019 at 9:55 AM James Bennett  wrote:
>> Since this discussion seems to be exclusively about how to use Django, 
>> please take it to the django-users mailing list; the django-developers list 
>> is not an appropriate place for this topic.
> 
> This is about my feature request "Prevent bots from submitting forms.":
> https://code.djangoproject.com/ticket/31085 
> 
> אורי 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CABD5YeELxLx3MTjYaVRrYRuuaAPyzhRe9nx6qjD8dxa%2B6XN9dw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4C06950D-2AAE-4FAC-BFC7-A5B1A7DD355E%40kye.id.au.

Re: Adding json lines (jsonl) serializer ro django

[Adam Johnson]

Hi Ali

Thanks for coming back to this. As I wrote on the ticket I'd be in favour
of adding this.

If you've got some code already it'd be good to see it in a PR

As for your question about overly long lines I think the .replace() style
is fine, or a consrtuction like this:

''.join([
"{"
'"key1": "value1",
"}",
])

Django contributions are not just about core developers giving you the
green light; you'll need to be a bit persistent to follow the coding
guides, fix test errors, respond to feedback, and push the patch through.
But given you've returned after 10 months I'm sure you can!

Thanks,

Adam


On Mon, 16 Dec 2019 at 23:05, Ali Vakilzade  wrote:

> Hey!
>
> A few month ago I opened a ticket for adding jsonl support to django
> serializers, I have added a basic patch as the starting point but my ticket
> was closed because it needed more discussion on the mailing list, I'm
> willing to work more on my patch to reach a final state (adding more tests
> and updating docs) but before working more on it just wanted to get the
> green light or some direction from you :-)
>
> Link to ticket: https://code.djangoproject.com/ticket/30190
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/17a919f1-559d-4599-85c8-236a9df5cf6e%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2RQ5x65XA%2BtiRmbhCKeasPn8a7wc_Na7LD8zLSEzLJMg%40mail.gmail.com.

Re: Suggestion to change the Logger date format to ISO 8601

[Adam Johnson]

Hi

I think the change you're referring to is in runserver:
https://github.com/django/django/blob/ff00a053478fee06bdfb4206c6d4e079e98640ff/django/core/servers/basehttp.py#L132
. Django uses a function from the standard library wsgiref simple server
here to generate server_time which is then shown in the log format. Indeed
it doesn't seem to allow configuring it at current.

I imagine there's a way to stop using the log_date_time_string() function
there if you want, however I am not sure about changing the default. Many
sites end up using runserver in production (despite it being insecure) and
it's likely there are scripts out there to parse the logs as they are.

Thanks,

Adam

On Mon, 16 Dec 2019 at 17:25, Leon Albrecht  wrote:

> At the moment Django is using "DD/MMM/ hh:mm:ss", but since 1988 there
> exists an ISO to format dates like this: "YYY-DD-MM hh:mm:ss"
>
> this is not a majot change and i've searched for to do it myself but
> according to the python logger libary this format is already in use, but
> Django apperantly changes it, somewhere I could not find it, to the
> beforementioned format.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/9536ce2f-e864-4231-99b5-66a7fde9f77c%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM22%3DU%2Bq4gOPGSSXer1wk5NjYx8Konkw7AAWVx2KVC9LHw%40mail.gmail.com.

Re: Suggestion: Add validators to Model Meta options

[Adam Johnson]

Hi Mathias

I feel like this has been suggested on the mailing list or ticket tracker
before, a few years ago. However after a quick check I can't find the
discussion/ticket in mind. Perhaps if you hunt a bit better than me you can
find it.

I think it's definitely a whole in the validation API. I think it'd be
better to see a composable Form.clean before another model option. Although
Django makes things fast I do always feel a bit comfortable how closely
coupled models and forms are.

Have you seen the database constraints added to Django and improved over
the recent versions?
https://docs.djangoproject.com/en/3.0/ref/models/constraints/ . I've been
using them on a few projects with some success. I prefer this kind of
validation since it's done in the database and thus it's impossible to
insert or update rows that are bad. There's definitely a (substantial)
project there to escalate check constraints into form validation errors too.

As for your composability approach - it's possible with today's Django if
you use a bit of Python magic. clean() should work as a callable class
rather than a function. For example (a sketch, untested):

class MultiCleaner:
def __init__(self, model_validators):
self.model_validators = model_validators

def __call__(self, instance):
for model_validator in model_validators:
model_validator(instance)


class Model:
...

clean = MultiCleaner([
ComparisonModelValidator('start_date', 'end_date'),
])

If you want to expand this idea and test it I'd be interested to see the
results.

Thanks,

Adam

On Mon, 16 Dec 2019 at 15:21, Mathias Weirsøe Klitgaard <
mathias.weir...@gmail.com> wrote:

> Hi Django Developers,
>
> I'm new to contributing and from what I gathered, I should ask here before
> opening a ticket.
>
> Right now the way to validate a model as a whole is to override
> Model.clean(). I have 2 problems with this:
>
> 1) If you do multiple checks that raise ValidationErrors, it is tedious to
> accumulate them.
> 2) Having different models that checks almost the same, e.g. start_date
> should come before end_date, it should be easy to reuse validators.
>
> I suggest to add a 'validators' option to Model Meta options.
> This should be very similar to the 'validators' option a Field has, a list
> of callables that raises ValidationErrors, except these should take an
> object 'instance' instead of a 'value'.
> It should then be Model.full_clean() responsibility to call these model
> validators in addition to what it already does.
>
> A concern I have is the confusion that may rise between these new 'model
> validators' and regular 'field validators'. Maybe clever naming could help
> distinguish them from eachother, and maybe it's not a huge deal since they
> are so closely related.
>
> It would be nice if some common model validators got built-in as well. For
> example a ComparisonModelValidator could take the names of two fields and
> validate if they are in the right order, it could look like
>
> class ComparisonModelValidator(low, high, message=None, code=None)
> * low - field name of the lesser field
> * high - field name of the greater field
> * message - if not None, overrides message
> * code - if not None, overrides code
>
> Then it could be used in the model as
>
> class Event(models.Model):
> start_date = models.DateField()
> end_date = models.DateField()
> ...
>
> class Meta:
> validators = [ComparisonModelValidator('start_date', 'end_date')]
>
>
> All feedback is appreciated.
>
> Mathias
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/57166b63-56e6-485a-ba99-23369e7c6b1b%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1LQFrVTVFiCUJteycedpJS4y312P7DquqNfVR8PcBZdw%40mail.gmail.com.