Search
Forums
Kiwitrees on Twitter
    Tags

    ID notes, pages, flags, survey, timeout, set link, access level, clippings cart, tools, ID facts, FAQ, Default record, Php 7.1, stories, admin, configure, php 7, 2.0.2, administration pages, events of close relatives, DIV, Export/Import, image, ckeditor, blank, media_links, version, colors, errors, HTML block, family facts, emigration, place, title, html, dead, transifex, road map, lists, support, beta, performance, nickname, GEDCOM, login upgrade, xenea, dropbox. token, translation, watermark, widget, theme, contact links, places, footer, add_asso_facts, 3.3.3, news module, GEDCOM errors, follow, prefix

    #9719
    kiwi
    kiwi
    Keymaster

    1643 posts

    An interesting suggestion, and not a new one. The thought has occurred to me even back in PGV days. Then (and now) it was in relation to Batch update > Add missing married names. I run it regularly because I often forget to add them when I find marriage details. But I have about 10 or more examples (mainly name changes, adoptions etc) where I do not want a particular “suggested” married name to be added. So I must remember to skip each of those and always run the update one record at a time.

    There are now a lot more examples in the “Sanity check” tool that could use a similar “ignore this one next time” feature.
    But that is where the problem becomes unmanageable, and why I don’t think I will ever do it.

    For such a setting to work, it must be possible to record a “don’t update” flag against the relevant record. By “record”, I mean it could possibly be any of INDI, FAM, OBJE, SOUR, or NOTE, although INDI and FAM are the most obvious uses. In addition, there would need to be a different flag for each check. One for duplicate names, one for married young, one for children at an older age, and so on. Potentially there could be as many as 25 different flags set for any single individual or family.

    That raises the issue of processing efficiency and speed. I don’t think this could easily be done as a database stored item, because currently when anyone re-imports a GEDCOM file it deletes all existing data (for that tree). So all those flags would be removed! So it would need to be something like a series of “unofficial GEDCOM tags”, like _DUPE_NAME, _MARR_YNG, etc.. Perhaps 25+ of them.

    Ultimately, that just gets too messy, I’m afraid. So I am going to, reluctantly, say no to this idea, at least until a better / more practical solution comes to either my mind or anyone else who has a suggestion.

    Nigel
    My personal kiwitrees site is www.our-families.info