[Moin-user] Clarification of userid & help doc

[Thomas Waldmann]

> I)
> The first paragraph of Help => Admin => User doc on my rev states:
> ____________________________ <paste from help doc> _____________________
> User data is stored in directory data/user in files that have the user
> id as filename. The files with the appendix .trail contain a history of
> what pages the user visited last.
> ____________________________ <\paste from help doc> ____________________
> 
> At my moin rev=1.5.8(FC-8) this is not true.  If development is to keep
> the design I am working with in place, then perhaps the help doc might
> be revised to say:
> ____________________________ <paste to help doc> _____________________
> User data is stored in directory data/user in numerically numbered files
> that have the user id in the field "name=". 

Well, this is just a misunderstanding.

userid IS that numerical thing.

The user's name (login name) is called username (not userid).

> The numeric file name is
> generated at user registration time in a format like a.b.c and the
> significance of the numbers are:
>   a is ---
>   b is ---
>   c is ---

This is a internal detail. If it is interesting, look into the code.
Otherwise take it just as random, unique userids.

> Therefore at the root user level, all users might be listed by:
>   "...# grep ^name= *"
> or a particular user may be found by:
>   "...# grep userid *"
> where userid id the userid of a particular user who is being sought.

s/userid/username/ # :)

> The files with the appendix .trail contain a history of what pages the
> user visited last.

As of 1.6.0, this is not true any more. The trail is now stored into the
session. And the bookmark(s) are now stored into same file as all other
profile settings.

> II)
> The help doc treats the subject of user removal thus:
> ____________________________ <paste from help doc> _____________________
> You can remove a user by deleting his user file (and other files that
> are named with that userid prefix). 
> 
> Be aware that if you do that, you will destroy the edit history of that
> user. Moin won't be able to show this user in page history, because this
> user id will then be unknown. So better disable an account rather than
> removing it. After user data is deleted, MoinMoin may still think the
> user exists due to the user cache in data/cache/user/name2id. Deleting
> this file purges the cache and should fix this problem.
> ____________________________ <\paste from help doc> ____________________
> 
> There is a related aspect of removal that is not treated and perhaps
> needs to be reviewed by both development and document groups.  The
> "preferences" page presents the "name=" field for editing by the user
> even after registration time.  I have not tested this action, but should
> I revise my name by editing the name field then I have effectively
> caused removal of the former userid per the above description and at the
> same moment registered under a new userid.

No, you still have the same userid, but a new username.

Just imagine a women (or man) getting married and changing her (his)
last name.

Name changes, identity stays the same.

>  Without reverting to the
> root user and using various find/grep/awk/vi utilities to rebuild the
> database it seems to me that allowing a user to change "name=" field is
> a potentially disastrous option.

You can disable that field if you don't want it editable. But it has
good reasons it is editable. Users are usually allowed to create an
account for themselves (and it will accept any name they enter). So
instead of changing the name, they could also just create another
account. The problem is that if they do, they really have 2 identities
(as far the wiki is concerned). So this is a bad option for the marriage
case, for the oops/typo case and also for the nick->realname change
case.

> I'd like to be able to rewrite the
> help doc, but my knowledge is not deep enough.

It's good to talk first. :)

> III)
> Having presented the above two subjects, I expect to use these concepts
> soon to "bring consistency" to the user group on the moin wiki under my
> care.  This action of mine will require both removal of user file
> duplication and [maybe] editing individual user name fields.  I will try
> to remedy past randomness with future pre-registration instructions on
> selection of "acceptable" user name field data.
> 
> The last issue for me is to ask this group if built-in code tied to the
> name field having the purpose to make all the required substitutions in
> the database which allows a user to edit his name without adverse
> consequence is warranted?  If not, I expect awk might become my friend
> again...

If a user changes his/her username in the profile, RecentChanges and
page info action will automatically show the new name afterwards.
Of course, it will not change group pages and ACL entries.
Thus, if that username is used in some ACLs or on group pages, the name
will have to get change there also.

It is also a good idea to kill the name2id caches after doing changes in
the filesystem.