Dear all

I installed elog from the current stable repository on Debian 8 (jessie)

The installation went on smoothly, I modified the configuration files of the Apache server as described in the manual to use the elog in parallel with an existing webserver and then I tested. The demo logbook loads fine and I see that elog created a folder for the logbook in /var/lib/elog/logbooks, which is the directory specified by default in the /etc/init.d/elog file.

Then I modified the /etc/elog.conf file, added the following lines in the global section (custompath is a local path) 

Resource dir = /<custompath>/elog/res
Logbook dir = /<custompath>/elog/logbooks

And I created a new logbook.

After restarting the elog service the second database is correctly created but both of them are still stored in  /var/lib/elog/logbooks so it seems the global configurations in the config file are overwritten.

How can I specify the custom folder so that the new logbooks are written there?

Hello,

I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.  

Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.)

1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.

2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.  

2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.

2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.

All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.

To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder.

However, I can't commit myself to always create a log entry for every day either.  Again, human error.

Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.

My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.

Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?

Thank you very much in advance!

Hello,

I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.  

Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.)

1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer.

2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.  

2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such.

2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.

All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.

To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder.

However, I can't commit myself to always create a log entry for every day either.  Again, human error.

Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end-of-day or on a day I have downtime and can commit to administrative work.

My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.

Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?

Thank you very much in advance!

Andreas Luedeke wrote:

David Pilgram wrote: Stefan Ritt wrote: Ryan Blakeslee wrote: Hello, I am currently using ELOG as a daily logbook for work performed for customers.  This is a critical tool and process for 1. Showing customers work history 2. having a searchable knowledge base for future reference.   Currently, I will create a new log entry, assign the customer using a custom ROPTION in my elog.conf.  This process all works fine, mostly, except I run into the following obstacles (that are all human related.) 1. Many days, there are no log entries to be created for a PARTICULAR customer, and other days there are no long entries to be created for ANY customer. 2. Many days when there is a log entry to be created, it's created by me much later then when the work was performed.  For example, I do a bunch of work Tuesday and Wednesday, but I don't have time to enter all my entries until Thursday.   2A. In this case, I have to manually go back and edit the log entries with text-editor to adjust the times, dates, and such. 2B. In this case, I have log files with a file-name of THURSDAY (042513a.log) for work entries done on Tues and Wed, so I have to go back and rename the log files for consistency sake (mv 042513a.log 042313a.log).  ** I know this is not a requirement of the program, but I like to have the log filenames consistent with the dates contained in them.   All these I admit are human error -- but as a small business owner, I just can't always get to the log entries every day.   To overcome this, the manual solution would: at the beginning of each day, create a new log entry -- regardless of work to be performed and updated later.  This would serve as sort of a place holder. However, I can't commit myself to always create a log entry for every day either.  Again, human error.   Is what I would like to be able to do is create a new log entry, every single day, automatically.  I would then have a growing log dir of daily log entries (files) for ever day of the week, most blank but some would then contain data that I enter later-- either at the end- of-day or on a day I have downtime and can commit to administrative work. My thought is I could probably schedule a cron job do to this, but i'm not completely sure how I would go about auto-populating the incremental ID's, dates, etc.  Second, I don't know if there is a way to do this within ELOG itself, or if there is a built-in mechanism that already covers this.   Has anyone run into this, or solved this problem, or can someone kindly point me in the right direction or how I can implement the daily auto creation of logs?   Thank you very much in advance! Actually I would not worry with the 042313a.log files. In a future version of elog they might be replaced by a database or so. I see two options: Add an attribute of date/time type. You do that with "Type <attribute> = datetime". Then you can assign a certain date or time to each entry you do. That means you can tag an entry with the date of yesterday or so. If you make that date then the main database key (via "List display") it basically replaces your "internal" date. You can do automatic entries with the "elog" utility coming with the distribution and described here. This you can even run from a cron job. If you submit a new entry from elog, you get automatically the incremented IDs etc. You can use some default values for the attributes, which you can change later.  Purists look away now. I have the same issues regarding "catching up" of entries.  So what I do is use the date command to reset the computer's time back to the time that the entry [i]should[/i] have been made.  Say I need to put an entry for last Thursday (today is Saturday 27th), Firstly I set the clock back by date 04252200 (I use a time of 22:00 or later as code for a retro-made entry, the date being the important point for me). Then any entry will have the correct time (sic) and date entry within the file, and the file the expected format of 130425a.log After Thursday's batch of entries, I then simply reset the clock for the next entry/ies or indeed back to real time. Mind you, my log files have the format yymmdda.log, whereas you state yours are mmddyya.log, which strikes me as a very high degree of flexibility!   --- Nice to meet someone else who gets down to the bare ascii and knows how to edit the xxxxxxa.log files! Just my two cent: I would strongly recomment NOT to go back and forth with the system time. In some cases this can cause you severe problems with your control system.   Stefans suggestion works fine for our operations logbook: I've just introduced an attribute "When" and sort my entries according to this attribute. The line in the config: Start page = ?rsort=When takes care that this sorting is the default.   The advantage of this approach is in addition, that you keep track of both dates: the date when the work had been performed and the date when you've actually entered the information. Sometimes that turns out to be useful to me to figure out what I did and when ;-)   As to editing the bare ascii: I do this a lot, even with sed scripts. But there is a disclaimer: you can crash elogd with corrupted entries and you may have a hard time figuring out why it crashes. For example accidentally deleting a digit in a cross reference can create a loop that causes elogd to get non-responsive without error: try to find that! I would strongly advise not to build any user application build on editing the ascii files. Just use it for system administration.   Andreas -- He who knows others is wise. He who knows himself is enlightened.                 -- Lao Tsu     Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Detect language Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish ⇄ Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latin Latvian Lithuanian Macedonian Malay Maltese Norwegian Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Detect language » English

Hello Andreas, Stephan and David,

Thank you so much for the very insightful feedback -- it's very much appreciated!

I took all of the tips and created a solution that encompasses most of the feedback, and I think it solves my problem nicely while adhering  to my desire to keep log filenames in order as well as limiting the risk with moving/renaming, etc.

1. First, I have created a cron job that runs daily at 12:01AM, which runs the following command (This will create a new entry as a place-holder at 12:01AM every day) 

CODE:

elog -h localhost -p 8080 -l Daily -a Customer=CRON -a Subject="Daily Log - System Generated" -a Hours=New -a TravelHrs="0" -a Author=CRON -a Type="System Generated" -a Status="New" -a "Locale=localhost" -v "Auto-generated log entry."  

2. Second, I added the "When" attribute, per Andreas' suggestion.

3. Last, I added the recommended sort command to my .cfg which will exclude the auto-generated logs from showing up and cluttering my view; essentially making them invisible.  I sort by type to exclude the system generated types.

Now, -- to go back in time and enter my "catch-up" data, I'll use the 'Find' in my menu, and find by type = system generated.  That will pull up all the auto-generated entries.  I'll then open whatever day(s) log(s) and edit them, chose the "when" to be the actual day the log entry is for, and enter the data.

I think this is a perfect solution - thanks so much!  PS - Nice to meet you too David -glad to know someone else out there thinks like I do!  :-)

Hello,

I've had much success and use with ELOG.  However there is one thing that I wish I could figure out in order to 
make ELOG work exactly as I need it.

When I either create a new ELOG entry, or, have one created via an automated scrip run by CRON, the paragraph 
width is preset. 

I've read the notes and experimented with setting the text size, but it seems that if I either adjust it via the 
config file, or, change the size by dragging the message box itself, then I end up with an ELOG entry that has an 
irregular message size to it than all the others.  Consistency and uniformity is very important to me for how I 
use ELOG.

It would be idea, if the log entries did not contain <CR>'s or justified lines.  In other words, I would like to 
be able to have my ELOG entry fill the width of the screen, be it a wide screen or standard portrait scree, and 
at whatever resolution and text size I have my browser set to.

By not filling the entire width (and also by not having it auto adjust depending on screen size, resolution, 
etc.) there are large portions of the screen real estate that is lost and you end up with very long, scrolling 
log entries versus entries that file the entire width and therefor take less vertical screen space.

With all that said -- Does anyone else have this issue?  And, is there anything I can do to correct this?  This 
would make me a very happy user if it could be done.

Thank you in advance!

 Hello,

I have followed the very simple steps on the Download page for checking out and compiling from GIT.  That works perfect and there is no issue.  

The problem I have is-- it is not clear to me where to put the 'elog' dir that I have after I 'make' and 'make install'.  Or, is there an installer script afterwards that I run? I'm installing on Debian 7 and trying to upgrade from 2.5.2 (which was installed using apt-get.)

Hi Andreas,

Thank you so much for the reply and info; Much appreciated!  I turned up a CentOS 6 VM and the installation, using the RPM's provided on the 'downloads' page here, worked perfectly and was very straight-forward and easy.

The D/L page includes the Debian repositories (which is how I installed on Debian in the first place) but only installed v2.5.2.  I needed to get to the newest version (ELOG V2.9.2-2455) so I can setup authentication and SSH.  (And also so that when I am reading the manuals and documentation online, provided at this site, that is makes sense to the version I am running.)  I also want to add that it seems that I am able to bring over my older 2.5.2 logbooks to 2.9.2 without any problem.  To do that, I just rsync'd the logbooks from old to new.  They seem to work just fine under the newest version.

I'm good to go.  Anyone looking for an easy deployment of ELOG, especially in a production environment, I can attest that the RPM's provided here make it very simple to deploy on Cent6.

Thanks!

I am attempting to setup an ECR (Engineering Change Review/Request) process in ELOG.

I have a logbook setup so that an original request is submitted with a status of "Approval Pending"

Options ECR Status = Approval Pending, Approved / In Progress, Completed / In QA, Closed

Once the entry is made, it is reviewed by several people who reply to the original entry and update the approval fields, adding any comments as a reply :

Options OPS Approval = Approved, Denied
Options ENG Approval = Approved, Denied
Options Director Approval = Approved, Denied

Once the final approval is obtained, they reply to the thread and update the ECR Status field to "Approved / In Progress"

This goes through our QA process, and is finaly updated with "Closed"

The problem is, I would like to keep the historical data of when the status of these entries are made. For example, in the message thread, I can see that reply #4 changed the "Status" field to "Approved". However, I can not seem to find a way for this to work with quick filtering. The quick filter always filters on the first entry on a thread, and not the last.

The other option would be to change the status of the first entry, but that seems silly as I am using replys instead of edits.

Any ideas on how to implement this "Status" field into my workflow? I am even open to losing the historical "status" and beeing able to change all entries on the thread on reply. (i.e. Reply #4 changes "Status" to "Approved", and the system changed all entries in the thread to "Approved")