Observations is not correctly handling observers on edit pages

Issue Description

The edit form for observations is incorrectly validating observers.  It is adding a false extra observer on load that is not editable and fails validation.  Furthermore, a large number of the observations migrated from ACD last a node reference and have similar validation issues.  Both must be solved promptly to facilitate the data export.

Proposed Solution

  1. Remigrate/update ACD export to include node referenced Observers
  2. Review edit/observer dialog behavior on edit form


Original Issue

Jim tried unsuccessfully to DELETE the online Observations record (/node/366119) which is a duplicate of a previously submitted and entered observation (PCD OBSNO 162291).  Derek Antonelli was testing the "new" online observations form when this record was entered as a test.  The same issue continues to come up, throwing the error message “Observer also requires the following parts: Given.” any time a modification to the record or deletion of the record is attempted.  Currently can not actually delete the record! Nor is the check box to make the record “unpublished” available.  Note that the location of this record has been mapped in Montana, but actually occurs in N. Idaho.  Changes can not be saved to the location due to the Observer:Given issue listed above.

Duplicate record, to be deleted, can be found at:


Action Items:  

1. Follow up with Ben & Brent on deleting this eroneous observation.  {deleted /b}

2. Acquire access to making observation reports "unpublished", when deemed necessary due to error.  {permission granted already, validation rules broken in form /b}

I was able to delete this

Priority: -> critical
State: -> active
Client: -> Observations
Assigned: unassigned -> idfg-bthomas

I was able to delete this record by bypassing edit form validation and browsing directly to https://fishandgame.idaho.gov/species/node/366119/delete

Though this small issue is solved by hacking around form validation, this issue is a larger problem based on the inaccurate handling of observers.  This same issue is related to problems Luana has faced editing observations.  I'm marking this as critical and assigning to myself.  This is priority 1 for Monday morning.

Well... if you're going to

Well... if you're going to work on it, a related issue we found researching this is that "observer confidence" isn't being transferred to the observation node from the person node.  This is problematic because we'll need the observer confidence as part of our algorithm to make the total observation confidence percentage.


This was by design.  We can,

This was by design. 

We can, but we hadn't planned to archive observer confidence in the observation

Do we want it fluid tied to the observer so we only have to update once?  Or do we want to static tied to the time when the observation was made?

Observer confidence values for Observations

There seems to be a `double-edged sword' answer to this.  Do we want the cofidence to fluidly grow as we acquire or assign better information to the Observer? Or, do we want a static archive of the observation at the time it was made?  Just like a confidence rating getting better, the skills of the observer may also get better with time.  There is value to both options.  The answer to this question should involve other players opinions (e.g., Lynn, Bill, Nikki, ...).

I have tracked down the

I have tracked down the culprit.

Migrated observations bypass (by design) some of the validation.  This allowed the creation of persons (observers) and observations that had a family name but no given name. 

We had made family name optional but given name required.

Due to the way that the code behind observations updates the record, when validation is fired, regardless of who the new observer may be, the old archived observer fields (separate hidden textboxes) are tested against.

Working on a solution now.

Moved the discussion of observer confidence to its own ticket #1001 Save Observer Confidence in the Observation

The full name widget requires

State: active -> pending

The full name widget requires either a given or full name.  At this time I have given name required, because it makes the most sense to propogate a username to a given name field.

This may not be the best choice though.

Presently we have 1,900 records with no given name and 79 with no family name.  One of the two of these has to be modified. 

I'd like to chat with y'all about this and make a decision on this in the morning and edit the database so that all records pass.  My preference is still given name required, to encourage reporting, but I can be swayed.  I did test switching the validation to family name required and the test case Nikki sent me was editable.

Full name updated, tests needed

State: pending -> needs review

I have changed the name widget to only require family (last) name.  We have to require something, we can't take just empty string.

I also updated all the existing data to include a family name, and changed the way the webservice is handled when a new reporter visits.  All new reporters are required to provide a given and family name.  When creating a new observer (person) a reporter is only required to provide a family name.

This fixed the documented problem for Observation #567099.  Combined with my earlier patch for reassigning anonymous observations and the migration update, this should fix all observer issues documented.  (Though I realize there are still many user interface improvements ahead)

We need some tests to make sure that all observers may now be edited.  Updating to "needs review".  Let me know if you experience issues.

One week has passed, seems

State: needs review -> closed

One week has passed, seems patch is working and observers are editable. 

PCD needs a new import to fix problems with observers, but that is a separate issue unrelated to the UI.