Why do you move the last ticket in a logbook at all? The move functionality was more meant as an archive option, where you can archive old entries on an annual basis or so. If you just want to "close" a ticket for example, an attribute "Status" with options "open" and "close" will do it. Together with a quick filter you can easily show only open entries in an logbook that way.

Stefan 

 In the documentation:

>In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month >and so on. Once the date part of the attribute changes, the index restarts from one. The statement

>Subst Number = XYZ-%Y-%b-###

>results in automatically created attributes

of the form

>XYZ-2005-Oct-001
>XYZ-2005-Oct-002
>XYZ-2005-Oct-003

A little playing around with the %[Alpha character] s of strftime probably will  generate a format that will suit your requirement - to the second if needs be.

For example I've checked that

Preset Ticket = T%y%m%d%H%M%S#

Generates a ticket number T1302061705141 at that particular moment.

Unfortuately for this to work, you have to have the "#" suffix, which will add a trailling "1" at the end of every ticket (unless you generate two new entries within a second of each other).  There are plenty of ways to format all this available in strftime, and unless you keep changing the clock on your computer (which I am guilty of), the ticket numbers can be as unique as you care to make them, and sequentially increasing.

Having said that, I share the view with Stefan that the problem is moving a thread or entry to another logbook rather too early.  Personally I keep a thread in the current log book for at least a month after it is "closed" before I move it, although partly that's because sometimes these threads come back to life.  Although also because I ran into the same issue (moving the latest entry and finding the ID duplicated), and, realising the problem, then took the "wait" option to solve it..  

How can I set up the admins or manager group with the ability to Lock a Thread?  I don't wish to keep two log books.

With

allow <command> = <user list>

deny <command> = <user list>

you can prevent certain users to use certain commands (like delete a message). If you only allow admins to issue the "edit" command, that would in principle do it, but then normal users cannot edit their entries any more. Unfortunately this command cannot be restricted to certain attributes, like the thread "status". So I guess what you want is not exactly possible with the current implementation. 

 Thanks for the reply.  I was looking for a way to stop replies to a runaway thread.  Was wondering why the elog system has a "Locked by" attribute, but no way to set it.

That's a different meaning. The "Locked by" flag gets set when one user edits an entry. During the editing the entry gets "locked", which means that no one else can change it during that time. This should prevent one person to overwrite the edits of another if they are editing the same entry at the same time. Your "locking" means the locking of threads, which elog doe not "understand", it's just your definition of an attribute in your logbook. 

After installing ELOG on a new Windows 8 machine, I found everything working fine... until I went to make a new entry.   New entries work... but the FCKEditor toolbars do not show up.  I tried a variety of things (start as a service, start not as a service, run as administrator), but nothing made the toolbar appear that I coumd find.  The ELCode editor toolbar appears, but the nifty FCKEditor toobar never appears.  I could not figure out how to debug FCKEditor.  Any ideas?

Thanks for reporting that problem. Indeed the elog292-1.exe distribution has a bug in the directory structure. I fixed that in elog292-2.exe, which you can download from here:

http://midas.psi.ch/elog/download/windows/elog292-2.exe