I just found out that email notifications only worked for the first 50 users of this forum. So if you registered only recently, you might not have received any notification. This was a bug inside elogd which I hope to have fixed now (this entry notification will show...). If you get the first notification and do not want this, log in to the ELOG Forum, click on "Config" and remove the checkmarks from the logbooks you do not want to get notifications.

I'm (ab)using elog as a database and would like to use conditional attributes, like:

Attributes = PC Name, Operating System, Version, Distribution
Options Operating System = Linux{1}, Windows{2}
{1} Show Attributes Edit = Operating System, Distribution, PC Name
{2} Show Attributes Edit = Operating System, PC Name, Version

Problem is that there are several conditions and the list of attributes is rather long. Also, since it's a
rather dynamic environment I have to make new attributes all the time, and adding them to all "show attributes"
 lists is not only tedious, but bound to cause errors as well.
 

So... 

I was thinking, would it be an idea to make the list of attributes to be shown or hidden on a per attribute base.

 

Like:

Attributes = PC Name, Operating System, Version, Distribution

# hide specific attributes
Hide attributes = Distribution, PC Name

# or configure which fields should be shown allways
Show Attributes = Operating System, Version

# add attributes based on OS
Options Operating System = Linux{1}, Windows{2}
{1} Show Attribute Edit = Distribution
{2} Show Attribute Edit = PC Name

(just thinking out loud here).

Initially I thought you had to specify a port number after localhost for emailing.

As it turns out just putting "localhost" as the email server in the elog config

file works just fine. We have a strange problem where our elog server is running.

our outgoing mail has to be routed through port 465 and SSL. I had to set up

postfix and stunnel to handle this arrangement.

Thanks for a great piece of software - it does so much and is (mostly) so simple to use.  However, I do have a suggestion that (for me, at least) would make it even better -

I use elog for a variety of logging tasks but find that, because I want to see as complete a summary as possible, the list page can get very crowded with longer fields wrapping over several lines.  I would like to have more control over the way attributes are displayed here.  Specifically, being able to truncate data (e.g. to show just the first n characters of a description), being able to select a substring (e.g. displaying characters before the '@' character to remove the domain from an email address or displaying characters after the space to remove the day from a date in ddd dd/mm/yy format) and being able to concatenate fields (e.g. to show a reference in a single cell as "Incident 1234" by joining call type and call reference attributes).

regards

Steve

(For some reason I could not add this in Dennis's thread.)

I like this new feature, BUT

I happen to have two Options:   Options System, and Options Status.

System are a very few items, whereas Status has a long list, which, like Dennis's example, can be added to. 
Keeping the latter in alpha order is great, but it's a shame that the cost is that Options System are also
sorted alphabetically, whereas it has a natural order which it would be preferable to keep - for example (and
this is made up)

Options System: 3.1, NT, 2000, XP, Vista

where the natural order here is chronological.

Perhaps the configuration file option could be more specific, for example

Sort attribute Options Status = 1

which would then NOT sort Options System.  If both are needed to be sorted, both should be specified, or back to
the original syntax which defaults to sort *all* Options.

Hello Stefan.

Currently this is defined as a maximum of 100 literals in the cfg file. I would like to see the option to reference an external text file as input for this. 

As a side question, I would also like to increase the max to a greater value, for example, even 5000. I assume I can change the source (I recall var was something like "List_Option_Max") and see if that would still work, but would you know offhand if that would cause a problem anywhere else?

Regards,

Alan

(PS: Just getting started with ELog. Please excuse if these questions sound newbie. I also searched the Forum first but haven't found any answers to them yet.)

* Withdrawn *

The HTML layout produced by elogd is horrendous to deal with programmatically; I give up.

Hi,

I'm writing a greasemonkey script to slightly alter the look of the pages served by the ELOG server.  One difficulty that I'm struggling with is how to identify what type of page ELOG has created.  While I have several methods to determine the page type, such as a log entry vs. log entries summary, the solutions are not straight forward and not clean.  As far as I tell, there's no specific identification in HTML document currently that describes and identifies the type of page being served by the ELOG server.

So, I'm requesting that the pages created by ELOG be identified in some fashion with the META element, such as:

    <meta name="description" content="elog log entry" />

or

    <meta name="description" content="elog log summary" />

or even using the keywords attribute:

    <meta name="keywords" content="elog log summary" />

Thanks!

Internet Explorer fails to display correctly some aspects of pages generated by elog when the zoom functionality is used (Ctrl + and Ctrl -).  This is really a bug in the IE renderer rather than elog, but since IE can be persuaded to do better relatively easily it might be worth making some minor changes to make elog more robust when used with the buggy Microsoft browser.

The problem I encountered was initially with the multiple checkboxes for an Moptions attribute, but I noticed later it also affects the logbook tabs at the top of the screen.  If you start creating a submission to this forum in IE (7 or earlier, at least) you can see the problem; when zooming, the text labels and  the checkboxes do not scale together so start overlapping, and the same happens with the logbook tabs and the text links on them.  The problem is apparently to do with a proprietary IE concept called "layout" - see http://www.satzansatz.de/cssd/onhavinglayout.html for details - and IE struggles when some elements do not have the hasLayout property set to "true".

The fix is to coerce elements to have the hasLayout element set to "true" by giving them some benign CSS property.  The best I can find is to set "display: inline-block" for some of the key elements, and this can be done by modifying default.css rather than the elogd.c code.

Adding

span {
  display: inline-block;
}

to default.css (e.g. just after the default style definition for the "td" element) and adding

  display: inline-block;

to the style sets for the .sltab and .ltab classes (generic, not those specific to the "a" element) seems to prevent IE doing bad things with the display when zooming without messing up the display in Firefox.  I have not tested this comprehensively or in any other browsers, but I thought it might be worth passing on.

Cheers,

Richard Stamper