Automatic Export, posted by Tim Fowler on Thu Jan 27 19:09:55 2005
|
Is there any way to automatically export the logbook(s)? |
Automatic Copy to , posted by Chris Warner on Fri Jan 13 13:16:25 2006
|
Is it possible to configure elog to copy a new entry from 1 logbook to another? |
Auto-refresh ELog display, posted by Alan Stone on Thu Aug 24 15:52:54 2006
|
We have multiple LCDs at a console, and usually one is dedicated to displaying a browser
with the local ELog. Meanwhile, others are making entries from another machine. If
no one clicks on refresh, the ELog display becomes stale. Is there a method to have
the ELog reload every X minutes?
Thanks, Alan |
Auto-increment substitutions broken with records for multiple days, posted by Richard Stamper on Wed Jun 24 15:02:49 2009
|
With a logbook defined by
[test]
Theme = default
Comment = Test of auto-increment
Attributes = Batch
Subst Batch = %Y%m%d-##
the auto-incrementing of the Batch attribute within dates works when the logbook contains only entries for
today's date but otherwise will give a batch number of "01" for each entry.
Changing line 8714 of elogd.c as follows, from:
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
old_index = 0;
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
to
/* if date part changed, start over with index */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) != 0)
break; /* <------------- */
else
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
appears to fix this bug when I test it. This code is inside a loop stepping back through all log entries, and
the variable old_index is already set to zero before the loop. The existing code resets old_index whenever the
prefix of the attribute string (containing a date) does not match the "current" value of that prefix as found in
retstr (set using strftime). So, if there are any records for dates other than today then old_index is reset
and attribute values will be set with the counter = (old_index+1) = 1. The modified version stops comparisons
once a different date is seen, but assumes that records are date ordered. An alternative patch:
/* if date part matches */
if (strlen(attrib[index]) > 0 && strncmp(attrib[index], retstr, loc) == 0)
/* retrieve old index */
if (atoi(attrib[index] + loc) > old_index)
old_index = atoi(attrib[index] + loc);
does not make this assumption and also appears to work OK when I test it. |
Auto-increment attributes, posted by Steve Williamson on Wed Nov 26 10:00:25 2008
|
We have an auto-incrementing reference attribute defined as:
# RFC
Format RFC = 0,narrowattribname,narrowattribvalue,60,60
Preset RFC = RFC-######
Preset On Duplicate RFC = RFC-######
Tooltip RFC = A unique reference will be generated for this Request For Change
We also have a "Created by/when" attribute. Looking at the values this seems to be set when the user clicks "New" whereas the time stamp that appears on the line after the $@MID@$ seems to be set when the user clicks "Submit".
# Created
Format Created = 0,attribname,attribvalue,70,100
Preset Created = $long_name ($short_name) on $date
Preset On Duplicate Created = $long_name ($short_name) on $date
Every once in a while the incrementing stops working and the number 'sticks' or misses some out. It looks as if it might be because multiple people are adding entries concurrently. Could the occasion where there is a gap in the sequence (171-174) be where people abandoned changes (clicked on "Back") after having numbers allocated? Here is a list showing the discrepancies.
Date Item Time Stamp (from the line after $@MID@$) "Created" attribute time stamp
22/09/08 124 16:15:10 11:58
22/09/08 125 16:33:54 16:24
22/09/08 125 16:35:37 16:33 Should be 126
...
10/10/08 146 10:39:09 10:30 Correct
10/10/08 146 10:46:57 10:35 Should be 147
10/10/08 147 13:04:03 13:02 Should be 148
10/10/08 148 15:11:38 15:00 Should be 149
...
17/11/08 171 10:21 10:17 Correct
17/11/08 174 14:30 13:47 Should be 172
17/11/08 175 16:14 16:04 Should be 173
17/11/08 176 16:49 16:38 Should be 174
...
25/11/08 187 15:49:58 15:47 Correct
25/11/08 187 15:52:39 15:48 Should be 188
25/11/08 188 16:49:56 16:44 Should be 189
25/11/08 188 16:52:40 16:40 Should be 190
25/11/08 188 16:55:17 16:43 Should be 191
Let me know if you need any more information.
regards
Steve
|
Auto-Generate new logbook daily, posted by Ryan Blakeslee on Fri Apr 26 22:29:50 2013
|
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!
|
Auto-Generate new logbook daily, posted by Ryan Blakeslee on Fri Apr 26 22:29:50 2013
|
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!
|
Auto save?, posted by Daniel Roldan on Fri Jun 28 10:43:03 2013
|
Hi,
One question, is possible activate auto-save while write a new "ticket"?
Thanks very much. |
|