Enhance admin interface to provide a better way to add Items to Collections

[ColeDCrawford]

There should be a better way than adding comma separated IDs to select items. Right now this grabs any resource (object, photo, video) with the same ID and there's no way to disambiguate them. Ideally this should be an autocomplete field or similar. This is going to be a bit tricky to implement because the content is in Elasticsearch rather than Postgres with the rest of the Django content, but we at least need the disambiguation.

[lukehollis]

Hi @ColeDCrawford, what new method or improvements would you like added here for linking elasticsearch and the django database?

[ColeDCrawford]

Right now, this is how you're querying for items in ES - just on IDs. https://github.com/rsinghal/giza/blob/c6537f77f69acfb62b9b3273db025f8b15da3642/giza/views.py#L261-L310

As I said above, ideally this would be using an autocomplete box or something of the sort that queries ES and allows users to choose items. You should be storing a unique ID if that exists, otherwise creating a composite key (item ID + item type) to disambiguate items and then parsing that later to filter by item type + ID. The first sounds much better; @rsinghal do you know if there are UUIDs on items?

I guess you could do some hacky parsing (eg save video-12345,media-12345,site-23456) if you really want to stick with this but I already think the current system is brittle and not very usable from a UX perspective. The parsing breaks if you add a space anywhere in the string currently.

[rsinghal]

No UUID that disambiguates between categories. You need the _id and _type in ES. For example:

"_type": "objects",
"_id": "25316",

[ColeDCrawford]

We need an autocomplete box with a filter for object type. You will need to store both item type and item IDs for each reference because there is no UUID in Elasticsearch to be able to retrieve an item by a single key. The item type/category maps to the ES doc type (eventually separate indices, but we're still using ES v5). So even if we generated a UUID during ingest from TMS, and did it in a consistent manner, you would need to map that key back to a (not UUID) key + item type for querying ES. Making a change to ES to support querying by a theoretical UUID would be substantial at this point.

A number of plugins allow for remote URLs to external APIs as data sources for autocomplete. Eg see https://django-autocomplete-light.readthedocs.io/en/v2/remote.html