It will be interesting to see how this is done.

A lot of the e-mail addresses for web users at our site are bogus, because the default choice that's presented to them is the concatenation of: The user name they're choosing to be known as here + "@" + the result of running reverse DNS lookup on the IP address they're coming in from There probably isn't any better way to construct such a default, but unfortunately an e-mail address constructed according to this procedure will be bogus in many cases, and a lot of people don't bother to edit the default... So the result is that there's a lot of bogus pseudo-addresses of the general type "MickJagger@dial-in-ppp42-9.custmax.ms.uu.net", or whatever...

A lot of the e-mail addresses for web users at our site are bogus, because the default choice that's presented to them is the concatenation of: The user name they're choosing to be known as here + "@" + the result of running reverse DNS lookup on the IP address they're coming in from There probably isn't any better way to construct such a default, but unfortunately an e-mail address constructed according to this procedure will be bogus in many cases, and a lot of people don't bother to edit the default... So the result is that there's a lot of bogus pseudo-addresses of the general type "MickJagger@dial-in-ppp42-9.custmax.ms.uu.net", or whatever...

This is the purpose of the "Participants" button which should be at the top of the page of the list of topics in the conference. By default, this shows the login, last time on, and full name (but not email address) of the participant. A host can change this by putting a command in the conference rc file which redefines the "partmsg" variable to look like anything you want. For example, def partmsg '%10v %o %20u %{email}' will show the login, last time on, full name, and email address. If you just want a list of email addresses of conference members yourself, you could generate this in Unix and save it to a file from in Yapp with: def partmsg '%{email}' participants > filename -Dave

Wait a second. Did I miss something? Or was Henry talking about the registration process and Dave talking about ways to capture stuff already entered?

Mine was in response to Arnessa's original question.

] Mine was in response to Arnessa's original question. __ Aha! Dave! The case for threading...

We have two problems; here's the first: We want to configure a conference so that everybody can read it (even those who have not logged in), but only fairwitnesses and/or people in the "ulist" file can post to the conference (it doesn't really matter which of these two classes is privileged). So far we"ve tried the following ACL files: _________________________________________ r +all w +all +registered +f:ulist -f:observers c +all +registered +f:ulist -f:observers _________________________________________ r +all w -all -registered +f:ulist -f:observers c -all -registered +f:ulist -f:observers _________________________________________ And the following CONFIG files: _________________________________________ ! .austenarchive.cf 20 amy jwinsor mhc mrobens terry readonly ulist _________________________________________ ! .austenarchive.cf 0 amy jwinsor mhc mrobens terry 0 _________________________________________ ! .austenarchive.cf 0 amy jwinsor mhc mrobens terry 16 _________________________________________ Any hints?

Our second problem (less urgent) is that we would like to change the buttons in individual conferences, if we could. The /usr/bbs/www/rc.yapp-bin file has definitions such as (changing angle brackets to square brackets): define help '[a href="http://www.spring.com/help/intro.html"][img src="%{gifs}he lp.gif" alt="Help" border=0][/a]' Where %{gifs} resolves to /yapp-icons/ If we try to redefine the variable gifs in the rc file of an individual conference (by means of a line such as the following), it doesn't seem to have any effect: define gifs "/yapp-icons/austen/"

I suggest you try the following combination to make a conference readable by the world, and writable to only those who are in the user list or the fairwitness list (execpt those explicitly mentioned in the observers file), and to make topics createable by fairwitnesses (except those listed in the observes file) _________________________________________ r +all w +f:ulist +fwlist -f:observers c +fwlist -f:observers _________________________________________ It really shouldn't matter your conference security type when using an acl file. The only things that will make any difference, are if the security is a MAILLIST or a REGISTERED MAILLIST. All other conference types are overridden by the acl file. ****** IMPORTANT NOTE ********* Even if you do make this change, the "Enter a topic" and "Respond to topic" buttons and forms will still appear. In version 3.0.14 the capability has been added to make the "Enter a topic" and "Respond to topic" forms and buttons unaccessable if the user really cannot Enter a topic, etc. Previously the templates only checked to see if the user was an "observer" before displaying the buttons. Checking for "observer" is no longer a sufficient test. In version 3.0.14 you can check if the person can read topics by testing the "canracl" variable, can respond to topics by testing the "canwacl" variable, or can create topics by testing the "cancacl" variable. Without adding these explicit tests so that the forms no longer appear, the forms will be accessable but the information sumitted will not be posted to the conference.

the capability has been added to make the "Enter a topic" and "Respond to topic" forms and buttons unaccessable if the user really cannot Enter a topic, etc. ___ Good improvement.