Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
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.
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.
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.
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.
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.
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.
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.
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
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).
Huh? Under "MY ACCOUNT" you can change your UserName, your Real Name and your Password, independently of any other changes.
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?