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.