Is there a way to open a form or table when clicking on New rather than going to a text field? Thanks, TS!

Hey,

the syntax for creating links to other elog entries has a small issue in the HTML editor. The link will not be created properly if there are whitespaces in the name of the logbook. Using ELCode (or in a simple attribute field) the whitespaces can be replaced by "+", but this does not work in the HTML editor. The work-around would be to use ELCode mark-up instead of HTML.

Example 1 (this should work): elog:Contributions/47

Example 2 (this will not work): elog:Config+Examples/11

Example 3 (will also not work): elog:Config%20Examples/11

Hello, Sorry if this has been addressed elsewhere, but I could not find info.

I am wanting to submit a new elog entry (that should have been) for a past date, to predate log entrys currently in my system.

I assume I must manually create a new .log file. What ID# should I assign to this entry? Should I sub-increment (i.e 33.1)? I presume the correct thing to to would be to automate ID# increments in all sucessive logs with a script (python).

Please advise.

Thank you,

-Michael Hibbard

I'm converting our on-call logbook, with 25 years of history, to elog. Is there a way to override the current date/time for the Date field with the creation date/time of the original logbook entry?

For some odd reasons, we are experiencing frequent crashes of elogd over the past few days. It has been working fine so far, but more or less out of the blue it became rather unreliable. The current configuration is installed on two servers, one running 2.7.5.-r2174 on ClarkConnect 4 and one running 2.7.6-r2233 on Debian 4.0 - both show the same problem. Each of them has an "active" group with four logbooks and an "archive" group with three logbooks. In the "active" group, there are two logbooks that share the same index (using Subdir=...) and it looks like the crashes occur most of the time in these, though that's just a hunch so far. Also, most of the crashes seem to happen when submitting an entry that has been edited. Actually, submitting a modified entry has always been strange in our logbooks: When we hit submit, we get a pop-up window asking "Submit modified entry?". When choosing "OK", the entry that has been edited is duplicated. When choosing "Cancel", it is submitted correctly.

I've been running elogd like this (to get more info)

elogd -v > elog-2233-2.log 2>&1

The last entry I get in the log when elogd crashes is:

  Same index as logbook Machine Log
elogd: src/elogd.c:727: xfree: Assertion `*((unsigned int *) (temp - 4)) == 0xdeadc0de' failed.
Received unknown cookie "wikidb_mw__session"
Received unknown cookie "wikidb_mw__session"

I did actually make a few changes to the configuration before we noticed the crashes: I added one extra attribute and a few more conditionals.

Any additional information you need: Just let me know.

Regards,

Thomas

Hi All,

I found that elog crashes if I try to upload an image with long name. It actually uploads the file after the crash. It crashes also if in the full view with attachments visible. If I shorten the name all is fine.

The crash report screenshot is attached. It looks like a too small buffer (?).

Using 2.5.8, if I set "Protect Selection page" to 1, then elogd seg faults
as soon as it is accessed.

Under 2.5.7, a login page will come up, and the logbook will work, but only
if a valid username/password is given.  If an invalid login is given, then
elogd crashes.  We have a cron job that periodically restarts elogd if it is
has crashed.

Steve

[global]
logbook tabs = 0
port = 8080
Protect Selection page = 1
Password file = user.info
Admin user = saw
 

Using Elog 2.9.2

Elog crashes when making 10 replies, I narrowed the crash down to the Propagate Attributes setting.

I have an attribute "Status" that can be toggled between "Open" and "Closed" and that propagates all replies.  On the 10th reply the application crashed, this is repeatable 100% of the time.  Without the propagate option everything works fine.

Attached is my config file parsed down.

Is there a way around this, or is there a way on reply to change the attribute of the log note you replied to from open to closed without using the propagate option?