Re: [Django] #30539: Django - “with / as” to fill block is not working. (was: Django - “with / as” to fill block is not working)

[Django]

#30539: Django - “with / as” to fill block is not working.
-+-
 Reporter:  Jay Day  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Template system  |  Version:  master
 Severity:  Normal   |   Resolution:
 |  worksforme
 Keywords:  templates, blocks,   | Triage Stage:
  with   |  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
 * ui_ux:  1 => 0
 * resolution:   => worksforme
 * version:  2.2 => master


Comment:

 Thanks for the report, however I cannot reproduce your issue. In all
 described cases everything works for 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/065.354510f988aac7200fe079cdf79ee6c4%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30537: ForeignKey: inconsistent handling of referenced obj. id. (was: ORM: ForeignKey: inconsistent handling of referenced obj. id)

[Django]

#30537: ForeignKey: inconsistent handling of referenced obj. id.
-+-
 Reporter:  Aliaksei |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:  ORM, ForeignKey, | Triage Stage:
  NOT NULL constraint,   |  Unreviewed
  inconsistency  |
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:   => duplicate


Comment:

 Duplicate of #28147.

-- 
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.5c5a574887c643c8436bbee84cd87730%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30535: Czech plural-forms is incorrect in translations. (was: czech translations for "This password is too short. It must contain at least %(min_length)d character." broken in django >=

[Django]

#30535: Czech plural-forms is incorrect in translations.
-+-
 Reporter:  Jakub Kaláb  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  master
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  0
-+-
Changes (by felixxm):

 * status:  new => closed
 * component:  contrib.auth => Internationalization
 * version:  2.1 => master
 * resolution:   => invalid


Comment:

 Thanks for the report, however, translations are handled at
 
[https://docs.djangoproject.com/en/dev/internals/contributing/localizing/#translations.
 Transifex] and not in this tracker.

-- 
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.97b457ed904503d91c82342912a4540b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30539: Django - “with / as” to fill block is not working

[Django]

#30539: Django - “with / as” to fill block is not working
-+-
   Reporter:  Jay-Dai|  Owner:  nobody
   Type:  Bug| Status:  new
  Component:  Template   |Version:  2.2
  system |   Keywords:  templates, blocks,
   Severity:  Normal |  with
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 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)

-- 
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.15da27084d9af8ad8b603ac49228330e%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #7835: Provide the ability for model definitions that are only availably during testing

[Django]

#7835: Provide the ability for model definitions that are only availably during
testing
-+
 Reporter:  Russell Keith-Magee  |Owner:  nobody
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  feature test models  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+
Changes (by Mark Gregson):

 * cc: Mark Gregson (added)


-- 
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.c168714609850b9c983555fa84fce999%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30511: Support Identity columns on PostgreSQL.

[Django]

#30511: Support Identity columns on PostgreSQL.
-+-
 Reporter:  Michael Kany |Owner:  Michael
 |  Kany
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres generated   | Triage Stage:  Accepted
  identity   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael Kany):

 sorry,
 I've seen that instead of the proposed two new Field classes
 ('IdentityAutoField': 'integer', 'IdentityBigAutoField': 'bigint',)
 Is it possible to extend the AutoField class like this?
 For example with:

 class AutoField (Field):
 ...
 generated_identity = False # for the serial or generated distinction
 generated_by_default = false # for GENERATED ALWAYS if false / GENERATED
 BY DEFAULT if true
 seq_opt_start_with = 1
 seq_opt_increment_by = 1

 def __init __ (self, generated_identity = false, generated_by_default =
 false, seq_opt_start_with = 1, seq_opt_increment_by = 1, ** kwargs):
 ...

 There is another ticket
 # 56 Primary key columns should be UNSIGNED
 that with the parameters
 seq_opt_start_with = 1
 seq_opt_increment_by = 1
 would fit if necessary. Test if seq_opt_start_with> = 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.281678674bb7c9d34f1d9d67f18a1712%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30511: Support Identity columns on PostgreSQL.

[Django]

#30511: Support Identity columns on PostgreSQL.
-+-
 Reporter:  Michael Kany |Owner:  Michael
 |  Kany
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  postgres generated   | Triage Stage:  Accepted
  identity   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Michael Kany):

 Ich habe gesehen, das es anstelle der vorgeschlagenene zwei neuen Field
 classes ('IdentityAutoField': 'integer', 'IdentityBigAutoField':
 'bigint',)
 Ist es möglich die AutoField-klasse so zu erweitern
 Zum beispiel mit:

 class AutoField(Field):
 ...
 generated_identity = False  # für die unterscheidung serial oder generated
 generated_by_default = False # für GENERATED ALWAYS wenn False/ GENERATED
 BY DEFAULT wenn True
 seq_opt_start_with = 1
 seq_opt_increment_by = 1

 def __init__(self, generated_identity = False, generated_by_default =
 False, seq_opt_start_with = 1, seq_opt_increment_by = 1,  **kwargs):
 ...

 Da ist auch ein anderes Ticket
 #56 Primary key columns should be UNSIGNED
 das mit den Parametern
 seq_opt_start_with = 1
 seq_opt_increment_by = 1
 gegebenenfalls  passen würde. Test ob seq_opt_start_with >= 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.8091b4d5dc7f79189f299bfbd8dc09e6%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30538: Inconsistent slug generation behaviour of slugify() and prepopulated fields in Django Admin

[Django]

#30538: Inconsistent slug generation behaviour of slugify() and prepopulated 
fields
in Django Admin
-+-
   Reporter: |  Owner:  nobody
  nomenklature   |
   Type: | Status:  new
  Uncategorized  |
  Component: |Version:  2.2
  Uncategorized  |   Keywords:  slugify
   Severity:  Normal |  prepopulated fields
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 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/dffa3e1992562ba60512d96d1eb58592ceb5/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/dffa3e1992562ba60512d96d1eb58592ceb5/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/dffa3e1992562ba60512d96d1eb58592ceb5/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/dffa3e1992562ba60512d96d1eb58592ceb5/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(' + removeList.join('|') + ')\\b',
 'gi');
 s = s.replace(r, '');
 }
 }}}

 With that, I recognise that there may be reasons accounting for the
 inconsistencies. One could also argue that I can just stick to using the
 
[https://github.com/django/django/blob/dffa3e1992562ba60512d96d1eb58592ceb5/django/utils/text.py#L393
 django.utils.text.slugify()] function, but I value the ability to
 prepopulate slug fields from Django Admin (of course with a more
 standardised behaviour).

 Perhaps someone can weigh in on this and see if we can or should
 standardise the implementation of both?

-- 
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/055.855864dbd900ca09800ca8f5c15facb7%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30537: ORM: ForeignKey: inconsistent handling of referenced obj. id

[Django]

#30537: ORM: ForeignKey: inconsistent handling of referenced obj. id
-+-
 Reporter:  AliakseiMi   |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  ORM, ForeignKey, | Triage Stage:
  NOT NULL constraint,   |  Unreviewed
  inconsistency  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by AliakseiMi:

Old description:

> In short: if referenced obj. is saved after attaching to a referencing
> obj. its id field (i.e. _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
> }}}

New description:

 In short: if referenced obj. is saved after attaching to a referencing
 obj. its id field (i.e. _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**

--

-- 
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.f07a68b0eb84ac9061c57747fd141e60%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

[Django] #30537: ORM: ForeignKey: inconsistent handling of referenced obj. id

[Django]

#30537: ORM: ForeignKey: inconsistent handling of referenced obj. id
-+-
   Reporter: |  Owner:  nobody
  AliakseiMi |
   Type:  Bug| Status:  new
  Component:  Database   |Version:  2.0
  layer (models, ORM)|   Keywords:  ORM, ForeignKey,
   Severity:  Normal |  NOT NULL constraint, inconsistency
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 In short: if referenced obj. is saved after attaching to a referencing
 obj. its id field (i.e. _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
 }}}

-- 
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/053.c13cadddfdcf8f9655392ccfffbdb52b%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #29043: test --keepdb says "Using existing test database" even if it's run for the first time

[Django]

#29043: test --keepdb says "Using existing test database" even if it's run for 
the
first time
-+-
 Reporter:  karyon   |Owner:  Hasan
 Type:   |  Ramezani
  Cleanup/optimization   |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * status:  new => assigned
 * owner:  nobody => Hasan Ramezani
 * has_patch:  0 => 1
 * needs_tests:  0 => 1


Comment:

 The patch needs tests. I don't know how to test it.
 Any suggestion?

-- 
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.9b20b69f29ba110a96053d831f460151%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30355: Specifying custom manager doesn't work with prefetch

[Django]

#30355: Specifying custom manager doesn't work with prefetch
-+-
 Reporter:  Kyle Mulka   |Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by robinh00d):

 * owner:  robinh00d => (none)
 * status:  assigned => new


-- 
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.8a24bb806ba7be12995c0a5415207d16%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.