I copied the following line from the ELOG documentation file to my config file (with the appropriate changes to the attribute and value fields) and nothing happens. Am I missing something?

Style importance severe = background-color:red

Thanks for all your help.

Style importance severe = background-color:red

Thanks for all your help.

 Just the "usual candidates":

• Any typo?
• Edited the wrong file?
• Must send a HUP signal to elogd if running under linux
• Note that the style changes only in the list display

I just tried with a minimal configuration file:

[demo]
Attributes = Author, Importance, Subject
Options Importance = normal, severe
Style Importance severe = background-color:red

and it just worked fine:

I want to know if there were some way to insert a screen shot directly into the log book instead of going through the "save-attach" procedure. i.e. add some plug in button to do this under Linux?

Or, can I just make a plain log file "xxxx.log" and put it into the directory? Will that work?

Thanks

You cannot directly paste a screen shot into an elog entry. Use HoverSnap (Windows) or ksnapshot (linux) to produce directly an image file, then you need only two mouse clicks (browse and select file). There is also an Add-On for FireFox called "dragdropupload" which can be used for drag-and-drop a file into the attachment file selector. 

 I see. But what I want to do now is writing a script to make a elog entry, is that possible? I mean, I don't know if the log entry I generated could be recognized by elog.  e.g. the following text is generated by me, no through elog, is there a way to let them shown on elog?

Date: Mon, 01 Dec 2008 18:45:21 -0500
Author: Anonymous
Author Email: $user_email
Category: Shift summary
Subject: test
Attachment: 081201_184113_bigcal_014.jpg
Encoding: HTML
========================================
test
 

 For what you need you can use the "elog" utility, as described in https://midas.psi.ch/elog/userguide.html at the bottom. Using the "-f" option you can add attachments there.

 Got it! This is exactly what I need, thanks a lot!

Hello,

I just upgraded to elog 2.7.5 from 2.6.4 on my Debian system. Here is some feedback:

1) "make" fails if libssl-dev package is not installed. Documentation does not mention SSL library requirements.

2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
out that line).

3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
to "echo ").


Hope this helps.

George.

> 1) "make" fails if libssl-dev package is not installed. Documentation does not mention SSL library requirements.

I added a note to the documentation, thank you.

> 2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
> out that line).
> 
> 3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
> to "echo ").

The elogd (or elogd.init in the distribution) is written for RedHat based systems where echo_success gives the 
typical output with a green [OK] at the end of the line. For Debian, there is (was) in principle a Debian package 
which has it's own startup script. Since the package maintainer is not active any more (I guess), the Debian 
updates are heavily old. Once elog gets managed inside Debian again, that should get better again, but until then 
one has to follow 2) and 3) from above. If I would remove it, the Scientific Linux users would complain. 

> The elogd (or elogd.init in the distribution) is written for RedHat based systems where echo_success gives the 
> typical output with a green [OK] at the end of the line. For Debian, there is (was) in principle a Debian package 
> which has it's own startup script. Since the package maintainer is not active any more (I guess), the Debian 
> updates are heavily old. Once elog gets managed inside Debian again, that should get better again, but until then 
> one has to follow 2) and 3) from above. If I would remove it, the Scientific Linux users would complain. 

That makes sense. Might be worth adding a short Debian section to the installation instructions page?

FYI, Elog is no longer in Debian as of 2008-05-12.


Thanks,

George.

> > 2) /etc/init.d/elogd: line 10: /etc/rc.d/init.d/functions: No such file or directory (I fixed this by commenting
> > out that line).
> > 
> > 3) Starting elogd: /etc/init.d/elogd: line 34: echo_success: command not found (Fixed by search/replace "echo_"
> > to "echo ").
> 
> The elogd (or elogd.init in the distribution) is written for RedHat based systems where echo_success gives the 
> typical output with a green [OK] at the end of the line. For Debian, there is (was) in principle a Debian package 
> which has it's own startup script. Since the package maintainer is not active any more (I guess), the Debian 
> updates are heavily old. Once elog gets managed inside Debian again, that should get better again, but until then 
> one has to follow 2) and 3) from above. If I would remove it, the Scientific Linux users would complain. 

I'm actually using elog on Debian and have been rolling my own ".deb" for a while now (starting with the old Debian
one and working my way up till 2.7.5). Maybe you could add the Debian /etc/init.d/elog script to the "contrib"
directory, with a suitable note in the README or something like that? That script has not changed in a long time and
is still functional - and doing so would make it easier for people who would like to install elog on a Debian (or
Debian-based, e.g. Ubuntu) system. I'll attach the script.

Regards,

Thomas

	reload)
		# Do nothing since ELOG daemon responds to 
		# the changes in conffile directly.
		;;

    reload)
        if [ -f $PIDFILE ]; then
            echo -n "$DESC to reread config file ... "
            kill -HUP `cat "$PIDFILE"`
            echo "done"
        else
            echo "No $PIDFILE found!"
        fi
        ;;

> I'm actually using elog on Debian and have been rolling my own ".deb" for a while now (starting with the old 
Debian
> Maybe you could add the Debian /etc/init.d/elog script to the "contrib"
> directory, with a suitable note in the README or something like that? That script has not changed in a long 
time and
> is still functional - and doing so would make it easier for people who would like to install elog on a Debian 
(or
> Debian-based, e.g. Ubuntu) system. I'll attach the script.

The problem is not putting this into the "conrib" area, but supporting it. Since I don't have a Debian system, 
may I suggest that you put it yourself into the elog:Contributions/ logbook. If people then get problems in the 
future, they can contact you directly ;-)

> The problem is not putting this into the "conrib" area, but supporting it. Since I don't have a Debian system, 
> may I suggest that you put it yourself into the elog:Contributions/ logbook. If people then get problems in the 
> future, they can contact you directly ;-)

I finally got round to do so. I've also included the changes suggested by Yoshio Imai (reload functionality).
Hopefully, it is useful for someone...

I just ran into the following bug:

I have a logbook where entries have several attributes, among which several dates. All of these are set to "Type <attr> = date". If I use the "Select" action, tag several entries and subsequently chose "Edit", the values of all date attributes are wiped. All other attributes are kept at their original values, unless changed explicitly. For the date entries, the date choosers are shown (as when editing a single entry), but all set to blank.

Editing single entries works fine.

 This problem has been fixed in revision 2.7.5-2143. Please upgrade.

 Yup, this works now - thanks a mil!

I am tring to sort  the attribute, subject, but it sorts with Z on top and A on the bottom. Is there anyway to reverse sort?

 Sorry, to bother you. Solved my own problem   " Reverse sort = 0"

I would like to export several entries out of a logbook I have with a specific subject. 

I need to send these entries to someone who does not have elog nor can they install it.

Is there a way to do this?

Thanks,

Bill

 Yes. Go to the "find" page, select your subject, check "CSV", "XML" or "RAW" and click on search.

 Thanks for the information, looks like the csv options don't export the actual entry.  I'll have to play with the other formats they look like html.

Hi

Thanks for elog - it's a brilliant piece of software.  I'd looked all over for open source software to log/manage change requests before discovering elog; it's so flexible that I've been able to do everything I need with it.

However, I think that I've just discovered my first undocumented 'feature'.  Attribute names containing punctuation characters (e.g. / and :) cause "Redirection limit for this URL exceeded" errors in Firefox 3.0.2 and corrupt the URL if they're used in a Quick Filter.  I often use '/' in attribute names for brevity, e.g. "Old/New Versions" but hadn't used one in a Quick Filter before.

keep up the good work.

regards

Steve

Quick answer: Don't use '/' in attribute names ;-) but I guess you were kind of afraid to get this answer.

Somehow longer answer: I tried to reproduce your problem with following configuration:

[demo]
Attributes = Author, Type, Subject, Old/New
Options Old/New = Old, New
Quick filter = Type, Old/New

But I was not successful. Everything worked fine using ELOG V2.7.5-2137. Can you please check with the above configuration and tell me exactly when the redirection problem occurs? Is it during filtering on already on creating a new entry?

[demo]
Attributes = Author, Type, Subject, Old/New
Options Old/New = Old, New
Quick filter = Type, Old/New

 Thanks for the advice!

I've just had time to set up a test for this using both empty and populated logbooks (which don't have Hardware/Software in every entry as the field was added recently) and newly created logbooks (which have consistent attributes) and saw the problem on . 

The control ("Hardware/Software") causing the problem has three options "Hardware Only", "Software Only" and "Both".  The problem happens every time you click on the "-- Hardware/Software --" (i.e. All) option in the Quick Filter after having previously selected one (or more) of the options as a filter.  This produces the error:

The page isn't redirecting properly
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.
*   This problem can sometimes be caused by disabling or refusing to accept cookies.

I ran elog with a trace (attached) which shows lots of:

select(1024, [5], NULL, NULL, {1, 0})   = 1 (in [5], left {1, 0})
recv(5, "GET /Change_Log/?Hardware%2FSoftware=_all_ HTTP/1.1\r\nHost: localhost:8080\r\nUser-"..., 100000, 0) = 619
stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0
time(NULL)                              = 1227528904
send(5, "HTTP/1.1 302 Found\r\nServer: ELOG HTTP 2.7.5-2130\r\nConnection: Keep-Alive\r\nKeep-A"..., 199, 0) = 199
send(5, "<html>redir</html>\r\n", 20, 0) = 20

messages after selecting "-- Hardware/Software --"

The only difference between today's test and last week's is that today the browser is on the local machine.

I also attach my (anonymised) elogd.cfg

Hope this helps

regards

Steve

Thanks to your detailed description I could reproduce and fix the problem. Please download SVN revision #2144 and give it a try.

Tested SVN v 2147 and all looks OK

thanks

Steve

Can you email a thread of log entries. I think this would be a very useful function, which would enable the logger in effect to send an entire history of a particular issue to the interested parties.

 Well, kind of. If you notify yourself with elog entries, they are grouped in a thread in your email application. From there you can forward the thread to someone. Or you forward the link to one entry in the thread, and if the link is the opened, the interested parties see the whole link. Sending the whole thread inside elog is however not possible.

 Hi Stefan,

Your suggestion of emailing a link for a log entry with which any interested parties open the link are able to see the entire thread works. However, it does not display the additional text which may be added in the text box below the standard field entries. To view this additional text would require the email recipiant to log into the elog account. The only problem with this is the interested parties may not have the priviledges to log into the elog account. Thanks for your time.

 You could implemente guest read-only access to the logbook (like for this forum).