#2819 Edit Family deletes Family

v4.2.3
closed-fixed
nobody
None
9
2010-08-23
2010-07-27
Pilgrims
No

Tried this twice today.

Viewed family.

Chose 'Edit Family' from the 'Edit Family' drop-down options. First time I simply closed the pop-up without saving and the second time I saved without changing anything just to try something different.

Both times, the father, mother and child(ren) totally disappeared. The family had to be rebuilt using the 'Change Family Members' option.

Discussion

  • Stephen Arnold

    Stephen Arnold - 2010-07-29

    Confirmed. Edit Family removes all the 1 CHIL tags from the GEDCOM FAM record if the record is saved with or without making changes. It does not remove the corresponding (reverse) 1 FAMC tags from the INDI records.

    Additionally, the EDIT FAMILY interface does not contain an ADD SOURCE to the record.
    -Stephen

     
  • Pilgrims

    Pilgrims - 2010-08-16
    • priority: 5 --> 9
     
  • Pilgrims

    Pilgrims - 2010-08-16

    Temporarily resolved the immediate crisis of missing families by diff'ing the GEDCOM with a backup, paired with seeing which FAMs had vanished via the logs. Then it was a case of cutting and pasting the missing data across, and re-uploading the file. (Sloooooooow!)

    Looking at the GEDCOM I saw that ALL the members of the family disappear from the FAM record - no HUSB, no WIFE and no CHIL. The place, date, and other notes remain intact. The INDI records are untouched - ie no missing FAMS or FAMC tags.

    Hope that helps track it down.

     
  • Stephen Arnold

    Stephen Arnold - 2010-08-19

    We will work on removing this function as it is actually bad genealogical practices (inadequate SOUR) and is not needed. Resembles Quick Update in some fashion.
    -Stephen

     
  • Pilgrims

    Pilgrims - 2010-08-19

    That would be a shame. 'Edit family' seems to have the appropriate level of sourcing in it.

    As an admin I use both 'quick edit' options extensively.

    As an example, we have just completed a first level hierarchy overhaul of place names in our entire database - names that were entered incorrectly, or even without the most basic country first level.

    By using, in particular, the indi Quick Update and customising it, we were able to save heaps of time by having access to several event places at once.

    Otherwise this is a very long and off-putting process as sometimes you would need to go into half a dozen separate events for each indi and correct. [We have just changed over to the Chromium browser which is making using PGV faster as it processes the js better than Firefox]

    I don't believe that taking away a feature like this is really going to eliminate bad genealogical practises of not sourcing.

    For me its removal would make my job, to ensure the quality and accuracy of data, harder.

    [By the look of it the 'Edit Family'option could be hidden with CSS, until it is fixed,]

    FWIW I have just tried using the 'Edit Family' feature on a local install and it did not delete my family at all. The only difference that I can see is that locally I am running PGV on PHP 5.3.1 and upstream it is 5.2.13.

    This feature was working prior to upgrade to PGV 4.2.3 on both platforms to the best of my memory.

     
  • Pilgrims

    Pilgrims - 2010-08-19
    • milestone: 1021366 --> v4.2.3
     
  • Pilgrims

    Pilgrims - 2010-08-19

    Quote "[By the look of it the 'Edit Family'option could be hidden with CSS, until
    it is fixed,]"

    Scrap that thought as it looks like menu items are randomly generated on the fly.

     
  • Stephen Arnold

    Stephen Arnold - 2010-08-19

    If you are an admin, why not simply edit the RAW gedcom. It is SOOOO much faster than any GUI.
    The Quick Update is an abomination that never should never have been propagated to a final release. John designed it for one client, early in the history of the project, to serve a specific need, but it furthers terrible habits (can not SOUR entries) and a tool too often misused, abused and mistakenly used by users ill prepared to enter data.

    The EDIT FAMILY is really a subset of that function. While there is one SOUR feature, I dare say it is rare that the same source applies to all of the tags within the interface, and it does not allow multiple SOURcing for a particular event, nor allow you to specify which tag should or should not be SOURced by your entry. Simply BAD genealogy programming.

    I think it highly unlikely that it will remain, primarily due to the problems noted above, whether the functionality could be repaired or not. If I get around to 'fixing it', my 'fix' will be to remove it. Discussions elsewhere have shown that few long-term uber-admins have used this 'feature', hence why this bug has never been noticed. It is not new.
    -Stephen

     
  • Stephen Arnold

    Stephen Arnold - 2010-08-19

    Pilgrim
    BTW, the better way to do the changes you discuss, is to do either BATCH changes via the ADMIN function (search and replace - very flexible and powerful), or for really complicaed replacements, use a good text editor and GREP the changes needed, then simply re-import. Changing a large batch of misspelled or CAPPED names is a breeze with the batch function, as is changing place names and even long strings, SOUR references and more. S/R batch function lets you identify and approve each change, in order or do ALL, within a few minutes - much quicker than using a faulty interface.
    -Stephen

     
  • Pilgrims

    Pilgrims - 2010-08-19

    Thanks for the heads up on the batch feature - will explore.

    As for editing the GEDCOM: I used this method to fix the lost families BUT it does not easily give you the context sometimes needed to correctly identify places especially for a transitory generation ie one who comes from a country with a town the same name as the give another in their new land.

    I am going to look into working with the raw GEDCOM file more anyway as I want to merge GEDCOMS.

    While we are on the topic of sourcing though:- even adding an indi doesn't allow you multiple sources for the various elements in one 'save'. I have to enter the most pertinent source, selecting the appropriate B,M,D,I, checkbox, save and then go into each of the previously non selected events and add subsequent citations to those individually. Is this the way it is supposed to be?

     
  • Stephen Arnold

    Stephen Arnold - 2010-08-19

    Pilgrim
    Yes, this is how the INDI edit interface is currently designed. There has been much discussion amongst the developers as to whether it was prudent to add multiple SOUR and it is believed that it would be far to cumbersome and quite confusing to the average user - difficult enough for some as it is. I usually add an INDI, then click SAVE & VIEW NEW RECORD (or whatever the words are) and immediately enter into RAW, adding the SOUR notations to each tag. It is pretty fast, and certainly better than multiple TAG clicking. Of my 85,000+ indi's, I've entered about 80,000 of those myself. When another user adds or changes data, I use the REVIEW changes feature, click view record to see the changed data highlighted and then use RAW to make any corrections (usually PLAC, sometimes DATE, and often correct SOUR) in one fell swoop.

    Play with the batch function, especially S&R, and you'll find it quite useful. If, while viewing the record identified for correction, I spot other data or SOUR errors, its easy to click the RAW on that FAM or INDI record and fix them all at once, save and skip over approving a change for that record, returning to find the next needing adjustment. We've discovered many old errors in this fashion and the ability to approve each record's change, one-by-one, is very useful.

    My point on the EDIT FAMILY dialog is that it doesn't have the BMDI checkbox flexibility that the INDI entry has, so any SOUR notation is added to every event listed, which is, IMHO, worse than leaving off all SOUR, as it only confuses matters latter.
    -Stephen

     
  • Stephen Arnold

    Stephen Arnold - 2010-08-23

    Pilgrims - SVN fix released. With this addition and George's patches posted, can you please close this bug as FIXED.
    Thanks, Stephen

     
  • Pilgrims

    Pilgrims - 2010-08-23

    Applied 4.2.3 patch to 4.2.3 version - all good. Thanks ggpauly.

    okbigkid - thanks for heads up on S&R. Unfortunately can't use it consistently as it exceeds the 96M memory limit, thereby timing out, which can't be raised on a shared host.

     
  • Pilgrims

    Pilgrims - 2010-08-23
    • status: open --> closed-fixed
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks