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 
<https://code.djangoproject.com/ticket/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.
  • Dis... Contributions to Django itself
    • ... Carlton Gibson
      • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
        • ... Contributions to Django itself
          • ... Mariusz Felisiak
            • ... 'Adam Johnson' via Django developers (Contributions to Django itself)
              • ... Contributions to Django itself
                • ... 'Adam Johnson' via Django developers (Contributions to Django itself)

Reply via email to