1.3.0: edit_interface.php source citation autofill is taken from wrong source

[Frank Warius]

Hallo

if you have an event with 2 sources (S1 and S2)
(like the death event in http://wbt.warius.info/individual.php?pid=I10223&ged=Warius.ged&lang=en_US)
and you add the second source (S2) to the event (inedit_interface) the autofill information for the citation details of the second source (S2) is taken from the first source (S1) and not from S2

regards
Frank

[kiwi (kiwi3685-deactivatedaccount)]

Autocomplete takes its information from ALL sources, not from any one attached just to this indi or event. .

[ToyGuy (toyguy)]

Nigel
Not exactly.
It used to do so, but no longer does for SOUR.
If I have NEW YORK in a 1920 census Citation and SOUR S1920, but do not have it in the S1930 (1930 census), it does not find and offer New York as an option. A/C is now limited by the SOUR selected.

I have not been able to test Frank's hypothesis, but it is a likely outcome.

[ToyGuy (toyguy)]

Frank is correct. See attached - no suggestions for 1910

[Frank Warius (frank-warius)]

this might be intended, but isn't implemented.

In 1.3.0 version we have a new behavior.

Autocomplete for citation is taken only from one (the first) source. So if you have two sources in one event, autocomplete for citation for the second source shows only text from the first source

[wooc (wooc)]

In the log I see:
ERROR 2: preg_match() [<a href='function.preg-match'>function.preg-match</a>]: Unknown modifier '1'; 0 Error occurred on in function preg_match 1 called from line 355 of file autocomplete.php
I think it could be related.

[fisharebest (fisharebest)]

@wooc - I've submitted a fix for this. It is caused by searching for data that contains a "/" character.

[jon48 (genea-jaubart)]

Hello,
Concerning the initial issue, it comes from the way the source value is called. It is indeed coded like: jQuery("input[class^=SOUR]").val(), but this will take only the first element which class starts with "SOUR", hence it is picking the first source value, and not the associated one.

I faced this issue for a personal module I have developed.
For information (I do not say this is the best implementation, and I find it myself not very clean), the way I have fixed it is creating ID with a fixed prefix for a specific fact and a random number shared by the fact we want to associate like for instance #SOUR28421415 and #PAGE28421415. Then I call the JavaScript :

$('.PAGE').each(function(i, el){ /* We are going to iterate through each SourcePage fact, based on the class */
  el = $(el);
  el.autocomplete({
   source: function(request, response) {
    $.ajax({
     url: 'autocomplete.php',
     datatype: 'json',
     data : {
      term : request.term,
      sid: $('#SOUR' + el.attr('id').substring(4)).val() /* el.attr('id').substring(4) takes the value of PAGE28421415 and extract the ID than concatenate with the prefix for sources*/
     },
     success: function(data) {
      response(data);
     },
              error: function(xhr, textStatus, errorThrown) {
                  alert('Error: ' + xhr.statusText);
              }
    });
   },
   delay:500,
   select: function(event, ui){
    el.val(ui.item.value);
    el.change();
   }
  });
 });

The above is adapted from my own code, so all parameters might not be useful, and uses a slightly different call than standard autocomplete, but I am sure the jQuery.getJSON fonction could be called, the important bit, being the iteration over the .PAGE class, the retrieval of the id, and then the concatenation to the SOUR prefix to retrieve the associated value.

Jonathan

Regards.

[fisharebest (fisharebest)]

I believe this was fixed as part of #1381212

[fisharebest (fisharebest)]

Fix released in 1.6.1.

[Frank Warius (frank-warius)]

positiv tested with 1.6.2
Thanks
Frank