Re: [Django] #30706: Why isn't the auth.User.id field documented?

[Django]

#30706: Why isn't the auth.User.id field documented?
-+-
 Reporter:  Conrad   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Documentation|  Version:  master
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:  auth Documentation   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * version:  2.2 => master
 * resolution:   => wontfix


Comment:

 Thanks for the report, however by default, each model has
 [https://docs.djangoproject.com/en/2.2/topics/db/models/#automatic-
 primary-key-fields automatic primary key field] `id` (if custom primary
 key is not specified). I don't think that we need to add redundant `id`
 description to the `User` model docs.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30707: why it took 30s when call sorted function in django server sometimes. (was: why it took 30s when call sorted function in django server sometimes)

[Django]

#30707: why it took 30s when call sorted function in django server sometimes.
-+--
 Reporter:  liumilan |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  sorted function  | Triage Stage:  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+--
Changes (by felixxm):

 * status:  new => closed
 * resolution:   => invalid
 * version:  2.2 => master
 * component:  Testing framework => Core (Other)


Comment:

 I don't see anything Django-specific in attached example. It is rather a
 question about how `sorted()` works on iterables in Python.

 Closing per TicketClosingReasons/UseSupportChannels.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #30707: why it took 30s when call sorted function in django server sometimes

[Django]

#30707: why it took 30s when call sorted function in django server sometimes
-+-
   Reporter:  liumilan   |  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Testing|Version:  2.2
  framework  |
   Severity:  Normal |   Keywords:  sorted function
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I add some logic in django . And when i sent requests to server,i found
 some requests are handled so slowly,and then find it will take much time
 when call sorted function.But it is stranged that if i sent this wired
 data to server alone,it is ok,only take 100ms.Does the sorted function has
 confict with django?


 {{{
 def recall(word):
 dict_result = {}
 word_fields = word.split(":")
 for i in range(0,len(word_fields)):
 generate(dict_resut)
 pre_result = sorted(dict_result.items(),
 key=operator.itemgetter(1),reverse=True)

 return recall_tag[:-1]

 client code is:
   for line in sys.stdin:
 line = line.rstrip('\n')
 fields = line.split("\t")
 id = fields[0]
 title = fields[1]
 page_params_mq = {'id':vid,'title':title}
 try :
 rec_mq_res = get_rec(server_ip_mq, server_port_mq,
 web_page_mq, page_params_mq)
 except:
 print (line)
 }}}
 I run
 cat test_data|python client.py
 if there is only one data in test_data file,it is ok.If there are many
 data,it will occur randomly slowly

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #30706: Why isn't the auth.User.id field documented?

[Django]

#30706: Why isn't the auth.User.id field documented?
-+-
   Reporter:  Conrad |  Owner:  nobody
   Type: | Status:  new
  Cleanup/optimization   |
  Component: |Version:  2.2
  Documentation  |
   Severity:  Normal |   Keywords:  auth Documentation
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I asked this at the GitHub project
 ([https://github.com/django/djangoproject.com/issues/934]) and was
 redirected here: the default Django User id field exists and is used a lot
 (as far as questions on Stack Overflow and example projects I can find
 go), but I can't find any documentation on it apart from the fact, that it
 is set "None" for Anonymous Users. @frankwiles told me on GitHub that the
 reason might be that all models have the "id" field by default, but I
 couldn't find a source that this is the reason why it isn't mentioned in
 the docs.

 I believe it is ok to use it, if not it should be added to the
 documentation as a warning or similar text. If it is ok to use it, why not
 write it down? It would help people like me (pretty new to Django) to
 quickly find how to use unique user ids, maybe there are even some custom
 settings most people don't know about.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30701: Allowing patch_vary_headers() caching utility to handle '*' value.

[Django]

#30701: Allowing patch_vary_headers() caching utility to handle '*' value.
-+-
 Reporter:  Alexander-TX |Owner:  Adnan
 |  Umer
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Adnan Umer):

 [https://github.com/django/django/pull/11666 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30701: Allowing patch_vary_headers() caching utility to handle '*' value.

[Django]

#30701: Allowing patch_vary_headers() caching utility to handle '*' value.
-+-
 Reporter:  Alexander-TX |Owner:  Adnan
 |  Umer
 Type:  New feature  |   Status:  assigned
Component:  Core (Cache system)  |  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Adnan Umer):

 * owner:  nobody => Adnan Umer
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH parameter, only str

[Django]

#30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH 
parameter,
only str
-+-
 Reporter:  Nikita Krokosh   |Owner:  Nikita
 |  Krokosh
 Type:  New feature  |   Status:  closed
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  geoip2   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"eed2e740f7efa9a9290fb913f796437e2c4adc5f" eed2e740]:
 {{{
 #!CommitTicketReference repository=""
 revision="eed2e740f7efa9a9290fb913f796437e2c4adc5f"
 Fixed #30461 -- Made GeoIP2 and GEOIP_PATH setting accept pathlib.Path as
 library path.

 Thanks Nikita Krokosh for the initial patch.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH parameter, only str

[Django]

#30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH 
parameter,
only str
-+-
 Reporter:  Nikita Krokosh   |Owner:  Nikita
 |  Krokosh
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  geoip2   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"88c0b907e76bccfe1a25dc6580272b07aebd45d6" 88c0b907]:
 {{{
 #!CommitTicketReference repository=""
 revision="88c0b907e76bccfe1a25dc6580272b07aebd45d6"
 Refs #30461 -- Added django.utils._os.to_path().
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH parameter, only str

[Django]

#30461: contrib.gis.geoip2 does not support pathlib.Path as GEOIP_PATH 
parameter,
only str
-+-
 Reporter:  Nikita Krokosh   |Owner:  Nikita
 |  Krokosh
 Type:  New feature  |   Status:  assigned
Component:  GIS  |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  geoip2   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

[Django] #30705: Django template permissions not working when used inside the template of an inclusion tag

[Django]

#30705: Django template permissions not working when used inside the template 
of an
inclusion tag
-+-
   Reporter:  erev0s |  Owner:  nobody
   Type: | Status:  new
  Uncategorized  |
  Component:  Template   |Version:  2.2
  system |   Keywords:  permissions,
   Severity:  Normal |  inclusion tag
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I have 2 apps in a Django Project i am using to learn django. In the app A
 I have an inclusion tag where I am using a template named
 `templateA.html`. This inclusion tag is being used in the app B, inside
 the template `templateB.html`. The content of `templateA.html` is shown
 properly inside `templateB.html`.

 I noticed though that when I am attempting to check permissions of the
 user using code similar to the following:
 {{{
 {% if perms.appA.can_do_something %}
 show something here
 {% endif %}
 }}}
 then, if I include that code in `templateA.html` it is not working, while
 if I use it in `templateB.html` it is working properly.  I am mentioning
 again that the `templateA.html` is the one used in the inclusion tag I am
 using in the `templateB.html`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30702: Form leaks all objects of model

[Django]

#30702: Form leaks all objects of model
-+-
 Reporter:  Kevin Olbrich|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  form, forms, | Triage Stage:
  queryset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Kevin Olbrich):

 I've got the point and you are right: AssertionError.
 Thank you very much for pointing me in the right direction!

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30702: Form leaks all objects of model

[Django]

#30702: Form leaks all objects of model
-+-
 Reporter:  Kevin Olbrich|Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  form, forms, | Triage Stage:
  queryset   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Carlton Gibson):

 This is an issue with your usage of the django-braces mixin, not Django.
 You need to ask for help on the support channels for django-braces, or
 django-users or StackOverflow, rather than here.

 It's not a bug with Django. To see this add an `assert self.user is not
 None` in your form's `__init__()` after the `super()` call. Follow the
 traceback when that fails.

 In general, a bug is 99% likely to be in your code and only 1% likely (if
 that for something like ORM filtering which is as exercised as can be) to
 be in the framework. So, please, before opening an issue pursue support
 channels to help you pin down exactly what's going on. To show a fault in
 Django, at the least you need to remove additional code such as django-
 braces.

 Sorry if that seems harsh, but we can't offer usage support here. We just
 don't have the capacity. I hope that makes sense to you.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #30704: JSONField nested key and index transforms crash.

[Django]

#30704: JSONField nested key and index transforms crash.
--+
 Reporter:  felixxm   |Owner:  felixxm
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:  master
 Severity:  Normal|   Resolution:  fixed
 Keywords:| Triage Stage:  Accepted
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by GitHub ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"c19ad2da4b573431843e5cead77f4139e29c77a0" c19ad2d]:
 {{{
 #!CommitTicketReference repository=""
 revision="c19ad2da4b573431843e5cead77f4139e29c77a0"
 Fixed #30704 -- Fixed crash of JSONField nested key and index transforms
 on expressions with params.

 Thanks Florian Apolloner for the report and helping with tests.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #25367: Allow expressions in .filter() calls

[Django]

#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Matthew
 Type:   |  Schinckel
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"fff5186d3215e0ba06e47090226169f2230786b0" fff5186d]:
 {{{
 #!CommitTicketReference repository=""
 revision="fff5186d3215e0ba06e47090226169f2230786b0"
 Refs #25367 -- Moved select_format hook to BaseExpression.

 This will expose an intermediary hook for expressions that need special
 formatting when used in a SELECT clause.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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

Re: [Django] #25367: Allow expressions in .filter() calls

[Django]

#25367: Allow expressions in .filter() calls
-+-
 Reporter:  Anssi Kääriäinen |Owner:  Matthew
 Type:   |  Schinckel
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"efa1908f662c19038a944129c81462485c4a9fe8" efa1908f]:
 {{{
 #!CommitTicketReference repository=""
 revision="efa1908f662c19038a944129c81462485c4a9fe8"
 Refs #25367 -- Moved Oracle Exists() handling to contextual methods.

 Oracle requires the EXISTS expression to be wrapped in a CASE WHEN in
 the following cases.

 1. When part of a SELECT clause.
 2. When part of a ORDER BY clause.
 3. When compared against another expression in the WHERE clause.

 This commit moves the systematic CASE WHEN wrapping of Exists.as_oracle
 to contextual .select_format, Lookup.as_oracle, and OrderBy.as_oracle
 methods in order to avoid unnecessary wrapping.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

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