Re: [Django] #4848: Allow inline fields to be "mixed in" with the models' own fields

2019-07-12 Thread Django
#4848: Allow inline fields to be "mixed in" with the models' own fields
-+-
 Reporter:  leifbyron|Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  contrib.admin|  Version:  newforms-
 |  admin
 Severity:  Normal   |   Resolution:
 Keywords:  nfa-someday  | Triage Stage:  Accepted
  newforms-admin inline models   |
  fields |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alex Scott):

 * cc: Alex Scott (added)


Comment:

 Is anyone working on this?

 One "solution" that I found:
 
https://github.com/dezede/dezede/commit/ed13ccaf34494e71fd913fd785c229052f6acdc8

 Another:
 https://linevi.ch/en/django-inline-in-fieldset.html

 I've never contributed before but if some would weigh in on what they
 think the cleanest solution would be, I could maybe attempt something.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.65215d48e83be6f9a37d0c09542beab2%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30607: How to use Django specific markup in the docstrings.

2019-07-12 Thread Django
#30607: How to use Django specific markup in the docstrings.
-+-
 Reporter:  Anuj Sharma  |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Documentation|  Version:  2.2
 Severity:  Normal   |   Resolution:
 Keywords:  writing- | Triage Stage:
  documentation, Django-specific-|  Unreviewed
  markup |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam Starrh):

 * status:  closed => new
 * resolution:  invalid =>


Comment:

 Replying to [comment:3 Carlton Gibson]:
 > This is not a support channel. Please see
 TicketClosingReasons/UseSupportChannels.
 >
 > (Google `sphinx extensions`. Look in `django/docs/conf.py` and
 `django/docs/_ext/djangodocs.py`)
 >
 > > This should be added to the documentation as well.
 >
 > We already link to the RST docs.

 Please take a closer look at this.

 To utilize the Django-Specific markup, developers must add "djangodocs",
 to the extensions in their Sphinx configuration. The RST docs can tell you
 where to add the extension, but Django's docs should at least tell you
 what the name of the extension is, no?
 https://docs.djangoproject.com/en/dev/internals/contributing/writing-
 documentation/#getting-started-with-sphinx.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bc2e6781154edc877fde44c2fa3599c5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #14129: Slovenian translation plural-forms

2019-07-12 Thread Django
#14129: Slovenian translation plural-forms
-+-
 Reporter:  Gasper Zejn  |Owner:  Jannis
 |  Leidel
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.2
  Internationalization   |
 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 Claude Paroz):

 With Transifex, it's hard to know for sure. If anyone knows a method to do
 so, please tell me!

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.e7d442b07f53421b2d524b34ddb7e9ce%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0) with Python 3.7 (3.7.4).

2019-07-12 Thread Django
#30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0)
with Python 3.7 (3.7.4).
-+-
 Reporter:  Alexandru Rudi   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  oracle cx-oracle | Triage Stage:
  python-3.7 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexandru Rudi):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 Replying to [comment:8 Jani Tiainen]:
 > Could you please check NLS settings from your db:
 > {{{#!sql
 > SELECT * FROM NLS_DATABASE_PARAMETERS;
 > SELECT * FROM NLS_INSTANCE_PARAMETERS;
 > }}}

 From NLS_DATABASE_PARAMETERS:
 ||= PARAMETER =||= VALUE=||
 ||NLS_RDBMS_VERSION||   12.1.0.2.0||
 ||NLS_NCHAR_CONV_EXCP|| FALSE||
 ||NLS_LENGTH_SEMANTICS||BYTE||
 ||NLS_COMP||BINARY||
 ||NLS_DUAL_CURRENCY||   $||
 ||NLS_TIMESTAMP_TZ_FORMAT|| DD-MON-RR HH.MI.SSXFF AM TZR||
 ||NLS_TIME_TZ_FORMAT||  HH.MI.SSXFF AM TZR||
 ||NLS_TIMESTAMP_FORMAT||DD-MON-RR HH.MI.SSXFF AM||
 ||NLS_TIME_FORMAT|| HH.MI.SSXFF AM||
 ||NLS_SORT||BINARY||
 ||NLS_DATE_LANGUAGE||   AMERICAN||
 ||NLS_DATE_FORMAT|| DD-MON-RR||
 ||NLS_CALENDAR||GREGORIAN||
 ||NLS_NUMERIC_CHARACTERS||  .,||
 ||NLS_NCHAR_CHARACTERSET||  AL16UTF16||
 ||NLS_CHARACTERSET||WE8ISO8859P1||
 ||NLS_ISO_CURRENCY||AMERICA||
 ||NLS_CURRENCY||$||
 ||NLS_TERRITORY||   AMERICA||
 ||NLS_LANGUAGE||AMERICAN||

 From NLS_INSTANCE_PARAMETERS:
 ||= PARAMETER =||= VALUE=||
 ||NLS_LANGUAGE||AMERICAN||
 ||NLS_TERRITORY||   AMERICA||
 ||NLS_COMP||BINARY||
 ||NLS_LENGTH_SEMANTICS||BYTE||
 ||NLS_NCHAR_CONV_EXCP|| FALSE||
 The rest of the values are (null).

 > Also note that following settings takes place in environment before
 connection is opened:
 > {{{
 > NLS_LANG=.AL32UTF8
 > ORA_NCHAR_LITERAL_REPLACE=TRUE
 > }}}

 Can these be configured from settings.py?

 > {{{ _output_type_handler }}} is used to properly read numerical values
 from db. It shouldn't affect model creation but it has effect when reading
 values from db.
 >
 > Also if you could please try older versions of cx_Oracle just to rule
 out that it's some bug in cx_Oracle itself.

 Tested with 7.1 and 7.0, both worked without issue, so it seems to be a
 regression in cx_Oracle, even though I scanned their changelogs twice and
 no mention of a change that would impact this. Thank you for being
 understanding and guiding me in the right direction. I will raise a ticket
 on their end.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.960bcf23383be9a62a970aecc863b7f4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0) with Python 3.7 (3.7.4).

2019-07-12 Thread Django
#30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0)
with Python 3.7 (3.7.4).
-+-
 Reporter:  Alexandru Rudi   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle cx-oracle | Triage Stage:
  python-3.7 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by felixxm):

 Thanks for investigation, but I still don't believe that it is an issue in
 Django, it's probably some `cx_Oracle` issue with `outputtypehandler`
 related with a specific database, environment, OS, etc. configuration. I
 agree with Jani you could try to check with previous versions of
 `cx_Oracle` i.e. 7.1, 7.0, 6.X. If it works with other versions of
 `cx_Oracle` then you should report this issue in https://github.com/oracle
 /python-cx_Oracle/issues.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.fc233f8a36dbf3bee6c2e8cc3147ebb5%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #14129: Slovenian translation plural-forms

2019-07-12 Thread Django
#14129: Slovenian translation plural-forms
-+-
 Reporter:  Gasper Zejn  |Owner:  Jannis
 |  Leidel
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.2
  Internationalization   |
 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 felixxm):

 I think it **can** be changed in Transifex, am I right? Probably not :|

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.b75443018c45296106e25ebea48859af%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0) with Python 3.7 (3.7.4).

2019-07-12 Thread Django
#30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0)
with Python 3.7 (3.7.4).
-+-
 Reporter:  Alexandru Rudi   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle cx-oracle | Triage Stage:
  python-3.7 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Jani Tiainen):

 Could you please check NLS settings from your db:
 {{{#!sql
 SELECT * FROM NLS_DATABASE_PARAMETERS;
 SELECT * FROM NLS_INSTANCE_PARAMETERS;
 }}}

 Also note that following settings takes place in environment before
 connection is opened:
 {{{
 NLS_LANG=.AL32UTF8
 ORA_NCHAR_LITERAL_REPLACE=TRUE
 }}}

 {{{ _output_type_handler }}} is used to properly read numerical values
 from db. It shouldn't affect model creation but it has effect when reading
 values from db.

 Also if you could please try older versions of cx_Oracle just to rule out
 that it's some bug in cx_Oracle itself.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.93cf4aab39320a5cf7205320e8a6e499%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #14129: Slovenian translation plural-forms

2019-07-12 Thread Django
#14129: Slovenian translation plural-forms
-+-
 Reporter:  Gasper Zejn  |Owner:  Jannis
 |  Leidel
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.2
  Internationalization   |
 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 Claude Paroz):

 `can be changed` or `can't be changed`?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.c4247dc9a59be4bc7df31014e43cabd6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0) with Python 3.7 (3.7.4). (was: MemoryError raised by inspectdb executed on Oracle 12c.)

2019-07-12 Thread Django
#30630: MemoryError appears when using cx-Oracle 7.2 on Oracle 12c (12.1.0.2.0)
with Python 3.7 (3.7.4).
-+-
 Reporter:  Alexandru Rudi   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  oracle cx-oracle | Triage Stage:
  python-3.7 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexandru Rudi):

 * keywords:  oracle => oracle cx-oracle python-3.7
 * status:  closed => new
 * resolution:  invalid =>


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.4098daccdabbdfac920bdb318ed6bbe0%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30630: MemoryError raised by inspectdb executed on Oracle 12c.

2019-07-12 Thread Django
#30630: MemoryError raised by inspectdb executed on Oracle 12c.
-+-
 Reporter:  Alexandru Rudi   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  oracle   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexandru Rudi):

 * keywords:   => oracle


Comment:

 {{{#!python
 def __init__(self, connection):
 self.cursor = connection.cursor()
 #self.cursor.outputtypehandler = self._output_type_handler
 }}}

 Disabling that line in base.py in class FormatStylePlaceholderCursor
 removes the MemoryError. No other changes required to default Django 2.2
 implementation.
 Without the output type handler, the inspectdb command completed
 successfully and generated models for all the tables found in the
 database.
 I do not know how to proceed any further and don't even know the negative
 effects of disabling that handler. Is is still required?

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/077.39b3f18402a59aff7fffae5e9d153089%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #30635: Add feature to sanitize text include control characters

2019-07-12 Thread Django
#30635: Add feature to sanitize text include control characters
--+
   Reporter:  Tatsuya Matoba  |  Owner:  nobody
   Type:  New feature | Status:  new
  Component:  Utilities   |Version:  2.2
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 Current, If Django send to feed text with control characters, Django raise
 the `UnserializableContentError` .

 It was added by #20197.

 I think a common solution for app developers who encounter this problem
 would be to sanitize the control characters.

 I think it is desirable Django provide sanitizing feature for control
 characters.

 For example, add the following function to `django/utils/xmlutils.py` :

 {{{
 def sanitize_control_charcters(text):
 return re.sub(r'[\x00-\x08\x0B-\x0C\x0E-\x1F]', " ", text)
 }}}

 If there is no problem with adding functions, I would like to send a 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/051.a138b2a3709ca3e919c9ba4a51004d35%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #29824: Add support for EXCLUDE USING constraint

2019-07-12 Thread Django
#29824: Add support for EXCLUDE USING constraint
-+-
 Reporter:  Mads Jensen  |Owner:  Mads
 |  Jensen
 Type:  New feature  |   Status:  assigned
Component:  contrib.postgres |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  constraints  | Triage Stage:  Accepted
  postgres   |
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mads Jensen):

 * needs_better_patch:  1 => 0


-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.d7c909f31c5b7ffda00734e6e4f1fd2b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #14129: Slovenian translation plural-forms

2019-07-12 Thread Django
#14129: Slovenian translation plural-forms
-+-
 Reporter:  Gasper Zejn  |Owner:  Jannis
 |  Leidel
 Type:  Bug  |   Status:  new
Component:   |  Version:  1.2
  Internationalization   |
 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
-+-
Changes (by felixxm):

 * cc: Claude Paroz (added)


Comment:

 Claude, can you take a look? I think we can close this old ticket, because
 "plural-form" can be changed in Transifex.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.71b52f0f7f06a298b53adda1e3137175%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #13910: Add generator version of Template.render(Context)

2019-07-12 Thread Django
#13910: Add generator version of Template.render(Context)
-+---
 Reporter:  Ron Panduwana|Owner:  Petr Glotov
 Type:  New feature  |   Status:  assigned
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 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 Carlton Gibson):

 * owner:  Gagaro => Petr Glotov


Comment:

 [https://github.com/django/django/pull/11157 New 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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.39fab193657de37c8bcfd16996393a76%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #23004: Cleanse entries from request.META in debug views

2019-07-12 Thread Django
#23004: Cleanse entries from request.META in debug views
-+-
 Reporter:  Daniel Hahler|Owner:  Daniel Maxson
 Type:  New feature  |   Status:  assigned
Component:  Error reporting  |  Version:  master
 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
-+-
Changes (by Carlton Gibson):

 * needs_better_patch:  0 => 1


Comment:

 PR is looking good, but needs a little work on the docs, (as per review on
 PR).

 Daniel, I'd like to get this in: combined with #29714, it will clear up a
 whole group of the "Error Reporting" tickets. Please let me know if you
 need input or don't have capacity to finish it off.

 (Thanks for your effort! And same to all!)

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f2365ef2a4bfa7401bf7af7319db2645%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #13896: Change language to dynamic attribute in syndication feed generator

2019-07-12 Thread Django
#13896: Change language to dynamic attribute in syndication feed generator
-+-
 Reporter:  jedie|Owner:  Jason
 |  Kotenko
 Type:  New feature  |   Status:  closed
Component:  contrib.syndication  |  Version:  master
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by felixxm):

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


Comment:

 Closing as a duplicate of fixed #29352.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.101b411ecd956485f6ef34b3cee354a4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30634: "manage.py runserver" does not respect SCRIPT_NAME header. (was: "manage.py runserver" does not respect SCRIPT_NAME header)

2019-07-12 Thread Django
#30634: "manage.py runserver" does not respect SCRIPT_NAME header.
---+--
 Reporter:  Oleg Kainov|Owner:  nobody
 Type:  Bug|   Status:  closed
Component:  HTTP handling  |  Version:  master
 Severity:  Normal |   Resolution:  wontfix
 Keywords: | 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:

 I'm sorry but ''"... improving this server to be able to handle a
 production environment is outside the scope of Django."'' (see
 [https://docs.djangoproject.com/en/2.2/ref/django-admin/#runserver
 documentation]).

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.fd0d2783b2ca676504cf89624572815f%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30602: Raise ValueError in Extract lookups that don't work properly with DurationField.

2019-07-12 Thread Django
#30602: Raise ValueError in Extract lookups that don't work properly with
DurationField.
-+-
 Reporter:  cecedille1   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
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:"402e6d292fd8aa5dfd49166e80098122950053f7" 402e6d29]:
 {{{
 #!CommitTicketReference repository=""
 revision="402e6d292fd8aa5dfd49166e80098122950053f7"
 Fixed #30602 -- Made Extract raise ValueError when using unsupported
 lookups for DurationField.
 }}}

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.89ff2658d7ce9157b15c40d7a305d327%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


Re: [Django] #30634: "manage.py runserver" does not respect SCRIPT_NAME header

2019-07-12 Thread Django
#30634: "manage.py runserver" does not respect SCRIPT_NAME header
---+--
 Reporter:  okainov|Owner:  nobody
 Type:  Bug|   Status:  new
Component:  HTTP handling  |  Version:  2.2
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by okainov:

Old description:

> 0. Configure local nginx to emulate prod-like environment (i.e. when
> Django is running in Docker) and app should be in subfolder
>

> {{{
>  location /myapp/ {
> proxy_pass http://127.0.0.1:8000/;
>
>#proxy_set_header X-Script-Name /myapp;
> proxy_set_header SCRIPT_NAME /myapp;
>
> include proxy_params;
> }
> }}}
>

> 1. Run default Django app locally
> {{{
> manage.py runserver
> }}}
> 2. Debug any request and inspect request.META
> 3. Make sure request.META['SCRIPT_NAME'] is empty
>
> In the same time seems that running with uWSGI or something similar
> works. SO I assume the error is somewhere in `manage.py runserver`
> behavior
>

> Background:
> While I'm aware that `runserver` considered "insecure" and "slow", it
> doesn't really matter for me when I'm deploying small internal apps in my
> company (imagine ~10 users-app with <5 views). Since with `manage.py` I
> can run my app in "one click" and avoid hassle of separating static files
> serving and the main app, I would really like to keep it this way.

New description:

 0. Configure local nginx to emulate prod-like environment (i.e. when
 Django is running in Docker) and app should be in subfolder


 {{{
  location /myapp/ {
 proxy_pass http://127.0.0.1:8000/;

#proxy_set_header X-Script-Name /myapp;
 proxy_set_header SCRIPT_NAME /myapp;

 include proxy_params;
 }
 }}}


 1. Run default Django app locally
 {{{
 manage.py runserver
 }}}
 2. Debug any request and inspect request.META
 3. Make sure `request.META['SCRIPT_NAME']` is empty

 In the same time seems that running with uWSGI or something similar works.
 SO I assume the error is somewhere in `manage.py runserver` behavior


 Background:
 While I'm aware that `runserver` considered "insecure" and "slow", it
 doesn't really matter for me when I'm deploying small internal apps in my
 company (imagine ~10 users-app with <5 views). Since with `manage.py` I
 can run my app in "one click" and avoid hassle of separating static files
 serving and the main app, I would really like to keep it this way.

--

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1f4b97fc08737094f4063ef79ca38850%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.


[Django] #30634: "manage.py runserver" does not respect SCRIPT_NAME header

2019-07-12 Thread Django
#30634: "manage.py runserver" does not respect SCRIPT_NAME header
-+
   Reporter:  okainov|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  HTTP handling  |Version:  2.2
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 0. Configure local nginx to emulate prod-like environment (i.e. when
 Django is running in Docker) and app should be in subfolder


 {{{
  location /myapp/ {
 proxy_pass http://127.0.0.1:8000/;

#proxy_set_header X-Script-Name /myapp;
 proxy_set_header SCRIPT_NAME /myapp;

 include proxy_params;
 }
 }}}


 1. Run default Django app locally
 {{{
 manage.py runserver
 }}}
 2. Debug any request and inspect request.META
 3. Make sure request.META['SCRIPT_NAME'] is empty

 In the same time seems that running with uWSGI or something similar works.
 SO I assume the error is somewhere in `manage.py runserver` behavior


 Background:
 While I'm aware that `runserver` considered "insecure" and "slow", it
 doesn't really matter for me when I'm deploying small internal apps in my
 company (imagine ~10 users-app with <5 views). Since with `manage.py` I
 can run my app in "one click" and avoid hassle of separating static files
 serving and the main app, I would really like to keep it this way.

-- 
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 post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.ea06d1a53d74368d9db5b74adf85e923%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.