> I followed copied the example config provide to run on my server .
> Apparently , the author field was blank when i do a reply .
> I was hoping to get it to be the actual reply author.
> Just like the way the forum is done up.
> Please help ..

This (new) behaviour came from the request that some people id *NOT* want to
have the new author on the reply, but the *ORIGINAL* (they used an attribute
"Origial author" which should not be replaced on a reply). Therefor I added a
new option to resolve that. So please use

Preset Author = $long_name
Preset on reply Author = $long_name

if you want to have the attribut "Author" replaced by the current one both on
new entries and on replies.

Hello Kay,

I had to look it up in the source code: yes, you are right, it is hard-coded in elogd.h

elogd.h:#define MAX_N_LIST      100

You can of course change the limit and recompile.

As an alternative, you could have sub-menus with less than 100 entries  (disclaimer: the following is untested example):

Cheers

Andreas

Hello Andreas,

thanks a lot for your quick reply - both options are valid and working. For simplicity (the author list is generated automatically from a shell script) I opted for the first one.

Best regards,

Kay

> When ELOG is configured for Self-Register=3, is it still possible
> to use the Author attribute as a Quick Filter? 
> 
> When I try it, the Author drop down box doesn't display anything.
> 
> Thanks,
> Eric

The "Quick Filter" facility only works for attributes which are avaiable as 
an "Options <attribute> = ..." list. So if you have a "free" attribute like 
the author, the systen would have to scan the whole logbook to find all 
possible authors, which would result in some unacceptable performance 
degradation. Nevertheless, in systems with a limited number of authors one 
can add the "options author = ..." statement to get the selection box. The 
behaviour is independent of the "Self-Register" setting.

> Is it possible to make the author and pwd check case in-sensitive??  I 
> noticed that unless you type your userid and password in the same case each 
> time, the system doesn't recognize your or thinks the info is invalid.
> 
> thanks,
> eric

Well, that's how it should be. All other systems I know like Windows NT 
Login, Linux login etc. are case-sensitive, so we should follow that standard.

I've just checked that 'wget --no-check-certificate --save-cookies cookie.txt --keep-session-cookies -d "https://elog-gfa.psi.ch/SLS?uname=uuu&upassword=ppp" -O elog.txt'

created a file cookie.txt. The file contains three lines of data if uname and upassword are a valid login, and it is empty (beside of three comment lines) if they are not a valid login (wrong user or wrong password).

Could it be related to the set-up of your particular logbook?

Can you tell me how to reproduce this? If I do it here, I just get back to the login page:

Maybe it has to do with your specific Kerberos implementation? What server are you using?

 I am sorry but I cannot reproduce this any more. It happened several times when I was testing different kinds of wrong user input to the authentication dialog but now there is no issue any longer. However, there has been other issues lately in this domain and it may be that the Kerberos installation has been patched by our automatic update installation.

Case closed! Thanks anyway for responding.

Soren