Item9671: New users' topic dosen't have the useful links

When I create a new user, his topic shows the userform but it doesn't include the links for ChangePassword and the other useful stuff.

-- JuanPabloGaviria - 14 Sep 2010

It appears as though the feature proposal CleanUpNewUserTemplate remove all of the helpful stuff, with the intention to move it into a View template. I don't see that the 2nd half was ever completed. Confirmed

Set this to Urgent for 1.1.3. IMO the development proposal was not completed unless some alternative source of information is provided to the user.

-- GeorgeClark - 20 Mar 2011

Now that we have the AutoViewTemplatePlugin we can in principle easily fix this.

BUT here is the problem.

For an upgrader all the existing user topics have all the useful links. So adding to a view template means all the upgraders will end up with these links duplicated.

Another thing is that to someone not understanding view templates (that is 100% of new users and 99% of existing users) it is a bit strange that you see something when you view the page, but when you hit edit the page is blank and you cannot remove it.

Another important problem is that if you use another way to handle passwords than the Foswiki way (central single sign on solution) which many of us do, the reset password, change password, change email are all none working and will be tailored to just be a link to the corporate password resources on the intranet. And in this case, how useful is it to the users having this on their home page?

Then it is better that the admin can add this info to the New User Template topic if he wants it. So I am not sure what I would want to do with this bug item.

I hate hiding information and UI from users. I also hate having duplicate info, mysterious content you cannot delete, or useless resources.

-- KennethLavrsen - 20 Mar 2011

The result of the change for the "TemplateAuth" user is that they register, and are presented with two links:

• Your personal topic YourUserTopic has been created. How about uploading a picture.
• You are also listed in WikiUsers.

As you say, the view template for this type of stuff - things the experienced user might want to delete - it probably the wrong solution. It takes the worst features of the topic cruft and puts them into a magic topic overlay that can't be easily removed. So the alternatives:

NewUserTemplate

Creates obsolete info over time. Fills user topics with "cruft". Requires bulk topic changes if there are certain config changes, different mapper, enterprise password manager, etc. So this is out.

AutoViewTemplate

All users get the same cruft, and can't delete it or tailor it to their personal desires. Doesn't give the user anything to start with in their topic, such as examples of settings a user might want to modify. (Size of edit window, tooltips, Choice of editor, etc. .. we get support questions about these.)

How about this:

• NewUserTemplate as before tailor it to have:
  1. An %INCLUDE of WelcomeNewUser information. avoids duplication, can still be deleted, WelcomeNewUser would be implemented like the UserRegistration topic with the default and local versions included from System and Main to avoid tailoring issues. Maybe include a Twisty - default open - so the newbie can hide it before they delete it.
  2. A "commonly tailored settings" section. In this case, duplication is good, since they need to be edited. User can still delete them. These are handy to have available, and address some frequently asked questions on support.
  3. A %INCLUDE of ManagingYourAccount. That would in turn include a topic based upon LoginManager, PasswordManager, and other config information. (Maybe this should be done with the AutoViewTemplate)

This way the user topics get a minimal amount of useless information, and common information that can change over time is not duplicated. And if a site changes LoginManager, then the changes are automatically propagated to the users.

This it turning into somewhat of a development proposal, but IMHO the CleanUpNewUserTemplate should have addressed this. Just deleting the new user help and ignoring the proposed alternative was not exactly friendly toward the new users, and leaves us dealing with support questions and tasks like this.

-- GeorgeClark - 21 Mar 2011

Please see suggested changes to User Topics in http://foswiki.org/Tasks/Testcases/Item9671UserTopic. It adds back some "cruft" that is set per user, and triggers occasional support questions. Other boilerplate comes from includes. Have not figured out the Auto view templates yet.

-- GeorgeClark - 21 Mar 2011

The more I think about it the more I agree with Michael Daum that ANY such thing on the users home topic is cruft.

I see two needs here.

The links for the beginner that he needs the first hours of use. I would put these in the welcome email. I have seen in practical that newly registered users go there to find their way to our wiki and noone cares about their home page and hardly ever go to it.

So I would put some welcome links in the registration email to get people started well off.

The other need is to be able to find reset password, change password, and change email.

For those the reporter is used to finding the links there but they are also available elsewhere. I would rather we revisit if we have these resources the right places than adding them to the user home page. Maybe eveb in the left bar in Main web could be considered.

-- KennethLavrsen - 21 Mar 2011

I like the convenience of having the "typical user settable stuff" in the user topic. The idea of needing to raw view DefaultPreferences to find the settings, possibly merge them with the SitePreferences values, and then synthesize them into the settings in a user topic is utterly beyond the normal user. And yet we get support questions - how do I disable WYSIWYG, for example. Presenting the user with an empty topic is a rather insurmountable obstacle.

I certainly agree that the data needs to be included / normalized so that duplicated information subject to change is not present.

If the empty topic is the preferred results, what's the point of having the topic at all. The bulk of the information in the UserForm is unneeded from an operational standpoint. The WikiName in the WikiUsers topic provided the login / WikiName maping, and the .htpasswd file provides the email mapping.. So maybe the minimalist solution is to make the topic optional even for the TopicUserMapping?

Anyway. So set this to no action? I've downgraded to Normal so it's not a release blocker.

-- GeorgeClark - 22 Mar 2011

George

You are now touching a 3rd need - user preferences. These cannot be set in the user view template. They have to be set either as visible Set prefs or as meta defined prefs.

We used to have many prefs. Most have lost the meaning. The email pref was replaced by the htpassword based pref OR set in the form.

The edit window size pref was replaced by a resize feature that stores the size in a cookie. You can still define an initial size but it has little meaning today.

You can still set things like skin - IF the site has multiple skins. 99% of sites will not work well with other skins than the one the site is set up for. So a visible skin setting will in 99% of the time be useless or damaging.

Turning off Wysiwyg is a wish from many super users. That one was actually never in the new user template. And we have changed the way you turn off wysiwyg a number of times now.

I see 3 possible things we should consider.

• Add 2-3 resource links to the beginner tutorials in the welcome email.
• Add an additional entry in the tools section of the Main web left bar which points to a small page that contains the resources a user needs. We need to build such a page with care so that sites with an alternative password manager works also. I have some ideas I want to play with.
• For preferences we should consider adding a feature in the view template that enables turning user features on and off using a nice user interface instead of geeky Set statements.

Just for info - today all new users (and it has been like this for many years) have a user topic with a * Local VIEW_TEMPLATE = UserView.

In pattern skin this loads the PatternSkinUserViewTemplate which simply defines the form to be at the top.

We should conside adding a feature to this template (skin dependent implementation) so that the user could enable and disable certain features. I have used such a method for setting fields in a form in an application I made and it works great. Maybe we can use same method to change preference settings in meta.

For this bug item I would concentrate on the original report which was the useful links and I will see if I can make the email improvement and a nice simple link in the left bar. The end user will not know the difference between the left bar and links inside his topic.

And the preference part should become a feature proposal. Let us start discussing this a nice evening on IRC and storm some ideas.

-- KennethLavrsen - 22 Mar 2011

Defer to 1.1.5

-- GeorgeClark - 13 Dec 2011

I think we can close this as no action. There is disagreement on what to put where and the task is pretty old.

-- GeorgeClark - 17 Jun 2014

Commenting is disabled while not logged in