Jump to content


Photo

Bug with Ancestry Fact New Upload vs Update


  • Please log in to reply
6 replies to this topic

#1 bwr63

bwr63

    Member

  • Members
  • PipPip
  • 13 posts

Posted 21 November 2018 - 10:00 AM

I created a custom fact type in RM with the definition:-

Name: Birth Alternative

Abbreviation: Alt. Birth

 

RECREATE BUG:

If you upload a new fact to Ancestry. It appears on the website as "Alt. Birth"

 

Now edit he text of the fact either Place, Place Details or Description then resysnc with Ancestry. It changes on the website to "Birth Alternative"

 

Now make a dummy edit and save so you can compare a 3rd time and the facts don't line up.

 

VERIFY BUG:

I have seen this before also with the fact "Census (family)" that has abbreviation "Census (fam)".

 

 

WORKAROUND:

i can work around for custom facts by keeping the name the same but not for the built in facts as these are greyed out.

 

 

It seems the update routine and new fact upload use different fields for the work when sending to Ancestry.

Please change to a common field for the work.........

 



#2 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8180 posts

Posted 21 November 2018 - 05:37 PM

If Ancestry is changing the fact name after the upload then I'm not sure there is anything we can do.  Is there a reason why you don't want to add a second birth fact in RM to send to Ancestry, instead of a custom alternate birth fact. That should work fine without anything being edited?

 

Ancestry doesn't have family facts. They add two separate individual facts to the couple. Just keep that in mind when using it. If you go to Lists>Fact Type List you will see the Census (family) abbreviation is Census (fam) so it appears that is what Ancestry is changing the fact name to. 


Renee
RootsMagic

#3 bwr63

bwr63

    Member

  • Members
  • PipPip
  • 13 posts

Posted 22 November 2018 - 04:48 AM

Thanks Renee,

I think this is a bug in the way the information is sent to ancestry either at RM end or at Ancestry. It is present in both individual facts and family facts even though they are split.

 

The update procedure uses the full NAME while the adding new fact procedure uses the ABBREVIATION. For simple facts Birth, Death etc. etc. these have the abbreviation the same as the name so no issues.

 

If I change the custom fact to have the same NAME and ABBREVIATION then I have no problems with the update.

 

The main issue I have is that the CENSUS (FAMILY) fact has an abbreviation CENSUS (fam) so is triggering the bug and it is greyed out so I cannot change it.

 

 

The workaround is NOT to do an UPDATE but instead to upload a new fact and delete the old fact.

 

 

Its a bug but you can work around it.



#4 Jerry Bryan

Jerry Bryan

    Advanced Member

  • Members
  • PipPipPip
  • 3262 posts

Posted 22 November 2018 - 07:23 AM

I suspect that this REALLY is a bug in RM and is not something funny in the ancestry API or on the ancestry side of the house. And it surely has nothing to do with individual fact types vs. family fact types.

 

The simple fact is that RM's fact types each have two names - a Name and an Abbreviation. It's never clear to me when RM is going to use the Name for a fact type and when it's going to use the Abbreviation for a fact type. I can't remember the details (it was long before TreeShare), but I remember this dichotomy causing me problems many years ago. My solution was simply to be sure for all my user defined facts types to make the Name of the fact type and the Abbreviation of the fact type to be exactly the same. That negates whatever value there is in having both a Name and an Abbreviation for each fact type (I'm not sure what that value is), but it makes sure that problems like this one don't happen. Of course, this solution is not available for built-in fact types where the Name and Abbreviation are different, only for user defined fact types.

 

In truth, RM's fact types kind of have three names. The third name is the name of the GEDCOM tag which will be used when RM exports the fact type to a GEDCOM file. The GEDCOM tag name is not exposed to the RM user interface. You can't see the GEDCOM tag name, let alone change it, without using SQLite. I think there could be considerable value for some situations in exposing the GEDCOM tag name for each fact type to the RM user interface.

 

Jerry



#5 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8180 posts

Posted 23 November 2018 - 11:43 AM

Checking now and I see this was already noted on the development list. 


Renee
RootsMagic

#6 bwr63

bwr63

    Member

  • Members
  • PipPip
  • 13 posts

Posted 24 November 2018 - 10:15 AM

Hi Again,

Would it be possible to pull some of these development lists into a pinned topic in the forum so they are not repeated.

 

I only posted as I thought I had a workaround. It would be great to see bug lists with workaround's and expected fix dates/releases?



#7 Renee Zamora

Renee Zamora

    Advanced Member

  • Support
  • PipPipPip
  • 8180 posts

Posted 24 November 2018 - 04:06 PM

The development list is for internal use only. 


Renee
RootsMagic