Re: Password reset link is not displayed by default

2023-07-24 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)
Hi!

You've found the wrong mailing list for this post. This mailing list is for
discussing the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy.

For support, please follow the "Getting Help" page:
https://docs.djangoproject.com/en/stable/faq/help/ . This will help you
find people who are willing to support you, and to ask your question in a
way that makes it easy for them to answer.

That said, in response to your question: Django's default admin setup does
not come with a password reset view. It only has a "change password" view
for logged in users. If you want to support not-logged-in users to reset
their passwords, you need to add a URL as you have done.

Thanks,

Adam

On Sun, Jul 23, 2023 at 2:40 PM Marty  wrote:

> Hi,
>
> this is native django 4.2 code:
>
> *admin/login.html*
>
> ...
>
> {% csrf_token
> %}
>
>   ...
>
>   {% url '*admin_password_reset*' as password_reset_url %}
>
>   {% if password_reset_url %}
>
>   
>
> {% translate 'Forgotten your
> password or username?' %}
>
>   
>
>   {% endif %}
>
>   ...
>
> 
>
> ...
>
>
>
> *auth/urls.py:*
>
> urlpatterns = [
>
> ...
>
> path("password_reset/", views.PasswordResetView.as_view
> (), name="*password_reset*"),
>
> ...
>
> ]
>
> In template is expected *admin_password_reset *but auth module generates
> *password_reset*.
> This is my project urls.py:
> urlpatterns = []
>
> if settings.DEBUG:
> urlpatterns += [
> path('__debug__/', include(debug_toolbar.urls)),
> *static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT),
> ]
>
> urlpatterns += [
> # API
> # path('api/ ', include('apps.management.api_urls')),
>
> # extra pages
> path('changelog/', management_views.changelog, name='changelog'),
>
> # (due to password reset)
> path('accounts/', include('django.contrib.auth.urls')),
> *path('accounts/password_reset/', PasswordResetView.as_view(),
> name='admin_password_reset'),*
>
> # modules
> path('authentication/', include('apps.authentication.urls')),
> path('management/', include('apps.management.urls')),
>
> # native admin URLs
> path('', admin.site.urls),  # must be last if admin URL is empty!
> ]
>
> Notice that I had to add the extra
>
> *path('accounts/password_reset/', PasswordResetView.as_view(),
> name='admin_password_reset'),*to display the reset password link. Is this
> on purpose in django or is this bug that should be fixed?
>
>
> 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/24afc193-c22a-4be8-9f3b-14315b2b7a8bn%40googlegroups.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/CAMyDDM3Jj87WR6xuKnfVwA_j%3Do0iGmVZLotYx0O5_311gaZRNQ%40mail.gmail.com.


Re: Ticket #34555 ModelBase prevents addition of model Fields via __init_subclass__

2023-07-24 Thread 'Adam Johnson' via Django developers (Contributions to Django itself)
I think a new section in the topics/db/models guide would make sense.

If we add anything to the reference documentation, it would be quite short,
like "Model classes support __init_subclass__ and you can add fields
within". That doesn't sound worth the space to me.

On Sat, Jul 22, 2023 at 1:19 PM Jonathan Clarke 
wrote:

> Thanks for this and sorry for the delay in coming back.  Good to hear we
> can go ahead!
>
> Understood about omitting the changes to _meta and only focussing on the
> changes that allow fields to be added via __init_subclass__, i.e. only
> making the changes in this PR:
> https://github.com/django/django/pull/16849
>
> Can I ask where a good place to document the support of __init_subclass__
> would be?
> Here are a couple of places I spotted that might be appropriate:
> - https://github.com/django/django/blob/main/docs/ref/models/class.txt
> - https://github.com/django/django/blob/main/docs/topics/db/models.txt -
> perhaps within a new subheading in the Model inheritance section?
>
> Once confirmed I'll amend the PR
>
> Thanks
>
>
> On Wed, 28 Jun 2023 at 10:28, 'Adam Johnson' via Django developers
> (Contributions to Django itself) 
> wrote:
>
>> I think we probably won't see much more input, but since Simon and I
>> don't have any major concerns we can go ahead. I would also like to see
>> documentation about what is supported within __init_subclass__.
>>
>> The update to make _meta available seems a bit more invasive. The tests
>> catch all kinds of corner cases that are hard to deprecate, so if they're
>> breaking that may mean the change is not easy or even possible.
>>
>> On Fri, Jun 9, 2023 at 1:39 PM Jonathan Clarke <
>> jonathan.a.cla...@gmail.com> wrote:
>>
>>> Hi all, just wanted to check in to see if a conclusion can be reached on
>>> this idea?  Thanks :)
>>>
>>> On Tue, 16 May 2023 at 19:17, charettes  wrote:
>>>
 Just wanted to publicly +1 here as well. I was skeptical that we could
 add support for it without invasive changes at first but it seems to be
 relatively straightforward to support.

 One ask I would add is that we explicitly document what is support and
 what isn't. For example, at the time `__init_subclass__` is called one
 should not expect `_meta` or any other subclass fields to be available and
 that even when calling `super().__init_subclass__`. That might come as a
 surprise to users that want to do anything to a trivial field addition
 (e.g. perform model introspection). For non-trivial use cases a
 class_prepared signal seems like it's still the best way to run code once
 the class is fully initialized.

 Changing these expectations could be done by moving most of the
 ModelBase.__new__ logic to Model.__init_subclass__ but this would require a
 massive re-enginering of meta programming logic that is remain unchanged
 for years.

 Le vendredi 12 mai 2023 à 09:38:04 UTC-4, Adam Johnson a écrit :

> +1 from me. As Simon covered on the ticket, the change is small.
> Making Django classes support __init_subclass__ might unlock some nice
> dynamic field patterns.
>
> On Thu, May 11, 2023 at 12:47 PM hottwaj 
> wrote:
>
>> Hi there, I opened the above ticket and submitted a PR with fix and
>> test added.  I was asked to bring the issue here for wider review before
>> the ticket is re-opened (if that is what people agree to do)
>>
>> For reference, links to the ticket and PR are:
>> https://code.djangoproject.com/ticket/34555
>> https://github.com/django/django/pull/16849
>>
>> The issue raised is that current implementation of ModelBase.__new__
>> prevents use of __init_subclass__ on a Model to add model fields
>>
>> e.g. the code listed at the end of this email does not currently work
>> (the PR fixes this).
>>
>> Currently the same result could be achieved by i) writing a new
>> metaclass e.g. BaseBookModelMeta or ii) using a class decorator where
>> cls.add_to_class(field) is called.
>>
>> Using __init_subclass__ is advised as a simpler alternative to
>> writing a metaclass to customise class creation, hence this PR.
>>
>> Hope that makes sense and appreciate any feedback.  Thanks!
>>
>>
>> class BaseBookModel(models.Model):
>> class Meta:
>> abstract = True
>>
>> def __init_subclass__(cls, author_cls, **kwargs):
>> super().__init_subclass__(**kwargs)
>> cls.author = models.ForeignKey(author_cls,
>> on_delete=models.CASCADE)
>>
>> class Author(models.Model):
>> name = models.CharField(max_length=256, unique=True)
>>
>> class Book(BaseBookModel, author_cls=Author):
>> pass
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe fro

Re: Fellow Reports - July 2023

2023-07-24 Thread Mariusz Felisiak
Week ending July 23, 2023

*Triaged:*
https://code.djangoproject.com/ticket/34712 - Prevent misconfiguration 
of `STORAGES` setting (accepted)
https://code.djangoproject.com/ticket/34716 - Class methods from 
subclasses cannot be used as Field.default. (accepted)
https://code.djangoproject.com/ticket/34711 - Make ChoiceField 
auto-detect and coerce values. (wontfix)
https://code.djangoproject.com/ticket/34718 - Allow 
django.contrib.admin's ListFilter to render details tag collasped by 
default (needsinfo)
https://code.djangoproject.com/ticket/34721 - 
ChoiceField/TypedChoiceField: .value() has inconsistent behaviour, coercion 
not applied. (invalid)
https://code.djangoproject.com/ticket/34720 - BaseReloader.watch_dir() 
incorrectly checks for existence of path (invalid)
https://code.djangoproject.com/ticket/34724 - Allow passing kwargs to 
django.contrib.admin.decorators.display (wontfix)
https://code.djangoproject.com/ticket/34727 - Error in CharField with 
TextChoices and missing max_length parameter (invalid)
https://code.djangoproject.com/ticket/34723 - `TypeError` when loading 
a Django app with incorrect type of `choices` (wontfix)
https://code.djangoproject.com/ticket/34731 - Django test suite still 
has an occurence of assertEquals, removed in Python 3.12 (accepted)
https://code.djangoproject.com/ticket/34729 - Add explicit option to 
enable IF EXISTS / IF NOT EXISTS in PostgresQL index operations (wontfix)
https://code.djangoproject.com/ticket/34732 - UnicodeEncodeError on two 
tests in Python 3.12 (invalid)

*Reviewed/committed:*
https://github.com/django/django/pull/17082 - Refs #27471 -- Made 
admin's filter choice arrows use cursor pointers.
https://github.com/django/django/pull/17087 - Fixed #34716 -- Fixed 
serialization of nested class methods in migrations.
https://github.com/django/django/pull/17073 - Fixed #34036 -- Improved 
color contrast in admin light theme.
https://github.com/django/django/pull/17084 - Fixed #34717 -- Fixed 
QuerySet.aggregate() crash when referencing window functions.
https://github.com/django/django/pull/17094 - Reduced unique constraint 
eligibility code duplication.
https://github.com/django/django/pull/17058 - Fixed #34701 -- Added 
support for NULLS [NOT] DISTINCT on PostgreSQL 15+.
https://github.com/django/django/pull/17099 - Refs #34362 -- Added 
get_child_with_renamed_prefix() hook.
https://github.com/django/django/pull/17100 - Refs #29789 -- Added more 
tests for FilteredRelation with condition outside of relation name.
https://github.com/django/django/pull/17103 - Fixed #34731, Refs #34118 
-- Replaced assertEquals() with assertEqual() in 
test_condition_with_func_and_lookup_outside_relation_name().
https://github.com/django/django/pull/17085 - Refs #24686 -- Made 
AlterField operation a noop when renaming related model with db_table.


*Reviewed:*https://github.com/django/django/pull/17078 - Refs #34711 -- 
Added reference to TypedChoiceField in ChoiceField docs.


*Authored:*https://github.com/django/django/pull/17079 - Refs #34118 -- 
Improved sanitize_address() error message for tuple with empty strings.
https://github.com/django/django/pull/17090 - Refs #33201 -- Avoided 
unnecessary queries when renaming models with db_table on SpatiaLite.

Best,
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/f47a6727-39cb-4b3f-8fb7-3e2c837fe8dcn%40googlegroups.com.