> I needed the export feature and could not find documentation on it in the latest 
> version. I finally read the code and added Find Menu Text = <filename>
> where filename had the tags XML, CSV1, and CSV2
> This always exports all records. Shouldn't it just export the records appearing in 
> the window?

Exporting workes as follows: Click on "Find", and switch the radio button to XML or CSV.
If you click on "Search", you will be prompted where to save the resulting "export.xml"
or "export.csv". I did this through the search page because you can then specify som
filters, in order not to export all records.

> (BTW, the XML export is not valid. Internet Explorer complains about the first line)

The XML charset in the first line was missing. I fixed that, new version under CVS. Or
you can manually change the first line to

<?xml version="1.0" encoding="ISO-8859-1"?>

> > I needed the export feature and could not find documentation on it in the latest 
> > version. I finally read the code and added Find Menu Text = <filename>
> > where filename had the tags XML, CSV1, and CSV2
> > This always exports all records. Shouldn't it just export the records appearing in 
> > the window?
> 
> Exporting workes as follows: Click on "Find", and switch the radio button to XML or CSV.
> If you click on "Search", you will be prompted where to save the resulting "export.xml"
> or "export.csv". I did this through the search page because you can then specify som
> filters, in order not to export all records.
> 
> > (BTW, the XML export is not valid. Internet Explorer complains about the first line)
> 
> The XML charset in the first line was missing. I fixed that, new version under CVS. Or
> you can manually change the first line to
> 
> <?xml version="1.0" encoding="ISO-8859-1"?>

Thanks much!! I can't believe I missed seeing those options. Works great. (There is a 
danger to having the source code. You tend to read it instead of looking at the way the 
program works )

BTW,
Is there any way to turn off the Text column at the right side of the list?

> BTW,
> Is there any way to turn off the Text column at the right side of the list?

Summary lines = 0

> > In order to avoid having to remember multiple usernames/passwords for
> > different systems, is it possible for ELOG to use external authentication
> > via Active Directory, etc?
> 
> Not yet.

I would note that this is a request that comes in fairly frequently, but to
Stephan's credit (and looking back at previous comments) the task of trying to
implement authentication that would *not* be a maintenance nightmare basically
pushes such a request down to the bottom of the list.

The only common denominator that could possibly cover all contingencies would
be LDAP authentication.  One way of doing this in a more-or-less universal
fashion is to offload the auth task from eLog itself and place the burden on
Apache.  This means figuring out how to get Apache to pass auth info to eLog
when eLog operates behind Apache.  In the end, anything that can use LDAP as an
authentication mechanism (like AD) can host eLog - as long as eLog can glom off
of Apache's ability to do the actual authenticating.  

For our twiki (source from twiki.org) website, we use the following config:

-- In Apache http.conf
LoadModule auth_ldap_module   libexec/auth_ldap.so

AddModule auth_ldap.c

AccessFileName .htaccess

# Twiki
Include /proj/www/twiki/conf/httpd.conf


-- The http.conf in the Twiki directory
<VirtualHost *>
        DocumentRoot "/proj/www/twiki/html"
        ServerName twiki
        ErrorLog error_log
        CustomLog access_log combined
        <Directory "/proj/www/twiki/html/bin/">
                Options +ExecCGI
                allow from all
                AllowOverride Authconfig FileInfo Indexes Limit Options
        </Directory>
        <Location /bin>
                Options +ExecCGI
                AuthType Basic
                AuthName CoreID
        CustomLog access_log combined
        <Directory "/proj/www/twiki/html/bin/">
                Options +ExecCGI
                allow from all
                AllowOverride Authconfig FileInfo Indexes Limit Options
        </Directory>
        <Location /bin>
                Options +ExecCGI
                AuthType Basic
                AuthName ID
                AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
                require valid-user
                allow from all
                <Limit OPTIONS>
                        Order Deny,Allow
                        Deny from all
                </LIMIT>
        </Location>
</VirtualHost>

--- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
the following:

RedirectPermenant       /       http://twiki.co.com/bin/view.cgi

--- Also in the /bin directory we have:

Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi

AuthType                 Basic
AuthName                 "LDAP Login"
AuthLDAPURL
ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)


SetHandler cgi-script

ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth

<Files ~ "[^/]*\.html$">
       SetHandler blabla
       allow from all
</Files>

<Files "*">
       require valid-user
        allow from all
</Files>
-------------------------

Whether this is at all relevant, well . . . . 

> > > In order to avoid having to remember multiple usernames/passwords for
> > > different systems, is it possible for ELOG to use external authentication
> > > via Active Directory, etc?
> > 
> > Not yet.
> 
> I would note that this is a request that comes in fairly frequently, but to
> Stephan's credit (and looking back at previous comments) the task of trying to
> implement authentication that would *not* be a maintenance nightmare basically
> pushes such a request down to the bottom of the list.
> 
> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication.  One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache.  This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache.  In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.  
> 
> For our twiki (source from twiki.org) website, we use the following config:
> 
> -- In Apache http.conf
> LoadModule auth_ldap_module   libexec/auth_ldap.so
> 
> AddModule auth_ldap.c
> 
> AccessFileName .htaccess
> 
> # Twiki
> Include /proj/www/twiki/conf/httpd.conf
> 
> 
> -- The http.conf in the Twiki directory
> <VirtualHost *>
>         DocumentRoot "/proj/www/twiki/html"
>         ServerName twiki
>         ErrorLog error_log
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName CoreID
>         CustomLog access_log combined
>         <Directory "/proj/www/twiki/html/bin/">
>                 Options +ExecCGI
>                 allow from all
>                 AllowOverride Authconfig FileInfo Indexes Limit Options
>         </Directory>
>         <Location /bin>
>                 Options +ExecCGI
>                 AuthType Basic
>                 AuthName ID
>                 AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
>                 require valid-user
>                 allow from all
>                 <Limit OPTIONS>
>                         Order Deny,Allow
>                         Deny from all
>                 </LIMIT>
>         </Location>
> </VirtualHost>
> 
> --- Then the DocumentRoot ("/proj/www/twiki/html") has a '.htaccess' file with
> the following:
> 
> RedirectPermenant       /       http://twiki.co.com/bin/view.cgi
> 
> --- Also in the /bin directory we have:
> 
> Redirect http://twiki.sps.mot.com/index.html http://twiki.sps.mot.com/bin/view.cgi
> 
> AuthType                 Basic
> AuthName                 "LDAP Login"
> AuthLDAPURL
> ldap://ldap.co.com:389/ou=People,ou=Intranet,dc=co,dc=com?uid?sub?(objectClass=*)
> 
> 
> SetHandler cgi-script
> 
> ErrorDocument 401 /bin/oops.cgi/TWiki/TWikiRegistration?template=oopsauth
> 
> <Files ~ "[^/]*\.html$">
>        SetHandler blabla
>        allow from all
> </Files>
> 
> <Files "*">
>        require valid-user
>         allow from all
> </Files>
> -------------------------
> 
> Whether this is at all relevant, well . . . . 

Food for thought--thanks!

> The only common denominator that could possibly cover all contingencies would
> be LDAP authentication.  One way of doing this in a more-or-less universal
> fashion is to offload the auth task from eLog itself and place the burden on
> Apache.  This means figuring out how to get Apache to pass auth info to eLog
> when eLog operates behind Apache.  In the end, anything that can use LDAP as an
> authentication mechanism (like AD) can host eLog - as long as eLog can glom off
> of Apache's ability to do the actual authenticating.  

That sounds to me like a great idea. If anybody gets this working, people would be
grateful if this could be submitted to the "Contributions" section of this forum.

> > Currently there is a dropdown when searching for MOption fields. Maybe you could 
> > allow multiple selections in the dropdown. This to me is an "OR" search.
> 
> Multiple selections are not possible in HTML, only a single value can be selected at
> a time.

Try: (From monster.com)
<SELECT NAME="lid" multiple size="5">
<OPTION VALUE=""> ------- Select all -------- </OPTION>
<OPTION VALUE="323">Alabama-Anniston</OPTION>
<OPTION VALUE="324">Alabama-Birmingham</OPTION>
<OPTION VALUE="325">Alabama-Mobile/Dothan</OPTION>
<OPTION VALUE="328">Alabama-Montgomery</OPTION>
...
</SELECT>

Although this may not be supported in all browsers. (I think recent versions of 
Netscape and IE support it)

<SELECT NAME="lid" multiple size="5">

Oh, nice, I didn't know of that. However, I prefer to have multiple options to be selected
with individual check boxes, this saves more vertical window space. So I added that
functionality to the find page. If more than one option of a MOptions attribute are
selected, they are or'ed together during the search. You can try that in this forum with
the "OS" for example.