When building a custom filter, I can use existing filters that reference a specific person, the default person, bookmarked people, or people matching the results of a filter. But I don’t see a way to build a custom filter based on the currently selected person(s). Is there a technical reason why this cannot be done, or would it be possible to create a general filter “Currently selected person(s)” to use as a building block for custom filters?
1 Like
There can be an extended selection in the person view… necessary for merging, drag’n’drop & mass edits (like Tagging or deletions). But I don’t think this is what you meant.
Are you thinking of the Active Person selection? A filter for this has been a popular suggestion on the maillist & as a Feature Request.
A while back, I had searched for Active Person filtering rules and hoped the default person in the Person & Relationship General filter rules actually meant Active Person.
But default person turned out to but the “Home Person”. (Revised the manual in Jan 2020 to clarify that & requested that the filter rule be relabeled to say “Home Person” for consistency. Also that filtering on the Home Person be extended in other Category Views.) It appears default person is a legacy nomenclature that wasn’t harmonized when the new term was chosen.
After experimenting, I began to suspect that an Active Person filter could cause recursive refresh problems if it were a filter option for the People category view. (Applying the filter might force a Active Person value reset… which would force the filter to re-apply… which could force Active Person value reset… et cetera ad infinitum) But I’d still love to see it as a choice in the Filters rules for the other category views!
In the meantime, I use Home Person or a Tagged person filter rules as an unweildy workaround.
Note: I don’t know if the Active Person can be undefined. Surprisingly, the Home Person can be undefined. (Only happens on a new or imported Tree. You can’t make it undefined again after setting a Home Person.) And the active record in the other category views is frequently undefined.
It would be ugly if Gramps could choke creating a new Tree when left on a view using an unresolvable filter. So hopefully the filter rule handler processes any ‘undefined’ parameters gracefully.
Instead add current person and more to bookmarks, verify no desired person is bookmarked then use bookmarked people filter.
It should be possible to have a filter rule based upon the Active person. There is one for the Home person and Book marked people. I just don’t know enough programing to know how.
But I am sure someone can if you file a Feature Request.
While you wait for that to happen, your best bet is to temporarily make the person the Home person to run your filter.
Thanks all, I have used the bookmark approach before, and will continue to do so for now.
Before submitting a feature request, I’d like to think more about what exactly I’m requesting (as they say, be careful what you wish for!). I like the way that gramplets automatically refresh when the selection changes, but I think @emyoulation is right:
Even if it didn’t crash, I’m not sure what I would want to happen.
Maybe what I really want is a new gramplet that takes a custom filter as input (but still with some way of referencing the active record) and displays the resulting list of records (similar to the way the Children gramplet) without impacting the main view. Maybe this could be general enough to work in other views as well. Does that make sense?
2 Likes
Personally I cannot see this as a problem (famous last words).
Reports often use the active person as the focus of filtering options with no problems.
And if an Active person filter could cause problems then the same would be true for the Home person or Bookmarked people. At the time the filter is run, there can be only one Active person and that will probably be a different person the last time the filter was run. The same for Home person. That person can change outside of the filter settings. And there are no problems with that option. Quick Views are run off of the Active person. These involve filtering for the information.
Double check, do the other areas of Gramps; Places, Sources etc offer an Active record filter? Maybe what you are seeing as a need may also benefit the other filter areas too.
Instead if limiting the concept to Active Person, think Active record.
2 Likes
I found a way to create active/selected object filters. I’ll add them later today.
2 Likes
That’s great! Looking forward to looking at it.
Thank you!
I tried copying the _isdefaultperson to create a variant. But keep running into problems building a valid registration (.gpr.py) file. Mine cause Gramps to fail on boot due to an invalid type. More new things to learn!
I have created the ActivePerson filter rule https://github.com/gramps-project/addons-source/pull/306 if any of our more adventurous users wants to try it.
I will probably wait a few days to see if there are any comments before making it available for everyone via the usual addons update.
2 Likes
I just checked it out.
I created a Filter ActivePerson with the ActivePerson as its only rule.
Created a second filter using @Mattkmmr new male line by filter and setting the ActivePerson filter as its input.
Made a grandfather the active person, filter ran great. Made a second grandfather the active but when I ran the same filter again, the results were for the first grandfather.
And the same results happen if the Default person (Home person) filter rule is used. (First time I used it.)
Ran the filter with a home person set. Changed the home person to a new person, ran the same filter, the results were for the first home person.
And it is the home person at the time the filter is run for the first time. I had changed the home person before running the filter (so the filter made sense). The second time I ran the filter with another new home person, the filter returned the first run results.
How long has that been a bug?
After creating a custom filter in Person view with JUST Active person as the only rule, I’m getting a No active Person modal warning dialog.
However, the Active Person is the Home Person. And there is an Active Person showin in the Relationship and the same person Person is shwon in the Status Bar (Display Preferences tabhas Status bar: set to Relationship to home person)
@prculley I also created my version with user.uistate.get_active('Person') but it only works for flat list views. Do you know a way to make it also work for tree views?
1 Like
Interesting. A filter set to Default person (aka Home Person) is updating to the new person.
I DO have to re-run the filter manually as changing the Home Person does not ‘dirty’ the view and force a re-evaluation automatically. But I assumed that would be the behavior. (A dirty detection that that refreshes is too aggressive tends to do too many recursions.)
An example of overly aggressive refresh is when you’ve filtered your data in a view to do harmonizations and every time you commit an update to a record, the list re-sorts or, worse, re-filters.
Coool! You’re right. It works in Flat mode but not Grouped.
I did a similiar test and had the same result. I was using a flat view, not grouped. I also tried this: after changing the active person, I used “Reset” and “Find” to clear the effect of the filter. Then I reapplied the filter, and it gave me the original results, even though the newer active person was still highlighted. A nearby gramplet always showed the results for the correct active person.
2 Likes
Unfortunately the tree view is currently a problem. In gui/views/treebasemodel.py at about 590 the filter is initialized with a dummy ‘User’ class, instead of the current GUI user. So we will have to put a fix into the Gramps main code to deal with this.
The new lines should like:
for handle in dfilter.apply(cdb, tree=True,
user=User(parent=self.uistate.window,
uistate=self.uistate)):
You can tell I did not test in Person Treeview…
Patch merged for Gramps 5.1 release. Add uistate to tree views filter initialization PR#1039
2 Likes
My filepath had an extra treemodels directory level after views…
C:\Program Files\GrampsAIO64-5.1.2\gramps\gui\views\treemodels\treebasemodel.py
but the patch works for me. Thanks!
I just posted this bug.
https://gramps-project.org/bugs/view.php?id=11689
Apparently GrampsAIO-5.1.2-new_libs_win64 was causing errors when running filters based upon the new Active Person filter rules and why not everyone was seeing the same results.
1 Like
@prculley
I just used the Home Person (built-in) and Active Person (add-on) rules for an illustration of the FilterParams add-on tool by @kku
It stood out that these rules do not have an “Invert” option. Could you add that to both?
Also, the Home Person rule presents in the FilterParams list as “IsDefaultPerson”. Is this another remnant of the deprecated “Default” term instead of the new “Home” term.
