Re: [webmin-devel] making config change to existing module, addingpopup "select users" list

[Jamie C. <jca...@we...>]

On 10/Dec/2005 07:20 Mr Duck wrote ..
> Jamie Cameron wrote:
> >>   Basically, I want to provide a listing of usernames that
> >>will _not_ be listed in the Read User Mail user list.  For example,
> > That's a good idea for a feature..
> 
>    Thanks!  I wasn't expecting a reply from you directly... (=
> I use this module (mailboxes) more than anything else, and so
> the types of changes that I mentioned are very beneficial to me.
>   I would think that others might find them as useful, too.

I agree .. there are heaps of system users like bin, uucp, etc.. that
will never have mail.

> > The only way to do this is to implement your own custom config field
> > type, which is documented at http://www.webmin.com/modules-config.html
> > in the section on config type 15.
> 
>    Ok, I've been experimenting, and have a pretty good understanding
> of what is needed.  I've already added the config.info entries to
> implement the three items, including the type 15 for the userlist.
> I've written a working config_info.pl sub that handles the actual
> user selection, which all was easy to implement, thanks to the
> flexibility of the webmin layout.
> 
>    The only part that is giving me troubles is when it comes to the
> save part.  I don't quite follow what this means:
> -----------------------
> When saving, a function with parse_ is called instead. It can make use
> of the %in hash to find out what the user entered, and must return a new
> value for this module configuration setting.
> -----------------------
> 
>    The part that specifically confuses me is the "new value" stuff
> that is returned.  From what I can tell, the parse_ function simply
> needs to return the new value of the config item.  So, I wrote the
> sub as:
> 
> ---CODE----
> 
> sub parse_userIgnoreList
> {
>    return $in{'ignore_users'};
> }
> 
> ---END-----
> 
> But nothing was saved.  I see where in config_save.cgi the
> config_info.pl is checked, but when it comes to the foreign_call,
> I don't really follow what is happening with the data that the
> parse_ function returns.

That looks OK to me. What does the show__userIgnoreList function contain
though?
 
> > As long as your changes are well written, don't break any existing
> > functionality, and are optional, I would be glad to include them in the
> > module.
> 
>    I really appreciate your encouragement and openness.  Once I get
> the saving thing figured out, how should I go about getting the
> changes to you for examination?  Should I tgz the files involved
> or provide patches or what?

A patch is best, as it is easier to merge..

 - Jamie