* cc: djangoproject.com@… (added)
* easy: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:23>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* cc: thijs.triemstra@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:25>
Comment (by etienned):
I just want to let you know that I did a [[https://bitbucket.org/etienned
/django-autocomplete/overview|fork]] of tyrion
[[https://bitbucket.org/tyrion/django-autocomplete|django-autocomplete]]
that add a little bit more integration with the Django Admin and other
things:
- Highlight (put in bold the search term in the results list)
- Auto Focus (automatically select the first result of the list) need
jQuery UI >= 1.8.11
- Zebra (colorize list rows in alternance)
- Simple Cache (cache each different query)
- Add button (the green plus to add a new item for a Relation Field)
- Lookup button (the loupe like in a RawIdField to select from the
complete list)
- Multiterms (possibility to have completion on many terms in one field
separated by a delimiter, for example: a tag field)
- Distinct result (get only distinct results for all fields excepted
Relation fields)
Maybe something there could help doing the integration to the Django
Admin. [[http://teknozen.net/django-autocomplete_etienned.png|Here's]] a
screenshot of it in action.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:26>
* cc: hv@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:27>
* cc: 4glitch@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:28>
* cc: cmawebsite@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:29>
Comment (by collinanderson):
patch using select2: https://github.com/django/django/pull/5609
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:30>
Comment (by RamezIssac):
May i ask why select2 ?!
Can this patch be done in a way that ease 3rd party integration , (or make
it optional to use select2) rather then changing the default ?!
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:31>
Comment (by codingjoe):
I don't know, this is `django.contrib.admin` not `core` were're talking
about. I don't see why we should improve it using more javascript
libraries.
I don't like the fact tho, that it is being distributed within our repo. I
would go for a CDN or some build method.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:32>
Comment (by aaugustin):
Not using a CDN is a conscious choice.
There are at least two reasons for this:
* privacy (avoid leaking info through the Referer header)
* offline use (download the tar.gz and the docs once and use them for
local development: not everyone on Earth has convenient access to a high-
speed, permanent Internet connection, in doubt we'd rather favor the use
case of the least privileged people)
I'm aware that these are social arguments, not technical ones, and I stand
by them.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:33>
Comment (by carljm):
And a third argument for not using a CDN -- we'd be quietly introducing
another point of failure into people's projects.
That said, the "or some build method" idea is probably a better one. It
might be nice if we used bower or something similar to automate pulling in
the outside JS dependencies, instead of manually vendoring them. But it's
also not really a big deal. Vendored dependencies are more easily
auditable, and everyone can figure out how to upgrade them when necessary.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:34>
* cc: ramezashraf@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:35>
Comment (by collinanderson):
'''why select2 ?''' It seems like a popular and mature library. I have to
admit I've never used an autocomplete library before so I'm a bit of an
imposter here. :) I'm a little scared that it just got major breaking
changes. What would you use? jQuery UI? Typeahead?
'''changing the default''' It's opt-in. You have to specify
`ajax_autocomplete = ['user']` or maybe you'll have to use
`formfield_overrides`. 3rd-parties could re-use the backend view.
'''vendoring / distributing with django''' I think it's a necessary evil.
I'm a little scared that we went from vendoring just jQuery to including
xregexp and Roboto in just 6 months. The native html5 `datalist` doesn't
seem good enough for the job, and I tried hand-writing autocomplete
javascript in django and quickly realized a dependency is a must.
Currently vendoring is the only option for django, and it's a reasonable
size (slightly smaller than jQuery, 80k vs 84k). I see this as the main
hurdle to getting this merged. We would need to run it by the
DevelopersMailingList for sure.
'''reusing django-select2''' I think the widget code in django-select2 is
much better than what I have, and of course django-select2 actually has
tests. I'd be interested in re-using those. I'm a bit worried about the
backend code. Currently I'm trying to implement this as similar to
raw_id_fields as possible. If we reuse the admin code we get permissions,
to_field, limit_choices_to, search, get_queryset, urls, etc for free. What
would it take to add the missing features to django-select2?
'''next steps''' I mostly made this pull request as a discussion starter
and to show what I think is a good way forward. I don't actually have the
energy right now to push this to completion, but I'd help review pull
requests.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:36>
* cc: info@… (added)
Comment:
I'm maintaining `django-select2` and wrote the current version. Let me
share my thoughts on integrating something similar in
`django.conrtib.admin`.
`django-select2` pickels the query and stores it in `django.core.cache`,
to work as a drop in widget. I think this would be a bit over the top. I
would suggest using `app_name`, `model_name` and `field_name` to uniquely
identify the relation.
From that point it should be possible to determine the queryset including
`limit_choices_to` constraints.
I think that `select2` is a great choice, I worked with other libraries,
but since `select2` version 4, I'd recommend it over other solutions.
If you want I could give it a shot. In any case feel free to use code from
`django-select2`.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:37>
Comment (by charettes):
I also think Select2 is one if not the best JavaScript autocomplete
library around at the moment.
I've tried alternative such as Chosen and multiple jQuery/Bootstrap
alternatives in the past and but just like @codingjoe said since version 4
Select2 is quite solid. It's a great shim that binds correctly to the DOM
state of the <select> it's attached to and doesn't require any extra
manipulation to be marked as disabled, focused, etc
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:38>
Comment (by jpic):
Since codingjoe told me a couple of days ago that he didn't know about
django-autocomplete-light (which i maintain) before he took over on
django-select2, it should be mentioned that django-autocomplete-light also
has support for generic foreign key which we might want in django admin as
well (and it supports django-generic-m2m too), supports add-another (even
outside the admin) and so on. While django-select2 might be lucky enough
that it gets its features inside contrib.admin, I'm affraid that DAL will
still require maintainance even in future versions of django. Anyway,
autocompletion is a really rich subject and I recommend to write the
documentation before the implementation itself, which use cases do you
want to support and so on.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:39>
* cc: jpic (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:40>
* cc: zachborboa@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:41>
* cc: tymoteusz.jankowski@…, tymoteusz.jankowski@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:42>
Comment (by guettli):
Just for the records. This comparison grid can help to find a matching
library: https://www.djangopackages.com/grids/g/auto-complete/
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:43>
* owner: nobody => codingjoe
* status: new => assigned
Comment:
James and me just discussed selectize.js vs select2.
We agreed that selectize is promising but doesn't have all the features
yet, to be implemented in django without much JS work.
Select2 seems to be the better choices because it supports html data
attributes.
We also discussed how to support `limit_choices_to` for the AJAX result
set. We're probably going to send the field reference to the AJAX endpoint
to figure out the `QuerysetChoices`.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:44>
Comment (by codingjoe):
Patch can be found here: https://github.com/django/django/pull/6385
There are still some implementation details to be discussed.
- Is this going to replace the RawIdWidget?
- Do we add a new `autocomplete_fields` attribute?
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:45>
* cc: eduardocereto (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:46>
* cc: andreterra@… (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:47>
* cc: kevin-brown (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:48>
* needs_better_patch: 1 => 0
* needs_docs: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:49>
Comment (by yeago):
I'd like to raise something else for discussion...
Regarding permission checks, I think matching the way raw_id_fields would
just be building in unwanted limitations in many cases. Firstly, the
permission says 'change' where no change is occurring. It just seemed like
the original implementation was taking a short-cut by using that
permission (since it was effectively a pop-out changeview).
In many cases, someone may want to grant access to a form that has an
autocomplete list of users but that doesn't mean they want to grant change
access to their user list. Moreover, we're already granting a permission
when we are allowing access to the admin form the autocomplete would be
used on. I'm not sure what case we are covering by granting access to a
form but not granting access to the autocomplete we explicitly added.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:50>
Comment (by codingjoe):
Replying to [comment:50 yeago]:
> I'd like to raise something else for discussion...
>
> Regarding permission checks, I think matching the way raw_id_fields
would just be building in unwanted limitations in many cases. Firstly, the
permission says 'change' where no change is occurring. It just seemed like
the original implementation was taking a short-cut by using that
permission (since it was effectively a pop-out changeview).
>
> In many cases, someone may want to grant access to a form that has an
autocomplete list of users but that doesn't mean they want to grant change
access to their user list. Moreover, we're already granting a permission
when we are allowing access to the admin form the autocomplete would be
used on. I'm not sure what case we are covering by granting access to a
form but not granting access to the autocomplete we explicitly added.
It's not implemented that way. In fact you need change permission on the
model the you are currently editing not the related object. e.g. If you
have access to groups but not to users, the groups m2m autocomplete would
still work.
Does that solve the issue for you?
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:51>
Comment (by codingjoe):
Since there are so many people following this ticket. Please review. From
where I'm standing this ticket is only shy of a review to be merged into
1.10. So please, please, please :)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:52>
Comment (by yeago):
@codingjoe I'm not sure that you understood properly what I am saying,
because I'm not wrong. Go look at a raw_id_fields to a user object then,
as a user without the user.change permission, try to edit that field. You
will get a Forbidden error. You need the user.change permission in order
to pull up the eyeglass required to populate a raw_id_field. The only
argument is whether this is a feature and not a bug.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:53>
Comment (by collinanderson):
yeago: I think codingjoe is saying that his autocomplete is implemented
differently from raw_id_fields. In his implementation, you need change
permission on the model the you are currently editing not the related
object. (Try it out and see if you agree.)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:54>
* cc: djangoproject.com@… (removed)
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:55>
* needs_better_patch: 0 => 1
Comment:
Not an extensive review yet, but I left some comments for improvement on
the PR.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:56>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:57>
* needs_better_patch: 0 => 1
Comment:
As Florian noted on the PR, "Using the "edit"-icon next to a FK does not
update the autocomplete widget."
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:58>
Comment (by James Pic):
I thought this was supported upstream:
https://github.com/select2/select2/commit/ea79a197e0ffe55aa600eed6d18cbd1c804c3176
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:59>
Comment (by Johannes Hoppe):
@James
yes, but that only works for actual option tags doesn't it? In this case
the we are only using a JSON API and the dynamic options.
I haven't looked into that yet. You are a better JS coder than me. I would
greatly appreciate a patch or suggestion form your side.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:60>
Comment (by James Pic):
This is the code that does the trick for me: https://github.com/yourlabs
/django-autocomplete-
light/blob/master/src/dal_select2/static/autocomplete_light/select2.js#L91-L97
{{{
// Remove this block when this is merged upstream:
// https://github.com/select2/select2/pull/4249
$(document).on('DOMSubtreeModified', '[data-autocomplete-light-
function=select2] option', function() {
$(this).parents('select').next().find(
'.select2-selection--single .select2-selection__rendered'
).text($(this).text());
});
}}}
Just replace `[data-autocomplete-light-function=select2]` by your own
select tag selector and you should be good to go.
However, it was meant as a temporary fix even for DAL, so I'm not sure if
this is of any help to you. I would suggest to add a breakpoint somewhere
in the code that Kevin's patch adds or changes and hopefully if it's
executed at all then the solution should be easy to find.
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:61>
Comment (by James Pic):
Ok so I was wrong, here's the new ticket for this issue:
https://github.com/select2/select2/issues/4733
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:62>
* needs_better_patch: 1 => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:63>
Comment (by Tim Graham <timograham@…>):
In [changeset:"01a294f8f014a32e288958701540ea47dcb9fc14" 01a294f8]:
{{{
#!CommitTicketReference repository=""
revision="01a294f8f014a32e288958701540ea47dcb9fc14"
Refs #14370 -- Vendored Select2 4.0.3 for use by the admin.
From https://github.com/select2/select2/releases/tag/4.0.3
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:64>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"94cd8efc50c717cd00244f4b2233f971a53b205e" 94cd8ef]:
{{{
#!CommitTicketReference repository=""
revision="94cd8efc50c717cd00244f4b2233f971a53b205e"
Fixed #14370 -- Allowed using a Select2 widget for ForeignKey and
ManyToManyField in the admin.
Thanks Florian Apolloner and Tim Graham for review and
contributing to the patch.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:65>
Comment (by Tim Graham <timograham@…>):
In [changeset:"f13bd321105c1d83903040ae02e21da2bbd4db0c" f13bd321]:
{{{
#!CommitTicketReference repository=""
revision="f13bd321105c1d83903040ae02e21da2bbd4db0c"
Refs #14370 -- Fixed typo in ModelAdmin.autocomplete_fields docs.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/14370#comment:66>