As a variant of what Stefan has suggested:

Perhaps a simple comment is set up as the pre-loaded reply - perhaps including date and time.  Maybe include the author's name in the comment, but all that is available anyway (see documentation for that).  This bit isn't vital.

Then each user simply has to *reply* to the message concerned, and you then get the list of who has read it, available in threaded view of the comment and replies.

Of course this works best with small numbers of users, and where threads are never very long.  Also, it means that you can lock the original message (prevent it being edited) which may be a particular concern depending on what you are using elog for.

You might also want to define an attribute that a reader can tick to say that they have taken action if it is important that someone has to take further action (as opposed to just reading) - and maybe that changes the colour of the background or the icon in front of the topic.  Then there would be a record as to who has done the necessary, and later readers will know the matter is for information rather than needing attention.   For example,. who kicked the power supply to the ion source on Monday morning to "wake it up" (this is true, but pre-elog, so was a paper record).  John kicked it last Monday, and the power supply respects John, may be a statistic one could find from such information recorded as suggested here.

You may want a second attribute people have to explicity select so as to show they understand what they've read, rather than just reply/submit without having read... e.g. they have to select a digit of the ticket number, or some auto-generated number (or letter, I'm not characterist) that is within the original comment.

We all know people who click on things they've never read, and come on, we've all done it at times...

David.

Hi Alan,

I have no idea if this helps but the Date and Time formats in the config file internally interconnect, as I discovered in trying to define them separately.  Define one, and the other is defined.

I only mention this as I spent some hours trying to sort out the issue, only to learn it was a "feature" that Stefan didn't want to correct as it may affect too many others.  I can understand that, and made a different solution to what I wanted to do.

I've seen exact;y this effect, even though I have branching = 0 in my config file - so ordinarily no chance to have two
 replies to an entry.  My pointer aka mouse (I'm on Linux) is a bit dodgy, and sometimes disconnects/reconnects, so in effect gives a very fast double click.  I've always assumed that was the cause of the problem.  The two replies have incremental IDs, and both those IDs are listed in the "Reply to" header section of the entry.  I'm not sure how this overcomes the branching = 0 detail, though.

That is what I have assumed, but if others see this on occasion, perhaps it's got a different cause.

I don't know if you can get elog to generate a log file - check the documentation, I don't bother.  But I do have some experience with this matter.

There are two related circumstances I know of that can arise which will cause elog to crash.

As you are probably aware, the entries are threaded.  I find the main problem is if you move a long thread - I forget the number but over 30 entries - from one log book to another, it will copy across fine, but the deletion of the thread from the source logbook will crash elog *before* the entire thread has been deleted: cause 1.

If you then restart elog, and happen to access the partially deleted thread, elog will run into a loop.  You won't be able to access elog, and you will see it is burning up CPU time, and it probably will eventually crash, but normally I find what the process number is and kill it (with "kill -9 [process no]").  This is cause 2.  The reason is that elog is looking for an entry number in the thread that no longer exists (because elog has already deleted it).

There is a moderately convoluted way I have devised to completely delete the partially deleted thread, needing access to the yymmdda.log files.  Cause 2 can also occur if someone manually edits yymmdda.log files with insufficient care (that includes me on occasion).  

Hi,

First up, the Copy command is supposed to be used to copy to another log book, as it says in the documentation, not a duplicate entry in the same logbook.  I've tried doing a copy into the same logbook, it appears to work (although I don't know about every circumstance, I just did a quick and dirty test).  Use at your own risk!  Don't use Preserve ID feature is one caution I would raise immediately.

As for renaming the command, I'd suggest defining a new language, "lenglish" or whatever, make all the files necessary as per any normal language; in the eloglang.lenglish file would be

New = New

Edit = Modify

---

Copy to = Duplicate

and so on.  I chose to call my eloglang "lenglish" as duplicate, modify etc as used in the example here derive from Latin, but other commands would still be English.

When specified in the config file (just like the languages that "come with the box") that should give you the alternative names for the commands.

David.

So did I [thankful there is no shame face icon].

Menu commands = List, New, Edit, Delete, Reply, Duplicate, Find, Config, Help

I have experience of elog hanging (under linux).  I'll describe my situation, although it may not apply to you.  I still use elog 2.9.2 but I am unaware of this issue ever being resolved although I have mentioned it in the past.  (Possibly because I'm one of the few who has this situation).  I certainly recall other person had this as the problem, and my reply on this forum solved their problem.  The cause is the following:

1.  A thread with a large number of replies - something over 40 I think.

2.  This long thread is deleted from the first entry.  This will crash elog,

3.  Once restarted, the later entries of the deleted thread (which survived the deletion attempt when elog crashed) are accessed.  This will cause elog to go into an endless loop and hang.  Until I learnt better, I had to reboot the computer.  Under linux kill -9 (process) does the job, but kill (process) does not.

The problem lays with the first entry that survived the attempt at deletion.  It has an "In reply to" line in the entry in the yymmdda.log file, referring to an entry that has now been deleted.  Manually editing the yymmdda.log file to remove that line does the trick, and then the surviving entries can be accessed and deleted.

A good work-around is that if you are about to delete a long thread is to delete it in sections, starting at the end.  It is useful to note the entry number or some other way to find it again after the last section is deleted, as of course it will now be back in with the even older entries.  Or have two tabs on your browser accessing the same thread.

If you want to move the long thread to another logbook, to avoid the problem, Copy the thread, and then do the deletion in stages.  Moving a long thread does the same computer crash/computer hang, although the Copying part is done fine, the deletion part is the problem.

You don't have to have a large number of replies to an entry to cause the hang in controlled conditions.  Just edit the yymmdda.log file of a new entry adding in a "In reply to" line referring to an earlier entry number that does not exist is enough to cause the problem when you try and access the thread.

If this is the cause of your issue, the problem is to find the orphan thread that is causing the hang, especially after all this time.  Also, you may have more than one orphan thread.  Even though I am aware of the problem, I do occasionally find orphan threads in my logbooks.  In my case I use the ticketing system, and searching by ticket number will find an orphan thread without hanging the computer, but if you then click on any entry found - hang.

There is a related issue, which I think I have now resolved.  If the entry in the "Reply to" field in the yymmdda.log file does not exist, that is a later entry (not earlier, as above), elog will cause a duplicate entry, always in bold, with entry no 0 to appear in the listings.  This entry is an artifact that appears in the listings, not a real entry in a yymmdda.log file.  Again, finding the rogue entry is the tricky bit.

Hi Alan,

Just to be clear (and for others) if any entry is a reply to a previous one, such as this one is to yours, then there will be "Reply to" and "In reply to" fields in the entry as found in the yymmdda.log files.  They are automatically generated as part of the elog program's internal structure, but are only there when there is a reply - so a new entry on a new topic does not have either field (at all) until there is a reply to that entry, when the fields start to appear in the log file.

David.