Closed andrewvanbreda closed 7 years ago
No problem. At the moment I suggest that we just stick with what we have, to save increasing development costs. So, it is fine that the importer throws an error if names are not provided. Guidance can instruct users to provide names; at the very least they can copy and paste spatial refs into the plot names field themselves.
In the longer-term your idea
Currently there is a workaround and to create a duplicate column of the spatial reference and call that Plot Name, this then maps to the “Location (from controlled term list)" database field.
would be fine, but, i don't think we should put resource into this now.
Note that #58 has a comment regarding the renaming of the "Location (from controlled term list)" field:
Map screen: 'Sample :: Location (from controlled termlist)' This is the plot name that the sample is associated with, correct? In which case, can it be called 'Unique plot ID'?
Yes, the Location (from controlled term list) does need changing, yes it is the plot name associated with the sample. I will added it to the issue I created about incorrect terminology in the importer.
OK, given what you said I will leave the problem I described in this issue, however I will at least visually remove the current exception error from the screen, hopefully I can do that simply by making the 'Unique plot ID' mandatory
I just need to speak to Biren about the warehouse still before the import will work, I think the configuration file has become overwritten again, but I will mail him about that as it is separate and not causing the error I saw.
I have now corrected the exception the user would see if the Unique Plot ID (location name) was not mapped. Actually again we have a very simple fix, where if the column isn't mapped I tell the system that the Unique Plot ID is the same as the spatial reference. No error, and the user can also continue as normal. I know we said to hold on this, but it was very simple to implement, simpler than a warning
@sacrevert My main question is do we need to tell the user this has happened (which adds quite a lot of complexity) or are you happy for the code to handle this invisibly? (or perhaps you disagree with this approach completely)
@andrewvanbreda great, all sounds excellent. I don't think we need to tell the user in a responsive way, we can just state that this will happen in guidance documentation. Happy for this to be closed if you are.
Yes I will close once I make the code commit. Not committed to Github yet
Hi @sacrevert
As previously reported, there are currently errors on the Plant Portal Plot Importer, in order to get that far into the importer, I needed to change your import file as it currently isn't valid (for instance, as previously mentioned, the rows going into a single sample currently have different spatial references) However if I create an altered version of your file I am able to proceed...at least I tried on my own box which was behaving the same way
The error I was seeing is not caused by a configuration problem at all, but a difference in the way your importer file is setup, and the ones I was using to test. I originally changed your file, but it was so long ago, I forgot it was causing errors.
The problem is simple. Plots are locations, but your import file doesn’t specify an plot name to go into the location name in the database. I could simply change the code to specify the spatial reference to go into the plot name, or do you want plots to actually have a name separate from the spatial reference. Currently there is a workaround and to create a duplicate column of the spatial reference and call that Plot Name, this then maps to the “Location (from controlled term list)" database field.
Nested in #46