Re: Discussion regarding #32628 and #32823

[Carlton Gibson]

Hi Sébastien. 

Sorry you feel hard done by here. I think that's perhaps unfamiliarity with 
the workflow. As per the triage workflow that Mariusz pointed you to, this 
is the correct place to discuss tickets that are marked as wontfix. 
The reality is we have a constant firehose of new tickets and do not have 
the capacity to go back and forth multiple times on the same ticket on 
Trac. 

What is more, the audience on the mailing list here is much wider that that 
on the issue tracker, which is why it's better to discuss things here. 
We do try and point folks this way, but it's not always clear I guess. 

So... 

Having looked at the ticket, I agree with the initial assessment: 

First, #32628 is suggesting a new feature to allow customising the ajax 
request used in the admin autocomplete view. At first pass, that's 
out-of-scope — that's not something that we want to add options around — 
it's simply not worth the complexity. Options include overriding 
autocomplete.js yourself, or building a custom view, rather than trying to 
extend the admin beyond its core use-case. 

This ties into your point 3 here. The wontfix comes with several 
suggestions, both from Mariusz and Johannes — both suggesting overriding 
the JS file as the most likely way forward for you. 

Then, sorry but, #32823 is just a duplicate. There's no bug there, unless 
you're looking to extend the JS in exactly the way you asked for in the 
previous ticket. That the usage of the underlying library's API does not 
allow holding it in an out-of-scope manner is not a bug (for Django). I 
hope that makes sense. 

So, to the suggestion... 

New features generally need motivating. My suggestion then would be to 
implement the alternate autocomplete.js and then show what it allows. "It's 
THIS PARTICULAR CHANGE and it allow THAT PARTICULAR USAGE" is a lot more 
powerful as a suggestion. 

However, it's not likely — not impossible, but not likely — that feature 
suggestions to add complexity to the admin autocomplete functionality would 
be accepted. 
Rather, I'm inclined towards Mariusz' initial comment that resolving #29700 
 to better document the 
autocomplete view would resolve the issue. We could include there 
customising the autocomplete.js side of it — perhaps your use-case would 
make a great example? In general we'd much rather go that way, instead of 
adding more complexity to the core itself. The admin's role is not to be a 
general application development platform, and we couldn't maintain it if it 
were: often that means we have to say no to possible features. The maxim 
that, if you need those features then implement a custom view, is part of 
the secret to its long life. 

Hopefully that all makes sense too. 

tl;dr: If you really want to make the case for this, implement 
autocomplete.js, help resolve #29700, then show that even with that in 
place this feature is needed for something that would be widely beneficial. 
This thread is the correct place for that discussion. 

I hope that helps. 

Kind Regards,

Carlton


On Monday, 7 June 2021 at 13:31:13 UTC+2 s.g...@b-sharpe.com wrote:

> Dear community,
>
> I am writing to this group as a last resort and as advised (twice) by 
> Mariusz Felisiak. I have several points to make.
>
> 1. Ticket #32823 is not a duplicate of #32628. #32628 was indeed a mixed 
> bag but mostly a feature request including a bugfix. #32823 was an attempt 
> to get the bug fixed ASAP while perhaps discussing the feature request made 
> in #32628 separately. This, apparently, was not understood.
>
> 2. I understand that a feature request might be disregarded, but ignoring 
> a bugfix with an offered PR is harder to understand for me.
>
> 3. Regarding the original feature request, I am disappointed that it got 
> flagged as wontfix before I even had a chance to make my point and be 
> understood. I later offered a slight rewrite of the autocomplete.js file 
> that implemented the feature (and fixed the bug) in a way that could be 
> accepted by Johannes Maron (not breaking Select2 API mirroring) but got no 
> answer.
>
> I understand that Django is a very large project and that you guys are all 
> volunteering to this.  I (and my company) am definitely willing to offer 
> developer time to help this project grow. But treating new-coming 
> developers like you did is just discouraging (to say the least), at least 
> for me.
>
> So will you please consider at least discussing the issues I raise here?
>
> Best regards,
>
> Sébastien Gélis
>

-- 
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/54eb64a3-38f9-4c6b-a79d-aa71f0c33ee9n%40googlegroups.com.

Adding a decorator to include a property in an object's serialization

[Diptesh Choudhuri]

Hello, I hope you are all doing well.

Currently if one wants to have custom properties on their models without 
introducing new columns, they have to use properties:

class Chapter(models.Model):
name = models.CharField()
text = models.TextField()

@property
def word_count(self):
return len(self.text.split())

chapter_one = Chapter.objects.first()

Now, the word count can be accessed using *chapter_one.wordcount*. However, 
when actually serializing this object, the wordcount isn't included:
{
  "name":"Technology",
  "text":"Some long text"
  // "wordcount": 3 <- this is not included
}

This problem can be fixed by updating the resultant serialization yourself.

serialized.update({ "wordcount": chapter_one.wordcount }) 

However, this quickly gets difficult once you have many such properties. 
There are workarounds for this (eg: using the* inspect *module) but they 
are difficult to understand and quickly result in unreadable code.

I propose we add a new decorator which will allow these properties to be 
included in the default object serialization.

*@column_property **# imported from django*
def word_count(self):
return len(self.text.split())

What do you think about this change? I think it'd be good since this won't 
introduce any backwards incompatible change. This change will especially 
benefit those who are creating some kind of API since they won't have to 
write complex code for such a simple use case.

I can open a ticket for this on djangoproject, and start working on this 
soon.

Thanks
Diptesh Choudhuri

-- 
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/b6f33375-cf76-421c-b6d4-3642d0bbb9f1n%40googlegroups.com.

Re: Default change password UX: area for improvements

[Markus Holtermann]

Hi Federico,

this is a good idea. Could you check if there's a ticket about this on 
https://code.djangoproject.com/ already, and if not, possibly open one. That 
would be much appreciated. Thank you!

Cheers,

Markus

On Mon, Jun 7, 2021, at 11:12 PM, Federico Capoano wrote:
> Hey everyone,
> 
> Given the following text in the user change page:
> 
> *Raw passwords are not stored, so there is no way to see this user’s 
> password, but you can change the password using this form.*
> *
> *
> Linking the change user password form using the word "this form" is on 
> the same level of links with "click here", which is notoriously bad UX 
> and I believe the django community is made of a lot of experts so there 
> shouldn't be the need to explain this here.
> 
> However, we can do better than just changing the link form, wouldn't it 
> be possible to add a link styled as a button?
> 
> Eg:
> 
> Raw passwords are not stored, so there is no way to see this user’s 
> password, but the password can be changed.
> 
> *Change the password*
> 
> BTW, this idea came from this issue: 
> https://github.com/openwisp/openwisp-radius/issues/265.
> We can easily fix it in our django app but I thought it may be good to 
> raise this here so we may fix it at the root instead.
> 
> Best regards
> Federico Capoano
> 
> -- 
> 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/CAERYH6VUm-bRsHkY_1LX9TwpJvMW%2B-Eyqf0Uye6FL%2B_Pb_%3D%2BQw%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/c73670f4-9324-467b-9861-48fff9eb326a%40www.fastmail.com.

Default change password UX: area for improvements

[Federico Capoano]

Hey everyone,

Given the following text in the user change page:

*Raw passwords are not stored, so there is no way to see this user’s
password, but you can change the password using this form.*

Linking the change user password form using the word "this form" is on the
same level of links with "click here", which is notoriously bad UX and I
believe the django community is made of a lot of experts so there shouldn't
be the need to explain this here.

However, we can do better than just changing the link form, wouldn't it be
possible to add a link styled as a button?

Eg:

Raw passwords are not stored, so there is no way to see this user’s
password, but the password can be changed.

*Change the password*

BTW, this idea came from this issue:
https://github.com/openwisp/openwisp-radius/issues/265.
We can easily fix it in our django app but I thought it may be good to
raise this here so we may fix it at the root instead.

Best regards
Federico Capoano

-- 
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/CAERYH6VUm-bRsHkY_1LX9TwpJvMW%2B-Eyqf0Uye6FL%2B_Pb_%3D%2BQw%40mail.gmail.com.

Re: IRC Archive

['Adam Johnson' via Django developers (Contributions to Django itself)]

Hi

I believe archiving stopped with the introduction of GDPR, which caused the
IRC archive bot we were using to shut down. GDPR made it quite unclear if
persisting chat logs (that users could assume to be ephemeral) would be
allowed. There was a previous django-developers thread on this.

Thanks,

Adam

On Mon, 7 Jun 2021 at 18:24, Douglas G  wrote:

> Hey, with the change from Freenode to Libera I was wondering if anyone had
> preserved Freenode IRC logs and made those available somewhere.
>
> Thanks,
> Douglas
>
> --
> 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/af0a70cb-2737-45b2-8b52-4ac9f9d1c543n%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/CAMyDDM2qsU9wHQiVsTfFJTa5tGXe8rKj3OBJxY5%2BpYshtpMrTw%40mail.gmail.com.

IRC Archive

[Douglas G]

Hey, with the change from Freenode to Libera I was wondering if anyone had 
preserved Freenode IRC logs and made those available somewhere. 

Thanks,
Douglas

-- 
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/af0a70cb-2737-45b2-8b52-4ac9f9d1c543n%40googlegroups.com.

Discussion regarding #32628 and #32823

[Contributions to Django itself]

Dear community,

I am writing to this group as a last resort and as advised (twice) by
Mariusz Felisiak. I have several points to make.

1. Ticket #32823 is not a duplicate of #32628. #32628 was indeed a mixed
bag but mostly a feature request including a bugfix. #32823 was an attempt
to get the bug fixed ASAP while perhaps discussing the feature request made
in #32628 separately. This, apparently, was not understood.

2. I understand that a feature request might be disregarded, but ignoring a
bugfix with an offered PR is harder to understand for me.

3. Regarding the original feature request, I am disappointed that it got
flagged as wontfix before I even had a chance to make my point and be
understood. I later offered a slight rewrite of the autocomplete.js file
that implemented the feature (and fixed the bug) in a way that could be
accepted by Johannes Maron (not breaking Select2 API mirroring) but got no
answer.

I understand that Django is a very large project and that you guys are all
volunteering to this.  I (and my company) am definitely willing to offer
developer time to help this project grow. But treating new-coming
developers like you did is just discouraging (to say the least), at least
for me.

So will you please consider at least discussing the issues I raise here?

Best regards,

Sébastien Gélis

-- 
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/CANSK4jZ2xD-v07QWKGLURYy-tA%3DW_%3DuxPqsxXWym-55yk7ZKNQ%40mail.gmail.com.