There are several methods to get the server time:

Via presets of attributes

Attributes = Author, Event time, ...

Preset Event time = $utcdate

which gives you actually the UTC time.

Via the editor

The editor toolbar contains a little clock. If you click on it, you insert the current server time (but localized, not UTC).

Hope one of the two methods work for you.

The problem with the conditional attributes in the find page is I believe fixed in the current version.

We've been having toruble with uploads not working and I notice that every time someone uploads to our elog the same error message appears in /var/log/syslog:

Cannot restore original GID/UID.

How can I fix thsi error? Or, perhaps more importantly, could it cause elog to "lock up" (note, it doesn't crash)?

I'm runing elog on Ubuntu kernel version 2.6.24-server.

Hi Stefan.

I have been "playing" around with this great tool and found an interesting "issue" ...

I use multiple logbooks and have both "Protect Selection page = 1" and "Expand Selection Page = 1".

When I open my elog, I get a Standard Login Screen with the Standard Bottom Text "ELOG V2.7.5-2130" which will link to your this website.

When I "Logout" and "Login" again from the Logbook page, I get another Login Screen with my own "Bottom text login" which will link to my own elog page.

How can I apply my own Bottom Text to the Standard Login Screen ?

Thanks & Regards, Barend
 

Originally, all information about our machines was stored in a spreadsheet with one sheet for the hardware of the machines and one for the software. By now, I've sucessfully moved the software part to an elog logbook and am now looking at transferring the hardware part as well.

As both lists are machine-name based, one of the options would be to merge both lists, as this would place all machine-related info into one logbook. The downside of this is that I get so many columns in list view that the result is quite unwieldy. Hence, I would like to hide some columns - ideally creating a "hardware view" and a "software view".

From the documentation, the only option I could find that seemed suitable was "List conditions". Unfortunately, I do not quite understand from the manual how this is supposed to work, so I'm quite possibly doing something wrong. I've tried this:

; General settings
List conditions = 1

; Attributes
Attributes = Type, Created, StatusA, StatusB, Archived

; Options & Tooltips
Options Type = Type1{10}, Type2{11}

; Conditionals
{10}List display = Edit, Type, Created, Status
{11}List display = Edit, Type, Created, StatusA, StatusB, Archived

but no matter how I set "Type", it does not seem to have any effect on the List display. One thing I don't understand for example is how does elog decide in List view which entry sets the condition? If all entries are set to the same value (in this example e.g. "Type1")? The first entry? Or am I missing something altogether?

Also, if there are alternative ways how I could accomplish my goal, I'd also be most grateful for suggestions.

Thanks in advance,

Thomas

Hi Stefan,

Is it possible to derive the time in a 'date/time' attribute from the Elog server?
We would like all our entries in GMT/UTC time and unfortunately as the time is currently derived from the client machines there are often entry descrepancies if the regional settings are not set correctly.

The '$entry time' variable can be used but seems to put a 1970 date in the field so bears no relevancy to an 'Event' time?

I'm also having issues with conditional entries in the Find page. If a conditional statement is used to hide attributes or change displayed attributes in the entry page then the attribute that is used in the conditional statement is not permanently selectable in the 'Find' page. It is available as a choice but as soon as selected the conditional action removes it? Is it possible to make conditional options/actions in the 'Find' page optional?

Hope that makes a little sense?

Many thanks

Dear Stefan,

Thanks for your reply.

I started running elog in February and it never failed. Then it started failing regularly towards the end of September. There were no system changes until then, except the daily automatic Yum updates (SLC4). Then I upgraded to the latest version (tar ball of 2.7.5). Then yesterday it crashed again. I saw that it crashed around the time when a user was doing something - inputting new data. I can monitor when it crashes and correlate it with user activity. But it is not easy to reproduce since I don't know exactly what the user is typing.

It would be necessary to record the user input forms and then replay them against a known server state. But that is not so easy.

I will think about doing something else - maybe running inside a debugger as you suggest.