Appending RIN to names in reports

Quote from Mark Whidby on 2025-04-22, 3:53 pmTo help differentiate between contemporaneous people with the same Given-Surname, I'd like to append RIN to names in reports, such as Narrative.
It doesn't appear that RIN is a supported field in fact sentence templates, so is there a SQL approach I could consider?
To help differentiate between contemporaneous people with the same Given-Surname, I'd like to append RIN to names in reports, such as Narrative.
It doesn't appear that RIN is a supported field in fact sentence templates, so is there a SQL approach I could consider?

Quote from Tom Holden on 2025-04-22, 10:34 pmThis post could be of interest: Copy RIN to REFN. You cannot append the REFN fact type to the name in a sentence template other than for that fact type so that may not work for you. If the suffix name field for everyone is empty, you might consider plugging in the RIN to it. Try both manually on a person and see if the reports of interest to you benefit from either of them.
This post could be of interest: Copy RIN to REFN. You cannot append the REFN fact type to the name in a sentence template other than for that fact type so that may not work for you. If the suffix name field for everyone is empty, you might consider plugging in the RIN to it. Try both manually on a person and see if the reports of interest to you benefit from either of them.

Quote from Mark Whidby on 2025-04-30, 3:29 pmI don't think REFN will work, but I love the idea of using the suffix name field. I'll experiment with that. Thanks!
I don't think REFN will work, but I love the idea of using the suffix name field. I'll experiment with that. Thanks!

Quote from Tom Holden on 2025-04-30, 10:51 pmPopulating the name suffix field is also super easy as the RIN is already in the NameTable as OwnerID. I would do it only on the records for Primary Names (IsPrimary=1). Adding it to Alternate Names would be unneeded clutter.
Populating the name suffix field is also super easy as the RIN is already in the NameTable as OwnerID. I would do it only on the records for Primary Names (IsPrimary=1). Adding it to Alternate Names would be unneeded clutter.

Quote from Mark Whidby on 2025-05-02, 7:56 pmI really like this idea, and good point about IsPrimary.
I'm going to enclose the RIN in brackets in Suffix. Then I can turn off the setting to display RIN in the UI to reduce clutter. Instead of "Mark Whidby-5 [5]", I'll see "Mark Whidby [5]". This matches the format I've been using in my notes doc.
I really like this idea, and good point about IsPrimary.
I'm going to enclose the RIN in brackets in Suffix. Then I can turn off the setting to display RIN in the UI to reduce clutter. Instead of "Mark Whidby-5 [5]", I'll see "Mark Whidby [5]". This matches the format I've been using in my notes doc.

Quote from Tom Holden on 2025-05-03, 3:04 pmIf there is already a suffix value that does not contain a string in the format [n], then append the RIN. The regexp_replace() extension would be ideal for that purpose.One could readily strip and reapply RINs to the suffix should they not be wanted for some reason or need updating due to transfers or merges. Very fast as a single table scan.

Quote from Mark Whidby on 2025-05-04, 9:28 amAnother added benefit is it makes it very easy to distinguish individuals who have a record vs ones where I just "typed a name".
Another added benefit is it makes it very easy to distinguish individuals who have a record vs ones where I just "typed a name".

Quote from Tom Holden on 2025-05-04, 12:01 pmQuote from Mark Whidby on 2025-05-04, 9:28 ameasy to distinguish individuals who have a record vs ones where I just "typed a name".
except for individuals with a record created after the last time [RIN] was appended to suffixes. Maybe it makes sense to append to the names of witnesses who are not in the database something like " [n/a]". Then any name not having the [...] format in a display or printout signifies that the procedure needs to be run to resolve the ambiguity.
I've wondered if the privacy braces "{...}" in the suffix or the witness name are subject to the 'do not print' option in reports. I suspect it only applies when in a Note or a fact/event description.
Hope you'll follow up your original post in the RM Community with how your innovation is working out for you illustrated with images of displays or reports where you find real benefit.
Quote from Mark Whidby on 2025-05-04, 9:28 ameasy to distinguish individuals who have a record vs ones where I just "typed a name".
except for individuals with a record created after the last time [RIN] was appended to suffixes. Maybe it makes sense to append to the names of witnesses who are not in the database something like " [n/a]". Then any name not having the [...] format in a display or printout signifies that the procedure needs to be run to resolve the ambiguity.
I've wondered if the privacy braces "{...}" in the suffix or the witness name are subject to the 'do not print' option in reports. I suspect it only applies when in a Note or a fact/event description.
Hope you'll follow up your original post in the RM Community with how your innovation is working out for you illustrated with images of displays or reports where you find real benefit.

Quote from Mark Whidby on 2025-05-05, 11:42 amI plan to run my RIN append script frequently, certainly before any reporting or analysis, so I'm not worried about that situation. But, I'll give some thought to the "[n/a]" option, as well.
Yes, I plan to respond to the RM Community now that I'm satisfied with this approach.
Thanks again!
I plan to run my RIN append script frequently, certainly before any reporting or analysis, so I'm not worried about that situation. But, I'll give some thought to the "[n/a]" option, as well.
Yes, I plan to respond to the RM Community now that I'm satisfied with this approach.
Thanks again!