My repositories do not have much data in the Internet tab. And it looks like a lot of experiments will be necessary to really understand this rule.
That is important before it is adapted to the 2 other Categories have Internet tabs. And before more Categories are expanded with Internet tabs.
Nick explained that the “URL” field searches all text fields in all URLs. And the “Address” field searches all text fields in all mailing addresses.
But this doesn’t really clarify the behavior enough to expand the wiki.
‘Url’ is diagrammed fully in the Person section:
Has a look at the source code for the HasRepo rule for details.
- Field 1 (Name) matches on the repository name.
- Field 2 (Type) matches on the string representation of the repository type.
- Field 3 (Address) matches on any of the text fields within each mailing address of the repository.
- Field 4 (URL) matches either the path (Web Address) or description for each URL (Internet Address) listed in the repository.
If you have a look at the get_text_data_list methods in the LocationBase and URL objects, you can see which fields are regarded as text data.
I am to a point where I read code for syntax but not logic in Python. While making progress with SuperTool and tweaking some Gramplets, not having much luck with workflows through the Python Shell add-on gramplet nor the Python Eval debug tool.
So for me, the _HasRepo.py isn’t readable beyond … “OK. That syntax, looping construct, and parameter passing looks recognizable”.
For every field that you enter a value, it will try to match on a substring of some text data.
So for the “Name” it will match on a substring of a repository name. e.g. “Archive” will match “The National Archives”.
For “Type” it will match against the string representation of the repository type.
For “Address” it will loop through each repository address and match against a string constructed as “street, locality, city, county, state, country, postal code, phone number”. A match is only required against one address in the list.
For “URL” it works in the same way as “Address” except that it matches again “path, description”.
In the tests I did, it seems to be doing MORE. So that’s why I think it needs exhaustive experiments.
The “Address” searching was also returning Web Address (aka ‘path’.) I hadn’t tried physical delivery addresses.
Using the example database, if I enter “http” in the “Url” field I get two results as expected. If I put “http” in the “Address” field I get nothing - also as expected.
Entering “great” into both the “Address” and “URL” fields give me a single result. The repository has “great” in an URL path and in the city field of an address.
Can you reproduce the problem using the example database?
I had to put Unique words in each field to verify which was hitting. The Example.gramps lacks that distinctiveness in the sample data. There simply isn’t enough variation between field values.
It is a bit more confused with the Web Address. Because I’m not certain if E-mail type Web Addresses searched differently than other types. (no ‘http’ … so maybe there’s no validation?)
Another oddity was a LOT of the following error in the Console:
(gramps.exe:2496): Gtk-CRITICAL **: 14:59:42.477: gtk_tree_model_filter_get_path: assertion 'GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed
It’s just a text search. So in your screenshot example, putting “marc” or “gmail” or “gazetteer” in the “URL” field will match.
They probably won’t match in the “Address” field, unless you have an address containing something like “March street”.
I need to set up a structured checklist to test all the variations. After a restart and re-create of the Custom Filter, I don’t get the same result using similar values.
This sample is too contaminated by the same data be propagated in too many fields. The GeoNames eMail and domain is scattered across Notes, source names, author, Internet tab, descriptions, and probably more fields by the Place Cleanup addon.
Thanks @Nick-Hall
Think I’ll put this on the “back burner” bookmark for a month.
While trying to answer a question, discovered that the “selector combo box” (horrible name from an “Aunt Martha” perspective) had been omitted from the making Custom Types docs. While cross-referencing that to the custom types in Internet tab, discovered those were lacking too. Since there were only 3 of those, this came up while filling in those wiki sections.
Going to go back to cross-referencing the Selector Combo Box custom types ( Event Attributes, Family Attributes, media Attributes, Person Attributes, Event Roles, Event types, Family Relation types, Child Reference Types, Name Origin Types, Names Types, Note Types, Place Types, Repository Types, Source Attributes, source Media Types, Internet Address (URL) Types.) and then finally get back to the “— 
new for version 5.2.0” change log x-ref.
