Added option to display birth and death info in descendant report

[uwagura]

Made to address Bug #12758. This is a relatively small change, but I made a pull request so that the change and the initial feature request are visible to more experienced developers.

[emyoulation]

This Pull Request now address 2 very different bug reports.

@Nick-Hall - How can they be separated?

12758 : [Descendant Report] birth date display needs to be select optional
12759 : All Family Events [Quickreport] generates 2 error for drag'n'drop of Family level events, and a non-functional "See details"

[uwagura]

This was my mistake, I pushed my quickreport change to my master branch without realizing it would effect this pull request. Perhaps if I reset my master branch to it's previous commit and then pushed that change, this pull request will go back to addressing bug 12758 alone, and PR #1613 will address 12759 alone? I've made a new branch to address 12759 and used that branch to make PR #1613, so it shouldn't be effected if I do this.

[uwagura]

Perhaps if I reset my master branch to it's previous commit and then pushed that change, this pull request will go back to addressing bug 12758 alone, and PR #1613 will address 12759 alone?

I went ahead and made this change without effecting #1613, so this PR only addresses bug 12758.

[hgohel]

Was removal of this line intentional? If not, it should be reintroduced.

[uwagura]

It was not intentional, I've gone ahead and reintroduced the line. Thanks for pointing this out!

[hgohel]

@uwagura Change looks good!

@Nick-Hall This PR is targeted to gramps master, is it too late to target 5.2 release?

[Nick-Hall]

is it too late to target 5.2 release?

As this change is small and confined to a single plugin, I think we can accept it for the gramps52 branch.

[hgohel]

@uwagura Could you target the maintenance/gramps52 branch for your change? See Changing the base branch of a pull request if needed. Your change will be included in the upcoming release :)

[uwagura]

@hgohel , I've gone ahead and changed the target to maintenance/gramps52, let me know if everything looks good!

[hgohel]

@uwagura Thanks. I thought the rebase to maintenance/gramps52 via GitHub would be smarter, but it brought along commits that are not part of your original change. I don't know if there's a way to resolve this using just GitHub (@Nick-Hall ideas?), so it might be better to revert this PR back to the master branch, and create a new PR for the maintenance/gramps52 so that only your changes are brought in.

[uwagura]

@hgohel yeah, I wasn't sure why it did that. It looks like if I create a new PR, it still brings along the extra commits. Do you think I could fix the issue if I

1.) make a local branch named "lifespan" containing only the relevant commits
2.) git pull --rebase my local branch to the upstream maintenance/gramps52 branch,
3.) force push my local branch to the lifespan branch tied to this PR on github?

let me know what you think

[QuLogic]

Changing the base branch on GitHub does only that. It doesn't do a rebase of the commits for you. You would also need to do the rebase locally and force push in the manner you are suggesting.

[uwagura]

I was having trouble with the rebase, so I just pulled the gramps52 branch, manually remade my changes, committed them to a new lifespan branch based off of the gramps52 branch, and then force pushed these changes. It was a bit messier, but I think this pull request should be good now @hgohel . Thank you for your help @QuLogic !

[hgohel]

Nice! @uwagura thanks for your contribution, and thanks @QuLogic for jumping to advise.