From: Benny M. <ben...@gm...> - 2010-05-11 10:03:44
|
2010/5/11 Gerald Britton <ger...@gm...> > I actually think that things are working correctly. If there is a > problem it is that the complex interactions possible with proxies and > filters using nested combinations of "match" and "do not match" can > produce results that are perfectly logical but not always easy to > explain. > > Yes, the new logic might lead to other unwanted behavior that is perhaps worse than the original behavior. That is, perhaps it is better not to do this thing. Consider: A person is a private descendant of a family. But it is not private who his children are. When you do a descendant report, you obtain all children, then remove private. In the new setup, you still end up with the children of the private child, which you would want to remain hidden. Same with the original ancestor question: from a report you can deduce somebody is a private ancestor of somebody else, which you might not want to share with other people. So, for now, it might be best _not_ to change the way the proxy works, and do as Gerald says: offer a checkbox: apply private on final result, as opposed to, apply private at the beginning. One gives results you as a researcher want to see, the other gives results you allow to share with people. Benny > > On Tue, May 11, 2010 at 10:03 AM, jerome <rom...@ya...> wrote: > > As "standalone" everything works fine (filter or private proxy results). > I did not look at reports or tools, but I only get problem on Exporter (XML > or gedcom formats). > > > > Otherwise, I did not test a filter on notes and private notes or persons. > > > > By changing the central/root person on testing gramplet (added on bug > report) from I0001 to I37, I learned that adding sort() function on a > filtered list returns ordered objects (sorted by the filter rule) or by > entry/key (surname for person). Unfortunately, I was not able to understand > if to use proxy.filter and proxy.private together will try to match common > entries on lists or always to pass one into the second one. > > > > Maybe only a coding issue on Exporter. But why no more invert mark on > filter after matching a private record ? So, there is a temp list somewhere > (invert of inverted filter result !) added on output :( > > > > There is multiple variables on this issue : > > * invert mark on filter > > * proxy.private > > * proxy.filter > > > > Patching export formats (XML, gedcom) will generate the same number of > people as GeneWeb, csv, etc ... formats > > But (in my case) why need to also patch proxy (sourcebase, notebase) ? > And why proxy stop iteration on filtered list if someone is private ? This > one sounds like a related issue ! > > > > > > > > Regards, > > Jérôme > > > > > > --- En date de : Mar 11.5.10, Gerald Britton <ger...@gm...> > a écrit : > > > >> De: Gerald Britton <ger...@gm...> > >> Objet: Re: [Gramps-devel] Bug in Filters/Proxies? > >> À: "Doug Blank" <dou...@gm...> > >> Cc: "Gramps Development List" <gra...@li...> > >> Date: Mardi 11 mai 2010, 8h59 > >> this is a unique use case. i > >> cannot see that there is one correct way > >> to do it. probably some would ask for a way to > >> specify the order in > >> which the proxies are evaluated. however that would > >> mean changes to a > >> few dialogues I think > >> > >> On Tue, May 11, 2010 at 2:00 AM, Doug Blank <dou...@gm...> > >> wrote: > >> > Devs, > >> > > >> > In working with Jérôme on this bug: > >> > > >> > http://www.gramps-project.org/bugs/view.php?id=3878 > >> > > >> > We've encountered a filter interaction that doesn't > >> seem right, and we > >> > have a proposed solution, but we want to bounce it off > >> you. Here is > >> > the situation: > >> > > >> > 1) You have a filter that is: everyone that is *not* > >> an ancestor of a > >> > specific person. In the chain of ancestors are a > >> couple of people that > >> > are private. There are 29 people that match when > >> exported (eg, they > >> > are not ancestors of the person). > >> > > >> > 2) If you add the additional constraint of "Do not > >> include records > >> > marked private" with this filter, then the number of > >> people exported > >> > increases to 35, which includes some ancestors. > >> > > >> > The reason is that the Private filter is applied > >> first, so that the > >> > chain of ancestors no longer contains everyone that it > >> did before, and > >> > so less people are found to be ancestors, and thus > >> more people are not > >> > ancestors. The exported people includes some > >> ancestors, but not the > >> > private ones. > >> > > >> > It seems that the right thing to do is to apply the > >> Private (and > >> > Living) filters last, so that the constructed filter > >> behaves as it > >> > does interactively in Gramps. We have swapped the > >> order of the filter > >> > applications having Private go after Filter, and it > >> then does the > >> > correct thing. It seems from SVN that it has always > >> been in the wrong > >> > application order since it was introduced in Gramps > >> since before > >> > September 2007. > >> > > >> > Does anyone see an error in our logic, or see that in > >> some use cases > >> > it wouldn't do the right thing? Otherwise, we think > >> the order needs to > >> > be swapped. > >> > > >> > -Doug > >> > > >> > [1] > http://gramps.svn.sourceforge.net/viewvc/gramps/trunk/src/plugins/export/ExportGedcom.py?view=diff&r1=8930&r2=8931 > >> > > >> > > >> > ------------------------------------------------------------------------------ > >> > > >> > _______________________________________________ > >> > Gramps-devel mailing list > >> > Gra...@li... > >> > https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > >> > >> > >> > >> -- > >> Gerald Britton > >> > >> > ------------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> Gramps-devel mailing list > >> Gra...@li... > >> https://lists.sourceforge.net/lists/listinfo/gramps-devel > >> > > > > > > > > > > > > -- > Gerald Britton > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Gramps-devel mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-devel > |