BMIG recording form testing

[kitenetter]

This picks up from #1343

I added a record giving values for Habitat and Microhabitat:

When I subsequently view this record, it shows an erroneous value for "Location", an attribute that was greyed out during data entry:

If I try to edit the record, the "Location" attribute is not available, and the Microhabitat value seems to have been lost:

So there seem to be some incorrect links in the habitat hierarchies.

[burkmarr]

@kitenetter - these two issues are different so I'll deal with them separately:

1. The recorded microhabitat is not appearing selected when editing the record.
2. The 'location' attribute (a specific BMIG form sample attr - not the general iRecord one) on the record you entered had the value 'Built up area', even though you did not record a value. I'll deal with each separately below.

[burkmarr]

Problem 1 - the recorded microhabitat is not selected when you edit the record. This was a problem with the javascript file associated with this form (sites/default/files/indicia/js/node.9097.js). The script is responsible for enabling/disabling sample attribute dropdowns (exposure, location, management, ecotone, microhabitat and substrate) depending on the selected value of habitat. There was an initialisation step where by these were all cleared and disabled when the edit form is first shown. This step is not appropriate when the form is initialised from an existing record, so I fixed the script and it works now.

[burkmarr]

@kitenetter Problem 2 - the location sample attribute for the record you entered was set to 'Built up area' even though you did not set a value. This currently has me stumped. The BMIG location sample attribute (sample attribute id 1681) is linked to a termlist which only has three possible values (termlist id 1010):

1. Intertidal (termlist_term id 20254, term id 19169)
2. Splash zone (termlist_term id 20256, term id 19171)
3. Around HWM / strand-line (termlist_term id 20255, term id 19170)

Your record had the int_value 733 for the location attribute corresponding to the indicia term 'Built up area' (term id 733) which is referenced by two termlists - both habitat types for mammals (termlist ids 42 and 420). Termlist 42 is linked to sample attributes 'mammal habitat' (sample attribute id 109) and 'habitats within 200m' (sample id 482) and termlist 420 is to sample attribute 'type of habitat' (sample id 633).

I cannot understand how this value could have been assigned to your record. There's nothing unusual, as far as I can tell, about the way the BMIG location sample attribute is set up. I wondered if the javascript file that enables/disables the controls could have led to the value being set somehow. But the only time it sets a value for the location attribute is when the user clears the habitat selection and then the value is set to null. I don't see how it could lead to the term id 733 being set for location.

I've entered a couple of test records and have not been able to reproduce this problem with the location attribute. I wonder if you try again to see if you can do it replicating, as close as possible, the steps you took last time?

[burkmarr]

@kitenetter - forgot to say that for problem 1 you may have to clear your browsers cache for the page before the fixed javascript is picked up (e.g. on Chrome ctrl-shift-R).

[kitenetter]

@burkmarr I've just added this: https://irecord.org.uk/record-details?occurrence_id=34938924

and again it has the "Built-up area" attribute. Weird!

(I did clear the cache but I'm still not seeing the microhabitat term when going to the edit view of the record - however, I think I had iRecord open in my browser when I cleared the cache so possibly this didn't clear properly, or perhaps I should have cleared the Indicia cache as well - will test again tomorrow.)

[burkmarr]

Okay @kitenetter keep me posted. I already cleared the Indicia cache since uploading the file so you won't have to do that.

[kitenetter]

@burkmarr I've just done another test: https://irecord.org.uk/record-details?occurrence_id=34958139

The microhabitat is now displaying correctly on the editing form, but the link to "Built up area" is still getting added. I added the record via a different browser this time (Chrome, whereas I was using Edge previously).

So I'm consistently getting the same result, and it's odd that you can't reproduce it.

[burkmarr]

@kitenetter - I'll investigate further. Do you mind if I masquerade as you to try to reproduce? I will clearly mark as test record and ensure it is deleted afterwards.

[kitenetter]

That's fine @burkmarr and maybe you could record a few spiders to bump up my life list while you're at it :)

[burkmarr]

@kitenetter - this gets curiouser and curiouser. When I masquerade as you, I can consistently replicate the problem - the BMIG location attribute gets the value 'Built-up area'. Now I find that when I masquerade as me, I can also consistently replicate the problem, but the value is always set to 'Magazine'! (A term attribute used the termlist for an attribute that askes "where did you hear of the survey"). This is happening on the iRecord side, rather than the warehouse side, because I can see the values being sent in with the form payload, but I'm at a loss to explain it. I will ask John and Jim if they have any ideas.

[johnvanbreda]

@burkmarr I have tried a training record but the values were submitted successfully and stored OK. Are you saying that you have inspected the POST data sent by the form and you can see that it does include the value 733? If so, before pressing submit can you use the developer console to find inputs where the value=733? You could try the following:

$=jQuery
$.each($(':input,option:selected'), function() { if ($(this).val() == 733) { console.log(this); } });

[burkmarr]

Many thanks @johnvanbreda. Yes I was saying that I inspected the POST data. I didn't get a chance to do the jQuery because in the meantime the problem has 'gone away'. The only thing I changed was the caption associated with the sample attribute from 'Location' to 'Location in littoral zone' and the title of the associated term list from 'BMIG location' to 'Location in littoral zone'. I didn't do this to try to fix the problem - I just wanted to avoid confusion between the system location attribute and this BMIG one. But since I've done that, I cannot reproduce the problem - either under Martin's or my ID.

@kitenetter - can you confirm that the problem is no longer there for you?