Tags:
create new tag
, view all tags

NewUserPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on NewUserPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on NewUserPlugin

-- MichaelDaum - 18 Dec 2006

Thanks Micha for sharing this plugin with the TWikiCommunity, very much in line with the TWikiMission! cool!

I suggest to make some small mods to the plugin topic:

  • Escape links to oneself
  • Use full URL for Plugin Home/Feedback/Appraisal instead of Interwiki links

For convenience, I updated the MathModePlugin topic.

Addintional notes:

  • How about measuring and documenting the PluginBenchmarks numbers?
  • I added the package form to the plugin topic, please fill in the details
  • I added some more tags. Help with tag votes to make this plugin visible.
  • Codev.BuildingDakar#CPAN_local_minimirror is a bit hidden. Probably better to copy relevant information from there to the existing HowToInstallCpanModules supplemental documentation so that the information is more readily available. (And fix the link in the plugin topic accordingly, with an Interwiki link.)

-- PeterThoeny - 18 Dec 2006

Hi Peter, thanks for creating the additional plugin topics. Infact, I disagree on the replacement of interwiki links with full links as I prefer the shorter interwiki links. I have checked a couple of other topics and have seen that they escape the self-link in the h1 header most of the time. Actually, I use this specific self-link very often to reload a topic, i.e. in PatternSkin as there's no easy way to reload the topic otherwise besides hitting the reload button in the browser which forces cached css and js files to be reloaded too, thus is slower and a thing I like to prevent. On most pages this is the last self-link anyway and in addition in a well-defined position. I admit however, that the links in a h1 header look a bit uggly.

-- MichaelDaum - 19 Dec 2006

In this case it might be better to get Arthur add a reload link to the PatternSkin?

-- PeterThoeny - 19 Dec 2006

Note that this plugin creates a new user topic based on the value returned by TWiki::Func::getWikiUserName(): it is assumed that the external authentication (eg via some LDAP-based form) will set REMOTE_USER to an appropriate WikiName.

-- SteveJames - 12 Mar 2007

Do i have to edit C:\TWiki\data\TWiki\RenderLdapUser.txt to make the plugin work? Note in http://sibi.mycompany.net:8080/twiki/bin/view/TWiki/TWikiPreferences i have set

Set NEWUSERTEMPLATE = NewLdapUserTemplate 
under "Default User Settings ".

I have ldapContrib, LdapNGPlugin and GluePlugin enabled but when i take list of users only default users are listed. I tried using % REMOTE_USER % in a new topic and it gives my correct WikiName.

-- SibiJoseph - 22 Mar 2007

SibiJoseph - it's been a while since I first installed this plugin, but I believe it should work without editing RenderLdapUser. You will want to edit it so that the table in the Implementation section only contains the LDAP fields you want, but that content shouldn't affect the plugin's functioning.

However, I don't understand your description of the problem. When a new user logs in, is a topic created to match their wiki name, or not? Note that this plugin does not update the TWikiUsers topic, so you have to look for a topic matching the wiki name.

-- JohnWorsley - 09 May 2007

I made a modification to my NewUserPlugin.pm so that when it does create a new user topic, it redirects to that topic. This is useful to me because out LDAP server doesn't store email addresses, and this is the best way I could think of to prompt new users to enter their email address - send them to fill in the UserForm right off. So I thought I'd post it in case others would find it useful.

At the end, right after

  if ($errorMsg) {
    writeWarning("error during save of $tmplWeb.$tmplTopic: $errorMsg");
  }
I added
  else {
    my $query = TWiki::Func::getCgiQuery();
    unless ($query) {
      writeWarning("CgiQuery does not exist");
      return;
    }
   my $redirectUrl = TWiki::Func::getViewUrl($mainWeb,$wikiName);
   writeWarning("redirecting to $redirectUrl");
   TWiki::Func::redirectCgiQuery(undef,"$redirectUrl");
  }

-- JohnWorsley - 09 May 2007

It might be an idea if this plugin adds the user to Main.TWikiUsers as well?

-- AndrewRJones - 27 Jul 2007

There is a mis-spelling in NewUserPlugin.pm:

use constsant DEBUG => 0; # toggle me

-- MagicYang - 09 Jan 2008

fixed in v1.0.3

-- MichaelDaum - 09 Jan 2008

It would be great if you could update the plugin to add the user to TWikiUsers. If this is already on your list, do you have an idea of when it might be done?

-- ScottJaffa - 15 Jan 2008

When do you want to add it to TWikiUsers? For example, you better don't in an LDAP setup and just add an %LDAPUSERS% to TWikiUsers instead, which lists them dynamically.

Anyway, if anybody is willing to do that feature request, just attach a patch and I will have a look at it. smile

-- MichaelDaum - 16 Jan 2008

I would do it at the time that it creates the user page. A user logging in means they are probably using the wiki, so that is the time to list them in the wiki. Also, that should make it really easy (I assume) in that all the plugin has to do is call whatever function adds the user.

-- ScottJaffa - 16 Jan 2008

Would it be possible to add TWiki:Plugins/LdapNgPlugin, TWiki:Plugins/GluePlugin and TWiki:Plugins/IfDefinedPlugin to the required dependencies of this plugin?

-- MartinKaufmann - 05 Feb 2008

Only marked as "optional". The NewUserPlugin does not really depend on these plugins. They may only be used in the NewUserTemplate. You could easily use any other plugin in there to create nice default homepages.

-- MichaelDaum - 06 Feb 2008

We've discovered that the plugin barfs when new users have a middle name defined in their LDAP record. Anybody have a preference for where/how to patch that? I'll post whatever we come up with.

-- AaronFuleki - 05 Mar 2008

I installed NewUserPlugin on TWiki 4.2 and it turned out, that the new user topics do not get parent topics assigned. Since I want Main.TWikiUsers to be the parent topic, I figured out the following workaround. Putting the following code in the first line of my Main.NewLdapUserTemplate does the trick. %$nopMETA:TOPICPARENT{name="TWikiUsers"}%

Since there are no other registered users on this TWiki, I created Main.TWikiUsers manually and inserted a %SEARCH{...}% that finds all user topics by their parent.

Hope this helps someone. Please respond if you have a better idea.

-- AlexanderStedile - 04 Apr 2008

Hello,

Why the creation of user topic in the Main web is do by user and not by TWikiRegistrationAgent?

This question is beacuse this way is requerid which users haves permission of change in Main web for create your topic. So they can create others topics not desired.

As resolv this?

Thanks.

-- ItaloValcy - 27 May 2008

This plugin fills the gap where the normal way of registering a user to TWiki is not used, e.g. if you are using the LdapContrib and all users are registered using your LDAP directory - not TWiki. When the user logs in to TWiki authenticating against an external authority like LDAP, he/she will still need a home topic to properly link its wikiname. That's what this plugin does. Sorry if that was not clear reading the documentation.

This also means that users need write access to the Main web / Users web. Last but not least they might want to change their home topic anyway.

-- MichaelDaum - 27 May 2008

Aaron, we have middle names defined as well, and that wasn't issue for New User Plugin, once we made this change in Configuration (under LDAP settings):

{Ldap}{WikiNameAttribute} = givenName, middlename, sn

-- ShivaGoudarzi - 03 Jul 2008

I tried to install via the web installer but got this error:

Error: Installer returned errors:
Odd number of elements in hash assignment at tools/extender.pl line 971.
You may be able to resolve these errors and complete the installation from the command line, so I will leave the installed files where they are. 
To get this and the GluePlugin to install under FreeBSD, I had to chmod u+x the installer and change the perl path to: #!/usr/bin/perl

-- LarryDillon - 04 Aug 2008

Hi Larry, please file this as a bug to the Bugs:BuildContrib package. The installer scripts does not really fullfill an important function anyway. So you can simply unzip the package in your twiki directory and enable it in LocalSite.cfg.

-- MichaelDaum - 05 Aug 2008

I have a question on use of this plugin over time with LDAP where users might leave the organization, and others arrive with the same givenName and sn. We can guaranty that the user's sign-on ID is unique, but we wouldn't want to accidentally reuse or even end up with two active users sharing the same wiki name.

Currently with manual registration we run into the issue of collisions every couple of months or so. We have the user adjust their name during registration to make it unique.

Has anyone dealt with this issue when generating the WikiName from LDAP?

-- GeorgeClark - 08 Aug 2008

That's a more general problem, a missing feature: how to delete users, or better move them to an Alumni web. This problem has not been solved yet.

-- MichaelDaum - 08 Aug 2008

I think that there are at least two issues. In addition to the alumni problem there are duplicate names. At one point in my career, there were three different employees in our corporate directory, each with different employee numbers, but all shared my name. So NewUserPlugin would have to deal with possible duplicates.

If the plugin maintained the TWikiUsers topic, it would be possible to determine if the same WikiName was registered under a different employee ID and follow some method to generate an alternate WikiName. (numeric suffix ???). I think that registering a user with a duplicate name is a different problem than the archives - both could be current users.

If deleted users are moved to an Alumni web, would it update all of the history in RCS so that it is possible to differentiate who made a change when viewing a topic history?

-- GeorgeClark - 09 Aug 2008

Moving folks to an Alumni web either breaks links to homepages, or updates a large number of (also stale) pages if backlinks are fixed. For large organizations I prefer to keep the user homepages where they are, but replace the content with a note such as "Mike left the company in 2008, new contact person is JimmyNeutron."

-- PeterThoeny - 16 Aug 2008

Deleting a user or moving it to an alumni web is definitely a missing feature. Other wikis offer the option to transfer ownership to another user that still is active and will take over responsibility for the content previously owned by the old user.

In any case: this is out of the scope of what this plugin tries to achieve. Still these are all valuable ideas. In fact, one of my current clients does need an alumni feature. There are several reasons for that, some of them are also of technical nature.

There is a feature request somewhere on Codev where this all is being discussed as well. Forgotten which one it was.

-- MichaelDaum - 16 Aug 2008

Somehow I managed to evolve this to a delete user discussion. What I really was proposing was that this plugin needs to optionally maintain the TWikiUser mapping, so that the code that derives WikiName from LDAP could detect a duplicate registration. By not recording new mappings anywhere, it really depends upon the LDAP attributes deriving unique WikiNames.

I'd like for our organization to use this to auto-register new users. We'll write our own UserMapping module. But we need to somehow discover duplicate WikiNames.

-- GeorgeClark - 17 Aug 2008

Users::TWikiUserMapping::addUser has the code to add the user mapping to TWikiUsers. I assume that as it is not a documented Func:: api, this plugin shouldn't call addUser. But duplicating code into this plugin to add the mapping doesn't seem right either. Suggestions?

-- GeorgeClark - 17 Aug 2008

Func is mostly for plugins. If you are about to create your own UserMapping, you are already beyond it.

-- MichaelDaum - 17 Aug 2008

But if NewUserPlugin is what creates the user's topic, shouldn't it also be the place to update the TWikiUser topic? I guess I'm not fully following the division between what should happen in Mapping and what should be done in NewUser. Sorry to be dense.

-- GeorgeClark - 17 Aug 2008

Actually, managing users in TWikiUsers is a specific thing of the standard TWikiUserMapping and the TWiki registration agent. Maybe have a look at this code and inherit your new user mapping from TWikiUserMapping so that you get the interfaces and features you are looking for. It is all there already. The NewUserPlugin does only come into play to complete a UserMapper that keeps all of its user and group information outside of TWiki, i.e. when there's no redundant user information in some TWikiUsers topic. That's the case, for example, when you are maintaining all of your users in an LDAP directory, while you authorize and authenticate users with in TWiki using mod_ldap or LdapContrib. Baseline, I think that you should not bother with this plugin here. It seems that the feature you want can be done without it by using code already in the core engine.

-- MichaelDaum - 17 Aug 2008

Doc says, NEWUSERTEMPLATE defaults to NewUserTemplate, but code says NewLdapUserTemplate. Which one should I change?

-- OliverKrueger - 15 Sep 2008

Edit | Attach | Watch | Print version | History: r33 < r32 < r31 < r30 < r29 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r33 - 2012-06-28 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.