nasty side effect of changing userid

  • Paul Seesink

    Paul Seesink - 2011-12-30

    I have a user who has updating rights. Some time ago he changed his username. Resultingly his updates were since then registered with his new username. Some time later he mailed me that he could not update anymore records that he created/changed earlier. It took me some time to discover what happened. I solved it by mass changing the update registrations (_PGVU) from the old username into the new username.
    Discussion point:
    I would prefer a change where I would be notified that a user  wants to change his username. Then I could take the above measure  in advance, preventing unforeseen things to happen.
    Without such a timely intervention weird things might happen, in case a user changes his username into a former username that still exists in _PGVU records in the GEDCOM, resulting in inconsistent data. The chance that this will happen is anyway very low.

  • Gerry Kroll

    Gerry Kroll - 2011-12-31

    It sounds to me as if the real problem isn't that the userid was changed, but that the changes made by the user had not been reviewed by the admin.

    You need to review your procedures regarding changes made by your editing users.  After the change is made, it is put into limbo, waiting for admin approval.  After admin approval, the change will appear in the database, to be viewed by any other users.  Until the change is approved, only the admin and the original editing user can see its effect. 

  • Paul Seesink

    Paul Seesink - 2011-12-31

    I opted for skipping the review of the changes by that particular user, as he is knowledgeable and reliable for quality; thus accepting the changes in the automatic way, as a matter of efficiency.
    I suppose that the extra coding for the admin review has no influence on the registration of the username of the responsible person. So when that person changes at a certain point in time, the registration will subsequently be done with the name username, I guessed.
    That is the design issue, I wanted to expose.

  • Stephen Arnold

    Stephen Arnold - 2011-12-31

    pseesink ?
    I think you misread Gerry's post. There is no design issue to expose. Once the data in the CHAN tag is accepted within the database (and then appropriately within the GEDCOM) the USERNAME might as well be Mickey Mouse, Donald Duck or Beyonce. It is only a reference and has no future effect or characteristics which persist within the code to relate that change to any previous user. Another example:  John Smith is a longtime user. He's made thousands of additions and changes to the GEDCOM, all with USERNAME JSmith.  John dies and doesn't make more contributions from beyond the grave.

    His changes remain within the GEDCOM data until someone else makes a more recent change, and then his CHAN tag reference is replaced and there remains no indication that he contributed any of the original data.  Now whether this is proper or not is open to discussion, but not interpretation by the standard.  Some of us believe we would like to have a log of changes to know who, what and when, but that would be an enormous undertaking, particularly in an active and large family tree.

    Your user changing his U/N had no effect on PGV or the family tree data, except where there were changes that had not yet been accepted into the database. Pending changes are lost upon export too - hence the warnings.

  • Paul Seesink

    Paul Seesink - 2012-01-01

    Stephen, thanks for your explanation about the way the CHAN tag is used. I have clearly fantasized wrongly due to a  coincidence of my user trying to chance a person's data outside his "Max relationship privacy path length" and the fact that he chanced recently his username. So I will close this discussion. Excuse for having used your time unnecessary.

  • Gerry Kroll

    Gerry Kroll - 2012-01-02

    I don't think you need to apologize.

    These discussions often help to improve people's understanding of the finer points of PhpGedView's behaviour.  Therefore, the discussion was useful.

  • Stephen Arnold

    Stephen Arnold - 2012-01-02

    Nor did I think you did. It was a legitimate question that allowed us to clear explain a procedure that others may find useful.
    Thanks for the opportunity to answer it.
    Happy New Year, -Stephen

  • Anton Largiader

    Anton Largiader - 2012-01-09

    I'm a bit surprised to see that the username is the userid. I would have guessed that there was a unique (probably keyed and sequential) userid that does the heavy lifting, and the username is something that could be independently changed (like the password).

  • Stephen Arnold

    Stephen Arnold - 2012-01-09

    Huh? Under "MY ACCOUNT" you can change your UserName, your Real Name and your Password, independently of any other changes.

  • Anton Largiader

    Anton Largiader - 2012-01-13

    Yes, but the impression I get in this thread is that it isn't really independent.

    I would have assumed the program thinks: "User 321 (who is currently named okbigkid) made this change."

    It seems that the program actually thinks: "User okbigkid (who doesn't exist any more) made this change."

    The former is how nearly everything else that I know of works. Tying rights and security to a user-changeable field is a bit odd. Am I misunderstanding how PGV uses the username?


Log in to post a comment.

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

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks