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.
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.
From a data integrity perspective, it makes sense that a history of past names/identities are preserved on the individual record and can’t be edited. I’m not sure I understand what problem specifically it’s creating.
If it’s more a matter of preference/wanting the data on the page to look cleaner, I can update this to a feature request. Just let me know!
We can modify the current name of the individual, which could present the same disadvantages on data integrity as those you mention ! And the same goes for the aliases where we indicate for example the national numberID of each individual.
In the majority of cases the old provisional name will be retained, but it may be necessary to edit it, for example if there was a typo in it, or if someone gave a provisional name very generic or very close to the name of another individual and source of confusion, or other cases. For example someone made a test (I think it was me !) and now one of our lynxes has the other value “provisoire1”, that we should obviously, at least as orgadmins, be able to delete to avoid future confusions.
Adding @tanyastere for visibility as I’ve now changed this to a feature request after verifying with Jason that the fields are working as originally intended.
Hey all!
I cannot speak to the historical behavior portion of this. I’ve never seen these fields work as described in the first post.
From my perspective, as long as the content is user-input, meaning it isn’t generated by the system, anyone with edit permission should be able to make changes. This sounds like a case where we had an automated process adjust user-input content and began treating it as system-generated, which would not be in line with our data access goals.
I still need to confer with @jason to discuss the original intention of the fields and make sure there isn’t a case I’m unaware of, though, as there may be technical considerations. That being said, you’ve officially made your case enough that this is now under-review.
We need to pull in additional team members to get this taken care of and coordinate those efforts, so I don’t have a timeline yet on when we can solve this. It’s definitely on the horizon since it will help us prepare for Codex in the long run. Thanks!
As usual, this is a lengthy effort. Shockingly, we’re starting on this week! Our solution involves data migration, which means that the solution will need to be done on each platform individually. We will start with Flukebook since it has the most complex database, and we are sure to capture all of the use cases we are likely to encounter. From there, we will start on your platforms, since you’re the reporters. Then the changes will go to the rest of the Wildbook platforms.
Thank you for your patience! We’ll give you a heads up when we get to the point where we’re tackling your platforms.
