New filter rules for genetic genealogy

Development
#21

I’ll change the filter rules to following names and descriptions to avoid confusion:

  1. Patrilineal progenitor of <person>
    Matches the earliest recorded patrilineal ancestor father.
  2. Matrilineal progenitorix of <person>
    Matches the earliest recorded matrilineal ancestor mother.
  3. Y-chromsomal inheritance of <person>
    Matches recorded descendants of person following Y-chromsomal inheritance patterns.
  4. Mitochondrial inheritance of <person>
    Matches recorded descendants of person following mitochondrial inheritance patterns.
  5. Y-chromsomal inheritance of <filter>
    Matches recorded descendants of a filter result following Y-chromsomal inheritance patterns.
  6. Mitochondrial inheritance of <filter>
    Matches recorded descendants of a filter result following mitochondrial inheritance patterns.

I won’t add the checkboxes to this set of filter rules, because I want them to follow stricktly the genetic inheritance patterns, but I can create new filter rules following the male or female lines or other inheritance patterns with an option for including non-biological descendants.

2 Likes
#22

Why not

  • Patrilineal progenitor by ‘Birth’ relationships
  • Matrilineal progenitor by ‘Birth’ relationships
  • Patrilineal descendants by ‘Birth’ relationships
  • Matrilineal descendants by ‘Birth’ relationships

It makes clear that it is not making actual DNA searches and that the relationships are by Birth. Maybe expand the Description to include something like: "… the search results are the presumed Y-DNA results passed on by fathers to biological sons.

#23

@Mattkmmr
Need to reiterate in this thread how much I appreciate these additions that you’re coding.

Filters seem to be a great place to get my feet wet with customizing Gramps. I’m learning a lot from your postings.

Thank YOU!!!

1 Like
#24

AddRule-selector-dialog-PersonFilters-example-50

In choosing a Rule name, we need to keep the character limits of the interface in mind. We could get VERY explicit but the names need to be as terse as possible with the most critical criteria early.

Also, the convention seems to also require indicating the parameter. So the ‘of <person>’ portion wouldn’t be optional for the name

1 Like
#25

I experimented with adding the ‘Adopted’ sons to the SharedYDNA file. I named it ‘Male Line Descendants’. Besides changing the description verbiage, etc I added three lines of code.

for family_handle in family_list:
    family = self.db.get_family_from_handle(family_handle)
    for child_ref in family.get_child_ref_list():
        child = self.db.get_person_from_handle(child_ref.ref)
        if (child_ref.get_father_relation() == _("Birth") and
                child.get_gender() == 1):
            male_children.add(child_ref.ref)
        if (child_ref.get_father_relation() == _("Adopted") and
                child.get_gender() == 1):
            male_children.add(child_ref.ref)
return male_children

Not sure of the best way to share this.

#26

True and should be remembered but now moot as @Mattkmmr has come up with a solution. My suggestion was half a minute too slow.

And that window has vexed me because I have not yet figured out how to permanently expand that selection window.

1 Like
#27

Was hoping we could minimizing addition of rare use add-on rules that are a simple exception. The rules lists could become overwhelming very quickly. (And my selfish reason… And the documentation burden would be lighter too! Only 1 entry in the Add-on list page, 1 section in the Rule Expansions page, & 1 screen capture. Note that Rules haven’t yet been inserted in the Add-on List because we haven’t sussed out some oddities in the management of Rules.)

The primary use would be for biological relationships with the rare case including the adopted & hired womb babies.

So how about making the checkbox for the rare-case with the defaults being for the general case? The deselected by default checkbox might be ❏include all dependant relationships. (Although that still feels like awkward wording)

#28

This is rule by committee, Everybody has an opinion, but at the end of the day someone has to decide.

Are these filters Issued yet or are they in Beta ?

#29

Yup, “by Committee” is pretty much the entire concept of Open Source!

That said, Matt is creating them and has final say on his contributions. But he’s welcome to choose when to tell us to shut up. I try to show my appreciation by adding them to the wiki so he doesn’t have to.

He has been graciously posting to the GitHub repository for others to try out. They haven’t gone through code review yet and are still at the ‘Potentially hazardous. Use at your own risk’ stage!

You have to know enough (be enough of a daredevil) to be able to install manually. Once they pass through peer/code review, then an admin will add them to the Update manager and installation becomes easy enough for everyone,

#30

Found It!! :boom:

Time well spent while social distancing!!

2 Likes
#31

@Mattkmmr posted links to the files (or to the code) in the first post to this thread.

#32

Hey @Mattkmmr
I just re-read the add-on Rules docs and noticed that we can’t credit your work properly yet. Add-ons are normally credited in the Add-On list. But add-on Rules are doing funky things with the Plug-in Manager. So Rules haven’t been added there yet.

It is currently an All-or-nothing proposition. You can’t install & de-install one. Gramps applies the changes to all downloaded Rules at the same time. I suppose you have a measure of control because you can choose not to download. But Rule downloads tend to be bundled in sets rather than individual rules. And groups of distinctly different rules don’t slot into the compact Add-on List Table cleanly.

So far, only you and Paul have posted Rule contributions. Paul’s got his fingerprints all over Gramps. (In a GOOD way, @prculley !) So what would you like us to do for your credit until there’s some solution for the Rules in the Addon/Plugin Manager section?

#33

You need to look more closely. There is a source filter rule that I had a part in. In fact it was the first addon rule. Although I was shocked when Paul got it into a working form that he included me in the credits. My contribution was to copy existing code and get it configured to be used as a new builtin standard rule. He did all the work to make it an addon so it could be pushed out to the user needing it.

@prculley rocks!! Or should I say rules!!

#34

He certainly does!

Sorry for missing your Contribution. That’s another reason Sam’s been trying to find a way to drive some sort of synchronization between that wiki table wiki & download manager. Its too easy to overlook someone’s significant efforts.

#35

Do not overplay my “significant efforts”. :wink:

#36

@DaveSch Wouldn’t it be a bit confusing to call this filter “Male Line Descendants” if it only includes male male-line descendants? From the name only I would have assumed it includes female male-line descendants too (vide Filter for male-line descendants) Is there a reason why someone might want all patrilineal descendants (including adopted sons) but not daughters? Perhaps it would be more intuitive to have a filter that is called “Patrilineal descendants” that would include all male-line descendants (male or female) - and then the user could easily add the gender filter on top of it?

#37

I think the correct Latin term would be progenitrix.

#38

That’s probably because all addon filter rules are placed in one folder. We might split them up if the grow a lot, so they can be installed seperatly.

Ah right, I’ll rename it. :sweat_smile:

2 Likes
#39

Did you not want this ability?

Filter for male-line descendants

The filter that was cobbled together included @Mattkmmr male line Y-DNA filter combined with their children.

As I pointed out, this excluded adopted sons.

My “Male Line Descendants” solved this by making the selecting of the males from a Biological to a Family filter rule.

#40

You gonna make us beg? :woozy_face:

Where?