Overwriting trait when switching trait lists

[bhoeckel]

Hello,

We are encountering an issue we have not had in the past. When swapping between different trait lists for various crops we work on, the traits collected in text format disappear from the collection page. However, they are saved in the background data which you can visually see in both the spreadsheet grid and the variety summary toolbar tabs but can't be added to. When we write more comments in the same text trait and save them it will overwrite all of the previous text as if you clicked into an Excel box and started typing without clicking into the upper text box to place the cursor at the end of the comment, if that makes sense. In previous years, the trait data would always re-appear and automatically take the cursor to the end of the last comment to continue adding comments over multiple visits throughout the season.

The specific steps to recreate the issue are this:

Collect/type comments into a text trait
Finish collecting data and export field data
Switch to a different field/trial
Import new trait list for new field/trial, click no to export trait list, click OK to delete all traits
Then when you eventually switch back to the original field and trait list to collect more data, you can see the data issue described here

Is there a new setting to preserve those comments? and make them editable?

We’ve tried using the “repeated measures” feature in the experimental setting but that did not solve the issue.

My current plan was to create one long trait list for all of my crops that I work in (rather than separate trait lists for each crop) and then never swap out the trait list when switching between fields/trials. It will be a long cumbersome trait list, so any other suggestions would be much appreciated!

Thanks!

[trife]

Hi @bhoeckel
Apologies for the late reply- the summer really got away from me. This is a consequence of a change that was made to solve a different issue:

Previously, the trait name was used to store individual observations and query across tables. If the trait name contains certain characters, this can break some of our more complex database queries. To solve this, we are now using the internal numeric ID of the trait. However, this ID autoincrements and is auto assigned as traits are created or imported. So for a trait list, exporting/deleting/importing results in traits with new IDs.

In the long term, we're working on moving to a system where Field Book maintains a master list of traits and sublists are assigned to individual fields/experiments (likely in v6.1, aiming for next year). Does this solve your issue or would having a master list with traits mixed by crop be a problem?

In the short term, @chaneylc what solution should we implement here? Negative IDs for deleted traits that are flipped to positive if/when they're imported? Or will that cause additional issues?

[chaneylc]

I think we should wait until the v6 implementation. Allowing this and having a dialog saying the data will be deleted is confusing.

[bhoeckel]

I believe the interim solution we landed on is to have a master list of traits and to just select/deselect the traits that apply to the fields accordingly from that list. This seems to be working for now.