Hello Folks,

Found an interesting problem with 2.3.7 under redhat 9.0 linux.

When you take the elogd.cfg file and the menu commands = <list> and guest 
menu commands = <list>, the config menu for edit the elogd.cfg stops 
working, yet if I change the URL manually, I can still get to the file and 
the menus do not change.  If I delete all menu commands, then all works 
without errors, yet the menus do not match default.

Also, the self registration function equal to 3 does not always send email.

Cheers,
Roberto

> Hello Folks,
> 
> Found an interesting problem with 2.3.7 under redhat 9.0 linux.
> 
> When you take the elogd.cfg file and the menu commands = <list> and guest 
> menu commands = <list>, the config menu for edit the elogd.cfg stops 

are you logged
if you have a guest menu there is no access in the admin
access is restricted with 
Admin user = 'your login name' 
in Global section



> working, yet if I change the URL manually, I can still get to the file 
and 
> the menus do not change.  If I delete all menu commands, then all works 
> without errors, yet the menus do not match default.
> 
> Also, the self registration function equal to 3 does not always send 
email.

it is send to the admin user list
be sure that smtp parameter is ok

> 
> Cheers,
> Roberto

> When you take the elogd.cfg file and the menu commands = <list> and guest 
> menu commands = <list>, the config menu for edit the elogd.cfg stops 
> working, yet if I change the URL manually, I can still get to the file and 
> the menus do not change.  If I delete all menu commands, then all works 
> without errors, yet the menus do not match default.

There was a recent bug which made "Edit elog.cfg" stop working if the 
language is not English. This has been fixed and the update is in CVS. If 
you use English, this might be another problem. Can you send me your 
complete elogd.cfg so I can try to reproduce your problem?

> Also, the self registration function equal to 3 does not always send email.

"Not always" is hard to understand. Either it works or it does not for a 
certain configuration. What you can do is start elogd with the "-v" flag, 
which outputs all communication to the console window. Among this 
information, you have the communication with the SMTP server when sending an 
email. Maybe you see some problem there which only sometimes occurs (like 
wrong email addresses or so...)

> When you take the elogd.cfg file and the menu commands = <list> and guest 
> menu commands = <list>, the config menu for edit the elogd.cfg stops 
> working, yet if I change the URL manually, I can still get to the file and 
> the menus do not change.  If I delete all menu commands, then all works 
> without errors, yet the menus do not match default.

Has just been fixed. Available under CVS and soon in 2.3.8.

Ive just been alerted to a bug with email notifications in Elog.

Basically if your log book contains a space then the URL that is sent in 
emails when creating tickets or updating old entries doesnt put %20 (IEs 
space) inthe URL it leaves a space hense breaking the link.

for example

Correct Way prior to 2.3.8

http://192.168.0.1:99/Provisioning%20Request/35

Broken way with new version

http://192.168.0.1:99/Provisioning Request/35
                                 ^
Link is broken at this point

My config looks like this

Email Status Assigned = $Owner@abc.co.uk
Email Status Re-Assigned = $Owner@abc.co.uk
Email Status Completed = $Requester@abc.co.uk
Email "Send Update Email" Yes = $Requester@abc.co.uk
Use Email Subject = A Provisioning Ticket has been assigned to you or 
completed
Use Email From = NetworkTeam@abc.co.uk

> Correct Way prior to 2.3.8
> 
> http://192.168.0.1:99/Provisioning%20Request/35
> 
> Broken way with new version
> 
> http://192.168.0.1:99/Provisioning Request/35

Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
that you mixed up these two versions? To be precise, the fix happend in 
Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
version of elogd after that modification? I tried to reproduce your problem 
with the official 2.3.8 version, but I got the correct result.

> > Correct Way prior to 2.3.8
> > 
> > http://192.168.0.1:99/Provisioning%20Request/35
> > 
> > Broken way with new version
> > 
> > http://192.168.0.1:99/Provisioning Request/35
> 
> Exactly this problem has been fixed between 2.3.7 and 2.3.8, so can it be 
> that you mixed up these two versions? To be precise, the fix happend in 
> Revision 1.113 from 2003/06/04 08:17:35. So are you sure that you use a 
> version of elogd after that modification? I tried to reproduce your 
problem 
> with the official 2.3.8 version, but I got the correct result.

Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
upgrade, the only thing I kept was my own stylesheets and the config file.

One thing I just noticed is that if you dont have the URL statement set 
under global properties, some machines quote the hostname of the machine at 
which point this breaks the link. if you define the URL to the IP address 
the problem goes away.

However even without the URL setting undefined, it works for some people 
but not for others, I tried from 2 seperate machines and got 2 lots of 
results, so I suspect it might be DNS related somewhere along the lines.

> Im using the plain RPM from 2.3.8, i uninstalled the 2.3.7 RPM before this 
> upgrade, the only thing I kept was my own stylesheets and the config file.
> 
> One thing I just noticed is that if you dont have the URL statement set 
> under global properties, some machines quote the hostname of the machine at 
> which point this breaks the link. if you define the URL to the IP address 
> the problem goes away.
> 
> However even without the URL setting undefined, it works for some people 
> but not for others, I tried from 2 seperate machines and got 2 lots of 
> results, so I suspect it might be DNS related somewhere along the lines.

The only place I can see this problem could arise from is the "Referer:" 
statement in the HTTP header. This is sent by the browser to elogd, so if the 
included URL contains a blank, this could cause the problem in case no "URL" 
statement is present in elogd.cfg. Can you please run "elogd -v" to see the 
communication betwen elogd and your browser and check this? Maybe it depends 
from the browser, or even from the history of previous accesses. If you 
confirm that the "Referer:" statement contains blanks, I can put in a fix.