Trait Names differ between different BrAPI endpoints

[zrm22]

Note: This is related to the Fieldbook Observation Syncing code.

The current Observation syncing pipeline is as follows:

1. In Field Activity. Select Menu for a given Field.
2. Select the Sync Observations option
3. Fieldbook will then go get the list of Traits for that field preferring the first synonym as the trait name.
4. Fieldbook will then get the list of observations
5. User clicks 'Save'
6. The traits are stored/updated in the Fieldbook DB
7. The observations are then stored in the Fieldbook DB
8. User then can go to the Collect screen and previously measured observations should show up as scored

The issue is that Fieldbook will store internally the first synonym if available, but the GET observation response's observationVariableDBId will be the actual trait name. This does not throw an error, but rather when going to the collect screen, the observations do not show up as the names are different. This can be fixed by changing the code in the BrAPI Service classes for the getTraits function to favor the Trait name over the synonym as then the names will match and the link is made between the observation, the trait and the plot.

What would be the best way to handle this? As it stands Fieldbook cannot likely make the connection between the Variable name coming from the observation response and the name that is currently stored in the DB. Is there a preferred way to pass around a map containing all the synonyms -> stored trait name which then the observation code could just look up the stored name.

[trife]

Am I wrong in thinking this is related to #471 and we just shouldn't be storing the name or synonym but allowing the user to select which is displayed?

[zrm22]

It's related, I think allowing the user to select which is displayed would be very nice, but we would need to make sure that there is some way to lookup a synonym to get that internal DB id and use that to associate observations, variables(Traits) and Units(Plots/Plants...) all together. This would likely solve the issue I am seeing.