Reason statements for source detachments are not visible.

LegacyUser

Jan Martin Ekenes said: Reason statements for detaching sources should be visible but the only thing that carries over is the reason the source was attached to that person in the first place. This should be fixed.

LegacyUser

joe martel said: Thanks. That looks like a bug.

LegacyUser

Jan Martin Ekenes said: Thanks for you reply. I guess the bug will be addressed?

LegacyUser

Cherie Gardner Rawlings said: If it’s a bug, it’s been with us from the beginning. Nor do reason statements created when detaching relationships show up anywhere.

LegacyUser

Alan E. Brown said: Reason statements for detached sources are indeed visible. You just have to look in the change history for the person. Here's an example from https://www.familysearch.org/tree/per... (you have to scroll down to October 5, 2016 to see this one).



I'm wondering where else you might expect to see that reason statement. After all, the source is no longer attached to the person, so there's nowhere in the list of sources for a person that it could be shown. The change history seems like the correct place.

The same is true for relationships. If, for example, you remove a son from the relationship to his parents, that son no longer is related to those parents, so those parents will not show up in the son's details in the Family Members section. But the removal of the son from those parents will indeed show up in the son's change history (and will also appear in the change history for each of the parents). Such entries in the change history will include "Reason This Relationship Was Deleted."

LegacyUser

Amy Archibald said: The reason statement for detaching is showing the reason why the source was attached in the first place. The system is NOT showing the reason why it is being detached in the change log.

LegacyUser

ATP said: Just today I detached a child attached to parents without any sources provided as to why they should be attached and I provided the reason for the detachment which showed up in the change log. Almost immediately I received a message from the person who erroneously attached them. He admitted he did not read the change log and now we both are working together on this family line.

It seems then the responsibility for providing the reasons for attaching and detaching lies with the person who does the attaching and/or detaching.

LegacyUser

Amy Archibald said: This is the problem:

When you detach a source and enter in your reason statement for detaching, that statement is NOT showing up in the change log.

What is showing up in the change log is the reason statement that was entered by the person who attached the source in the first place.

Person #1 - attaches source and states for a reason "This matches".

Person #2 - detaches the source and states for a reason "This source does not apply to this person, this source belongs to the uncle of this person with the same name."

The Change log show the following:

Attachment from person #1 - "This matches"

Detachment from person # 2 - "This matches"

No where in the change log is it showing this statement from Person #2: "This source does not apply to this person, this source belongs to the uncle of this person with the same name."

****
This is a BUG!

It has happened before and was resolved in the past. It needs to be fixed again.

LegacyUser

Brett said: ATP

I am sorry to disagree ...

But, the "Reason" a "Source" was "Detached" should be 'available' to see and 'speak for themselves', just (exactly) like the "Reason" a "Source" was "Attached" does - of course, provided a "Reason" is included (in both instances).

I have had many instances where "Sources" that I "Attached" (and know were correct), that were later "Detached" by another User/Patron - where, either, there was NO "Reason"; or, the "Reason" was not correct/did not apply.

Such "Reason Statements" as to WHY a "Source" is/was "Detached" ARE "Important".

Brett

.

LegacyUser

joe martel said: Amy is correct. It probably has been a long-standing bug. The action in the changelog show the attribution (the date and contributor user that pushed the button) and the Reason for that transaction. On the Attach action it should show the Reason the user entered at Attach, and on Detach action should show the Reason that user entered to Detach.

LegacyUser

Jan Martin Ekenes said: I absolutey agree and Family Search needs to fix this bug.

LegacyUser

Alan E. Brown said: I don't understand what Amy and Joe are saying -- it does not match my experience. In the change log I see the attach with its reason and the detach with its reason. I just tested it and it worked exactly as expected. I made sure that my attach reason and detach reason were distinct. Here's the screen shot of the resulting change log.

LegacyUser

Jeff Wiseman said: Alan, I wonder if the confusion here is coming from something I had observed over a period of time in the past. If the person detaching the source doesn't actually enter a reason, then the original reason for attachment is still displayed.

In other words, if you don't enter a reason in the reason field, there is nothing to automatically blank out the reason for whatever the previous action was.

LegacyUser

Jan Martin Ekenes said: Alan, This is not what happened to me. I detached 27 sources from Signe Andersdatter LQ5N-WMV on 22 February and gave thoughtful and explicit reason statements, none of which showed up in the change log. The reason statements that appear in the log for the detached records are the same as the reason statements were for attaching the records to this person in the first place. Perhaps collaborating with your colleagues will reveal how it is possible to get it to work for you and not for others.

LegacyUser

Adrian Bruce said: This is quite weird - I looked at Jan's example myself and, as he says, there are no valid detachment reasons in the change log when I looked.

So I took my GG-GF's profile, a big gulp and tested something in production - which I would normally never do but with some people saying it works and others saying it doesn't, I justified it to myself. I attached, then detached the 1881 census, then looked at the Change Log:


His PID is KG21-L48 and the image shows the attachment with a reason for attachment, then the detachment with a different reason for detachment.

So I can't see the correct detachment reason on Signe Andersdatter LQ5N-WMV but I can see the correct detachment reason on Joseph Cadman KG21-L48.

I even tried detaching something from Joseph that had been added ages ago - it still works as it should and shows the correct detachment reason.

LegacyUser

Alan E. Brown said: Thanks, Adrian, and others who have given input. It appears that there are certain kinds of sources that act differently from others. That explains why some people definitively say that they see a bug, while others say that it works just fine.

This isn't my area of expertise as an engineer, although as a user I do a lot with sources. I believe Joe knows which engineering team to share this with.

And I'm impressed with your courage in testing in Production -- you cared enough about finding the truth that you took that big gulp and plowed forward anyway! I totally understand your wariness in touching live data for testing purposes -- that's why I do most of my testing in Beta.

LegacyUser

Jeff Wiseman said: Alan,

It's always really great when patrons out there explore those items themselves and contribute that information here. However, that experimenting nature of patrons would not be considered unusual in my own mind. Here's an interesting example of doing a search in the tree for "test person" which brings back over 2 million hits. In a database with a bit over 1 billion records, those test person records amount to roughly 0.2% of the entire database!



There's a LOT of folks out there experimenting in production trying to figure out how things work :-)

LegacyUser

Adrian Bruce said: Alan - I had 30y in IT, most of which included some element of software support so I got a feeling for what I could do where. In this instance, I was attaching and detaching and re-attaching the correct data, using the production software and the only issue that had previously been identified was with the Change Log. So logically the risk was minimal.

Even so, normally I'd do that sort of experiment in Beta - but in this instance, if there were something odd about the file setup causing this blip, then it might work in Beta but not in Production. (Yeah, I've had that - stuff working in Test, not in Production, because the Test files were too small and didn't have any records in Overflow....)

Still, for anyone without their years of fixing software at midnight, it's a case of "Don't try this at home..."