In which Wildbook did the issue occur? Both Whiskerbook & ACW
What operating system were you using? Win 11
What web browser were you using? latest chrome
What is your role on the site? admin & researcher
What happened?
When 2 or more Marked Individuals are merged, the merged IDs show up under a category of “Other values”, not “Merged” as they did previously. This “Other values” category is not editable, like the other name or ID categories and like the “Merged” category used to be. Nicknames associated with merged IDs are also put in a different “Other Values” category that is also not editable (per example from ACW below).
What did you expect to happen?
Expect to be able to edit all ID or name categories & fields
What are some steps we could take to reproduce the issue?
Here’s an example from Whiskerbook: CHAEPI
Here’s an example from ACW: NaLe0013
The issue here is that very often, provisional or temporary IDs are assigned when a match is found between 2 un-ID’d annotations. Later, when a match is found with a previously ID’d individual, then the 2 ID kits are merged. The problem is that the temporary ID is retained in the un-editable “Other values” field and so the owner of the data is unable to delete the temporary ID, which is of no value to the user.
Previously, the “Merged” ID field was editable which is why this is logged as a bug.
Thanks!
Maureen
cc: @PaulK & @Lucas
1 Like
I need more time to research this one. I’ll let you know what I find out.
2 Likes
This was interesting to research and I’ll do my best to explain what I’ve learned.
The “Merged” value appears in old code that only appears in the context of a project. Since the individuals in your examples aren’t associated with a project, the “Merged” field won’t appear here.
“Other values” represents other default names a Marked Individual had before but doesn’t directly represent a merged value. It could have just been renamed without a merge occurring.
Nothing in the code for this has recently been updated and therefore, no data has been lost.
Hi @Anastasia, maybe I need to take a step back to highlight the problem we really have here. Whether it’s the Merged name category or another name category, such as Nickname or Other values, the name categories should be consistently editable. Currently, the default ID a field that is system-generated, is editable, as are other fields like Nickname. To have a name field that isn’t editable is inconsistent, whether it’s called the Merged category or Other values isn’t really the problem. It’s the editability that we need to have consistent across all name values.
If we “lose” the Merged name category, that’s fine; storing merged IDs in a “Other values” category works just as well. We just need it to be editable like all the other name fields.
I hope that’s clearer. Sorry for any confusion.
thanks
Maureen
1 Like