Multi-GEDCOM auto complete list incorrect - entering INDI record ID

[Fred Rawson]

Creating a new user where there are multiple (two) GEDCOM’s and manually entering the individual when specifying “GEDCOM INDI record ID” and ”Pedigree chart root person” the wrong GEDCOM list is sometimes displayed. Using the find individual button associates to the correct GEDCOM and works correctly. SVN-9213

[kiwi (kiwi3685-deactivatedaccount)]

From my local testing I would add:
1 - it looks like auto-complete is only returning results from the current GEDCOM, not from the one the INDI is being linked to.

2 - This also happens on my PGV site, so is a bug thats been around for a long time.

[ToyGuy (toyguy)]

Auto-complete has always had this action in these situations. It is probably not appropriate to have this field as auto-complete, especially since the look-up is directly adjacent. I can't see how auto-complete would search several gedcoms at once, and I think the returned result would only be confusing. I would suggest removing it rather than trying to 'repair' it.
-Stephen

[kiwi (kiwi3685-deactivatedaccount)]

Thats certainly one option. But I actually think this is a VERY appropriate situation to use auto-complete in. Ideally I would drop the lookup-button rather than remove auto-complete.

It should be possible to work, as the page does know which GEDCOM to use. It already uses it to display the different GEDCOM names. Its not necessary, or even desirable, to search several GEDCOMs at once - it only needs to search the one relevant to the input box being used. Unfortunately I don't understand how auto-complete works well enough to figure out how.

However, you are correct that it is designed / hard-coded this way (to only use the current GEDCOM). Thats clear from the function it uses (row 551 of autocomlete.php - get_autocomplete_INDI() ) . Unless someone else has an easy solution I guess this would have to become a Feature Request rather than a bug.

[fisharebest (fisharebest)]

<<Unless someone else has an easy solution>>

Fairly easy......

The autocomplete works by identifying HTML inputs by their ID. For example, an input of pid or rootid gets an individual autocomplete, while an input of famid gets a family autocomplete.

The autocomplete code could be modified to search for an ID that includes a gedcom. For example, instead of <input id="pid">, we could recognise <input id="id:7"> which would be an indication that we want to search the gedcom with a gedcom_id of 7.

The javascript code in autocomplete.js.htm would then extract this parameter, and pass it as an extra parameter to autocomplete.php

Within autocomplete.php, it is then trivial to use this value instead of the default/current gedcom.

[kiwi (kiwi3685-deactivatedaccount)]

Thanks Greg, I'll play around with that. perhaps I'll figure it out before you get back fro your hols.

[kiwi (kiwi3685-deactivatedaccount)]

Sadly, after playing around with this for a while I can't figure out how to do it. It looks like someone else had the idea but didn't follow through. Autocomplete in this case is using <input id=$varname> where $varname='gedcomid'.$ged_id;
But autocomplete.js.htm ignores the number, by using only "starts with gedcomid" (input[id^=gedcomid]).

Its actually getting "gedcomid1", "gedcomid2" etc where the numeral is the GEDCOM ID. But I can't see how to collect that from the element and use it.

Any help would be appreciated.

[fisharebest (fisharebest)]

I had assumed that somewhere in autocomplete.js.htm, we would be able to use something like

$(this).attr(id)

but this just returns "undefined". Perhaps, because it is inside the call to .autocomplete(), we don't have the right context to call this.

[kiwi (kiwi3685-deactivatedaccount)]

Which is the better short term solution:
1 - remove auto complete from this field (which means users with a single GEDCOM lose a feature that IS working for them)
2 - leave as is, on the basis that issues will be relatively rare (multiple GEDCOM sites adding frequent new users).

[ToyGuy (toyguy)]

I would vote for removal, at least until a fix, as IMHO, the feature is not very important since the lookup exists and there would seem to be more frustration by a lack of 'proper' operation and misdirection than no function.
-Stephen

[kiwi (kiwi3685-deactivatedaccount)]

I think I agree too, so have done that for now. (svn 9283)

[kiwi (kiwi3685-deactivatedaccount)]

(sorry - svn 9284)