andrewvanbreda
commented
7 years ago Further note on this issue. It is something I already thought about, although perhaps not with a satisfactory conclusion.
For instance, a scenario the importer already deals with is that there are plots with the same ID within the same plot group because of this issue. In this case, it blocks importing until it is fixed, although it doesn't say how to fix it.
Opening a new issue, after the information below was added to another thread
What happens if a user creates some plots (e.g. plots 1 and 2), but is then later given permission to access some plots created by another user with the same labels? How would the user load new samples to the first plot 1 and not the other plot 1?
AVB Response: When importing, the user can only ever import onto an existing plot within their own plot groups. So in theory someone else could have the same Unique plot ID but because it isn't in your own plot group it won't be imported onto. Therefore to import onto existing plots it must of been specified to have a plot group. Plots without a plot group at all cannot have further samples imported onto them, although I supposed you could always make a plot group with just one plot in it, there is no limitation on the number of plot groups a plot can have. This does indeed leave the scenario where as you say a user could be assigned a plot with a duplicate Unique plot ID into their plot group. This would need to be handled by the user interface. I think we would have to say if this situation is detected they would need to rename the plot when it is assigned, even if it is just adding some kind of tag on the end. The original user would probably need to be informed of the change, or alternatively depending on how complex we want to get, the original user could continue to see the original name
OLP response: Fine, good to have identified this potential future issue. Asking the user to rename their plot is the simplest issue, although this does get you into the situation where you might be asking a user to rename a long-established plot because another user has shared a plot group permission containing a plot with the same name, but which was very recently created (in this situation it seems unreasonable to ask user 1 to change their plot name when it had priority). I might be over-thinking this though!
Perhaps a long-term solution would be a check when plot group permissions are shared, with an automatic (but user approved) renaming of plots (e.g. a plot name::spatial ref concatenation) where there are conflicts.
Nested in #46