Locking down user home pages was added to Dakar, it is a requirement to work around the issue of sending password reminders.
This is bad for several reasons:
- A typical TWiki installation behind firewall (TWiki:Codev.TWikiMission) uses external authentication (LDAP, NIS etc) where password reminders are not applicable
- It sends the wrong message. Wiki collaboration needs to be open for all. Locking down ones home page brings us back to the database world with tight access control, which is the opposite of free form wiki collaboration. Lets remove that mental barrier to collaboration
- Other users can't fix typos on user home pages
- Other users can't send a message to another user (barn star etc)
Peter pointed out this design issue to Martin several month ago in an IM conversation but we collectively took no action.
Possible solution is to store e-mail addresses internally in TWiki (and keep the e-mail in the user home page). Whenever a user saves his/her own topic the internal address gets updated (and ignored if someone else changes the e-mail address)
- Can this information could be stored in .htaccess? MC
- Not sure it can. It does not need to be. It can be a separate .emails file PTh
If I recall correctly, we discussed to add the e-mail address to the wite protected TWikiUsers
- SomeUser - somelogin - email@example.com - 05 Oct 2005
In retrospect might be better to have them completely invisible, as it is too easy to filter out the spam filter.
However, now we have the UserList
topics does anyone except the administrator need access to view TWikiUsers
We do need to ensure the login name is viewable by the user, but that might be better as a lookup displayed on the user's home page.
I understand the points made, and don;t like locking down home pages, but I can't see us coming up with an alternative in the immediate future. Deferred - we should address this in Edinburgh.
Not agreed, this needs to be looked at.
redefered - we are 3 days away from a release candidate. this mean is is
too late to change the way things are done.
And reopened. Lets look at the outstanding issues together at the time of the release candidate. I am not saying that this must be fixed, just that the options need to be looked at and then decided at the time of RC.
Peter, you are not following the work practice that we are using here in the Bugs web (for months now). we are trying to track what needs to be done, not waht needs to be considered. deffered, until such time as its actively decided to be acted upon. we need
to be able make it obvious what the current headline items are.
it's still an "Urgent" thing (which is different than "Requirement"). i also do not like home pages being locked down by default. as previously stated, it's not very wiki-like. otoh, it's not as if home pages have been promoted very heavily for the purpose of communication (like on usemod.com et al); rather, it's more about configuration settings. so there is some tension here as to what they're supposed to do.
reiterating cdot's point, "I understand the points made, and don't like locking down home pages, but I can't see us coming up with an alternative in the immediate future." so, until there is at least a plan of action, or someone is actively working on it, it should stay "Deferred"
sounds perhaps like this discussion
should move back to Codev?
Anything that helps fix this collaboration issue should be done. This design issue could be a reason to delay the Dakar release if nobody is actioning on it.
Follow-up in TWiki:Codev/RemoveWriteProtectionOfUserHomePages
Undeferred, post Dakar CC
TWiki4 ships with world-writable user home pages pr. default already, closing this. Report seperate issues hidden in this discussion as new items?