As a regular elog (ab)user, I have seen this behaviour from time to time. So far as I recall, the cause actually is that a normal entry is looking for the entry in the "Reply to" field of the normal entry in the yymmdda.log file. When that entry does not exist, then I see a duplicate line of an entry with entry "#0", in emboldened black type. I did have a screenshot, but cannot find it for now.
A quick (relative term, that) search usually finds the entry which references the missing "Reply to" line, and editing that, all is well. I'm not sure how this can happen, but it does. NB, I'm still on elog 2.9.2 so I don't know how the draft facility works and possibly enhances the possibility of this issue.
Note that this is different to the case (rather more frequent) where the entry in the "In reply to" field is missing. This causes elog to go into a continuous loop and only the strongest measures ("kill -9 xxxx in linux) will break this out. This can happen more frequently as if you delete a thread with a large number (>40?) of entries, elog crashes, but more importantly, hasn't finished the job. Clicking on the remenents of the thread (which are usually the later entries) causes the endless loop.
Andreas Luedeke wrote: |
It looks like you've found a bug in ELOG. I've checked my elog.log and see that all NEW entry lines show "#0".
I've looked into the code: the message is written before the new entry is submitted, and only then the entry ID is defined.
For new entries one would need to make the logging print line later - but that would blow up the code.
The message IDs are correct for saving drafts and editing entries. I'll discuss with Stefan if that should be fixed.
Andreas
Sergio Navarrete wrote: |
I have configured a logbook with the logfile on, but when a user replies to an entry the line logged goes
Date Time [User@IP] {Logbook} NEW entry #0
How can I make the #0 be the real entry number for the reply?
|
|
|