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 

Thank you.. that version works fine for me.

 Hi,

I have several top groups and each has several logbooks.

If I use the global option Protect Selection page=1 and Show top groups = 1, after an user logs in to the top group selection URL, the elog steers away from the top group selection page, and automatically brings him to the logbook selection page of the first top group. Is the elog programmed to exhibit this behavior?

What I would prefer is that, after an user logs in, the elog stays on the top group selection page, sine each user has his preferred destination, not always the logbooks in the first top group. Is there any setting I can use in the config file to do this? 

(My users need to access different top groups and logbooks on regular basis).

Thank you and regards.

 I am currently having a similar problem. I am migrating a few separate elogs to one new computer. I have three top groups set up with their own password files. If I log into top group A (TGA), and then try to go to top group B (TGB), I am presented with a "Create new user" screen for my login name for TGA. When I complete that form, I am taken to the user settings for top group A, rather than TGB. I can log out of TGA and then log into TGB fine, but if I try to switch between them without logging out, it freaks out.

There seems to be a problem with the cookies that keep me logged into the different top groups not recognizing that they are different entities. I'm running eLog 2.9.1 rev 436. Is it possible that this has been addressed in 2.9.2?

Thanks,

-t

Certainly 2.9.1 and 2.9.2 should behave similar in that respect. Have you tried to clear all cookies in your browser and try again?

/Stefan 

There is currently no way to change this in the config file. I will review the issue when I get some time and maybe come up with a fix. 

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. 

Hi Stefan,

I have observed following behavior when I move entries from one logbook to another:

1. The first entry in "Open" get ID "1"
2. When I move this Item to "Closed", it will keep ID "1" as I have used "Preserve IDs = 1"
3. A new entry in "Open" gets ID "1" again
4. When I move this item to "Closed" it will overwrite the previous ID "1" in "Closed"
5. A new entry in "open" gets ID "1" again....

Every new entry in "Open" will get the next higher ID Number related to the highest available ID number/entry in "Open".

Upon "move to Closed", the previous entries in "Closed"will be overwritten.

Is there a way to prevent the usage of a previously used ID Number when entering a new ID?
I.e. If an entry with ID "1" has been used in "Open" and moved to "Closed", have the next entry in "Open" use ID "2"?

Kind regards,

Barend

 Hi Barend,

The counting of entries, or even "tickets", only works within a particular logbook.  If you archive a set of entries to another [archive] logbook, the archived set disappears from view of the original logbook.  Should that entry, from logbook to archive, be the *latest* thread, then there is the danger of over-writing message ID, Ticket No and the like.

My policy to prevent the problem is to archive only threads that are say (depending upon use) a month after last entry..

I generally consider using the ID as ticket number a bad idea. The ID is the "primary key" (in terms of database language), and must be unique inside a logbook. So when moving entries between logbooks, there will be always problems.

Why don't you define an attribute "Ticket ID" and use that one? That won't change when you move the entry between logbooks:

Attributes =  Ticket ID, Subject, ...
Preset Ticket ID = ID-#####

 Hi All,

I have tried to use the "Ticket ID" approach and with each new entry this Ticket ID is indeed increased automatically...

But when the last Entry (with the highest Ticket ID i.e. ID-0009) is move to another Logbook, the Ticket ID in the next new entry will be "ID-0009" again (based upon the last previous entry "ID-0008").

So this appraoch will also re-produce duplicate Ticket IDs.

Is it possible to have the Ticket ID preset with value based upon the Date & Time of the entry? Instead of holding a Date/Time format, use a calculated numeric format?

This way, each new entry will have a truely unique Ticket ID.

Thanks & Regards, Barend 

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..  

ELog has been installed on our local server which runs on local time (UTC +8) and is working well, however, we work in two time zones.

Our PC's run in local time (IT requirement) but need to save and display one log in UTC and one log in local time - can this be done?

Appreciate anyones help!

Thanks

• define an additional logbook attribute, say "UTC Date"
  
• preset it on entry creation and submission with the UTC timestamp (cf. section "Attributes" of the ELog configuration guide):

  Preset UTC Date = $utcdate
  Subst UTC Date = $utcdate

• prevent the attribute from being changed manually by adding it to the

  Locked Attributes = < ... >

  and

  Fixed Attributes Edit = < ... >

  lists, respectively.
  You may also have to add it to the

  Remove on reply = < ... >

  list if replies turn out to keep the "UTC Date" value of the original entry.
  

I have a couple questions on how to configure multiple logbooks with groups.

1. How can I have a user have permissions to a single logbook that is within a group and jump to it using tabs?
   1. Launching from main/home screen may work, but using tabs from one group to another where the single workbook resides in a group of others, it errors out or asks for login to a logbook you may not have rights to.(always the first book in the group)
2. How can I force a main login to direct you to the MAIN logbook selection screen?

Example: (use images for reference)  A user has permissions to "Punch" and "Maintenance".  Maintenance is a single logbook and Punch is within the group "Dry Room". 

While the user is in Maintenance and without having to jump back to the MAIN selection screen, how can the user select the Tab "Dry Room" as seen in image, without throwing up or redirecting you?

There are several options:

• Use a bookmark in your browser. Put a link directly "Punch" and "Maintenance" in the link list of your browser and you can directly jump to that logbook. Different users can define different bookmarks in their browsers.
• Change the order of the logbooks in the group, like put "Punch" to be the first one in your group. But if you have different users with different permissions this will of course not work for all.
• Give up groups and just keep a linear list of logbooks. 

2. is not possible. Even if you use "Protect selection page", you will always be redirected to the first logbook after logging in. Maybe I should change that.

Updating my toolbox.  Starting to use elog as, well, a logbook.  Kind of liking the short, sweet, to the point capabilities.

Which leads me to wonder if anybody has opinions on trouble ticket systems that work well with elog?

Thanks!

Miles Fidelman

 I use elog's built-in ticketing system, and use the auto-generated ticket number to cross-reference with other matters/documents/files.  Much of the documentation for tickets is rather buried away under Subst <attribute> = <string>.

I've not found a way to link from an entry to a set of entries in another thread by their ticket number, particularly across more than one logbook.  [This is possible via their elog entry number, and which logbook it is in].  The former would be usefil to cross-reference an incident which you identify external to the elog system - "Oh, it's another one like [Ticket no] NOV12-001" possibily easier than "Oh it's another one like elog:archive12/67142 ".  Oh, the last bit should be highlighed as a (non-existant) link here, to show my point, nice of the ticket could be as well.

On the plus side, you can arrange the ticket number to show up in the thread display, quick search by ticket number, run different ticket colours (as it were) in different logbooks (i.e. different prefixes).  Just ensure you don't archive the latest entry, as that can lead to duplication of ticket numbers.

 By "ticket number" are you referring to the Message ID, or is there some additional trouble ticket functionality buried away?  And... can you point me to the documentation that's "buried away under Subst <attribute> = <string>?  Thanks!

Message ID is the internal numbering of each entry.  It is the number that is used internally for generating the threads, and which you can reference with the elog:[message ID] code within an entry to cross reference the entry with that message ID.

"Ticket" is the name of an attribute.  You define the attribute "Ticket", and can preload the attribute with the format  you require(*).  In the following extract of an elog.cfg file are the relivent lines to generate tickets, show the ticket number in the thread display, search for a particular ticket, and allow it to be edited when writing an entry - there are reasons.  The attribute "Organisation" here is an example of another attribute you would enter with the initial entry, of course there will be others specific to your requirements.

Attributes = Ticket, Organisation, ...

Preset ticket = T#####

Thread display = $Ticket: $Organisation, ...

Quick filter = Ticket, ID

When you start an new entry, the Ticket attribute is prepopulated with a number.  The first time will be T00001, subsequently it will be one higher than the currently existing highest ticket number in the logbook.

Why might you edit the ticket number?  You may wish to go back and edit an old (complete) entry's ticket number so it has some obvious name - perhaps the solution of what proves to be a stock problem, that has become known by a pet phrase, so it can be found by searching for that phrase in the quick fillter "Ticket".  That is a more advanced use of the ticket system.

 (*) Further on the format of the ticket is in the documentation under Subst <attribute> = <string>

Sorry for multiple edits, why cannot I cross-reference an entry in this forum as I can in my local logbook?

Thanks for the additional details!

 Hi,

I would like to make an hyperlink to an external file in a messaje. I have writen Allow (HTML = 1) in .cfg file and the hyperlink as

<p><a href="file:\\external_computer\directory">test</a></p>

It did not work. However if I write in the chrome browser:

file:\\external_computer\directory

It works.

Thank you so much!!

A link to a local file inside a web page does never work on purpose. Malicious web pages could otherwise get access to your local password file for example which would be a huge security hole. You have to copy the link address explicitly into your URL bar of the browser.