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
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!
Hi @Anastasia,
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.
1 Like
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.
Tanya
1 Like
Hi @ACWadmin1
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!
Hey all! I’ve got news and updates and estimates!
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. 
- Tanya
1 Like