Search Forums
Kiwitrees on Twitter

    dead, dropbox. token, defacto, My Page, 3.2.1, spouse, order, googlemaps, custom, places, help, administration pages, message contactform, backup, new feature, 3.0.0. setup, menus, release, add_asso_facts, reports, family facts, Themes change, feedback, button, login failure, time, calendar, upgrade, translation, click, 2.0, future, kiwitrees 2.0.2, re-order, family, survey, sidebar, NCHI, 3.1.1, album, colors theme, logs, GEDCOM errors, ID facts, 3.0.0, individual resource, fact, error, wish, transifex, users, css, session, access roles, 3.3.3, language, burial, REFN, news module, support


    1610 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.

    My personal kiwitrees site is