Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1158 Date sorting requests

open-fixed
Greg Roach
None
5
2009-11-01
2009-10-20
Wes Groleau
No

1. If GUID is displayed, put it last. (In fact, it would be nice to keep it last in exported GEDCOM also) I have seen it appearing in the middle of an INDI's life events.

2. If OCCU has no date, sort it as if its date is close to the date of first marriage (if known) or after GRAD or MILI (if present) or 18 years after known or estimated BIRT. I have seen it appearing between BIRT and infant BAPM

Discussion

1 2 > >> (Page 1 of 2)
  • kiwi_pgv
    kiwi_pgv
    2009-10-20

    Wes, two good suggestions.

    The second sounds complex, but I see the point. Similar computations are done for other items, so it should be possible.

    I had another thought about the GUID (even though I don't use it). Its not really an event at all, so wouldn't it be better placed in the INDI header area?

     
  • Wes Groleau
    Wes Groleau
    2009-10-20

    Does anyone use it?
    Putting it outside of the fact list seems trickier to me than sorting it last.
    I'd say it should be with the change info, and if outside of the fact list, lower on the page.

     
  • kiwi_pgv
    kiwi_pgv
    2009-10-21

    GUID - "Does anyone use it"

    Well, I guess "use" is the keyword there. I see loads of sites that "display" it, but I would suspect 99% of them don't even know what it is.

    Greg's merge code/patch did use it as a unique identifier, but no, apart from that I know of no real "use".

    I try to remove it from any data I receive, but just in case, I also suppress its display from all types of users (even Admin) in privacy settings, so I don't really care where it gets put :-).

     
  • Greg Roach
    Greg Roach
    2009-10-21

    From a developers point of view, these GUIDs are extremely useful.

    I would like to have the "add UIDS on import" option made mandatory ;-)

    If you don't want to see them, simply set the fact privacy to "hide, even from admins".

    Sorting is easy to fix. Just decide what order you want. Should _UID be last, or should CHAN be last or should _TODO be last or should AFN be last, etc.

     
  • Wes Groleau
    Wes Groleau
    2009-10-21

    Greg, do you mean we have to decide for coding changes, or we have to decide for some config setting I wasn't aware of?

     
  • Greg Roach
    Greg Roach
    2009-10-21

    The order is hard-coded. There is no config option.

    _UID isn't in the list, so its sort order is undefined.

    I could add it (in last place), as you request, but that might annoy people who are happy that CHAN and TODO are currently the final facts.

    It's not worth the effort to write a config option for this (and support and translate it).

     
  • kiwi_pgv
    kiwi_pgv
    2009-10-22

    As earlier, I'm only interested academically, but my preference would be _TODO, then any reference numbers (AFN, GUID etc) in alphabetic order by tag name), then CHAN last.

    Greg, presumably if UIDs were to be created on import, they woud also need to be created on ADD as well?

    These numbers do intrigue me though. Are they really "unique"?, whats stopping someone else generating a UID the same as one I use, for a completely different INDI?, and how do they / can they help with things like merging? Surely John Smith on my tree, and the same John Smith on your tree will have different UIDs just like they have different INDI refs? (Sorry getting well off Wes' request here)

     
  • Wes Groleau
    Wes Groleau
    2009-10-23

    I didn't mean to stir up such a storm.
    I consider it minor, and in fact, on my site, only an admin will see it.
    That said, I suppose my preference would be the same as the Kiwi's.

    The OCCU interests me more, but it, too, is minor.

     
  • Greg Roach
    Greg Roach
    2009-10-29

    <<they woud also need to be created on ADD as well?>>

    If the option is set, then they are. The code is in the "add gedcom record to database" logic.

    PGV UUID's are a "poor man's" version, and only as good as your random number generator. A "proper" uuid, as generated by MySQL uses the mac address, the microsecond timestamap and a random number. They can generallyl be relied on to be unique.

    Wes - the sort algorithm has to work on pairs of events, and cannot easily look to see age/marriage, etc. We cn only set it's order relative to other events. e.g. After MARR. I'll look at these when I get back to my home computer.

     
  • Greg Roach
    Greg Roach
    2009-10-29

    <<and how do they / can they help with things like merging?>>

    I do it by copying them back/forth. Thus after a merge, each INDI gets two UUIDs - one from each gedcom. It allows them to be matched if you subsequently edit/remerge either gedcom.

     
1 2 > >> (Page 1 of 2)