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

> > Hi all, 
> > 
> > Is it just my system or do others have this odd issue.
> > 
> > I have a pdf file which is 'upside-down', I attached it to an elog entry, and the .png image thumbnail was
> > generated.  Now this too was upside-down, so I tried to use the left (or right) rotation buttons along the top
> > of the image in elog to do a 180 degree rotation.
> > The first 90 degree rotation was fine, but the second attempt just made a smaller image.  
> > It happens with various pdf files generated by various software (in case).
> > I also tried it with a jpg file, in that case the second attempt enlarged the image.
> > 
> > I could not find any way to actually invert the .png image using elog; but I was surprised that a second
> > rotation ddid something different (change magnification) rather than nothing at all if it could only cope with a
> > 90 degree rotation.
> > 
> > It's not a vital fix for me, but I have found the thumbnail (png) manipulation functions have a few rough edges,
> > so when necessary I use xv or gimp on the .png file to get what I want.
> > 
> > Or is this just my system?
> 
> I just tried on the demo logbook:
> 
> https://midas.psi.ch/elogs/Linux+Demo/14
> 
> and it worked fine in rotating the image twice. Can you try yourself and find out if it's related to your installation if ImageMagic, or the actual image file?
> 
> /Stefan

Hi Stefan,

Well I didn't crash the server this time, and I could invert the image in the demo logbook by doing two rotations.
But, this is elog v2.9.0-2435, and I am using v2.9.2-2475.  And I remember there was a recent issue about the image manipulation at some point, so I went to the
download section to read the subversion listing to find where this occurred.  But you've changed subversion!  I couldn't find my way around it, so I not only could
I find the changefile that showed what happened for each subversion issue, but even how I could download the current (or indeed any past) subversion issue.

As far as I can recall, you made a change, I reported an issue, and you undid the change, or partially undid it.  Do you know when this was?  Could it be relivent?

 It's probably not of much help, but for a short time I ran two elog daemons on the same linux box, using different ports.  It was thus able to run with two separate elogd.cfg files.   This is linux, and heavily biased to my eccentric way of running this linux box, but started them as:

/usr/local/sbin/elogd -p 8080 -c /home/logbooks1/elogd1.cfg -d /home/logbooks1

/usr/local/sbin/elogd -p 8081 -c /home/logbooks2/elogd2.cfg -d /home/logbooks2

Do note that as I was the only user on that linux box, I didn't have login etc.

However, I was soon asked questions by Andreas as to how I found this running, as he had encountered problems with an earlier version.  To be honest, that stopped me experimenting too far with this at that point, as well as a coincidental upgrading of my hardware.

But I was doing this *not* because I had to run two separate elogd.cfg files, but other reasons which meant splitting into two at that time vastly improved the performance of elog on the linux box at that time.  So while I didn't actually enounter any problems in doing so, I only have limited experience - and, of course, absolutely none on running even one [windows equivalent of a daemon] on Windows.

I am assuming here you have good reason for two separate elogd.cfg files, rather than just wanting to run two separate logbooks - guessing here, but one set public (no login) and one set private (with login)?

 

 Please add my vote for this on the wishlist.

 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!

Ryan Blakeslee wrote:

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!  :-)

Hi Ryan,

Glad you've got your solution.   Sadly, won't work for me, as my 'catching up' is often as replies to some existing threads, rather than just the need to have the day's work under the day's date.  But useful to know for the future.

As for the computer time switching, I am aware of the issues, it's a stand-alone linux box, I've found elog to be surprisingly tolerant, everything's backed up.  The introduction of a 'When' attribute had better be on new logbooks or introduced at end of year (esp during quiet time) so that existing books don't fail to find what I'm looking for in searches.

As for ascii coding the yymmdda.log file, and the infinate loops, been there, got the tee-shirt.  In all bar one case I've found and corrected the problem, although in one case I became convinced it had to be a 'hidden' character because deleteing and retyping the entry letter by letter cured the issue.

By default, elog enties are sorted by their ID number.  When viewing a logbook in Full or Summary, they are
shown in strict order of ID.  In Threaded, entries are shown in strict order of ID for the latest entry of each
thread, and then previous entries (in reply to) back from the latest one.  

In collapsed mode, it is only the starting entry of each thread is shown (or the latest one if "collapse to
last" chosen, but that's a detail).

I have a couple of logbooks where I'd like the default sorting to be by another numeric attribute that I enter. 

Now this works fine in Full or Summary mode.  In threaded mode (e.g. default for this forum, where every entry
is shown but are grouped by thread), it works in as much as all the entres are there and in order, but it
doesn't quite look the same as when sorting by ID - the replies are not each offset further right beneath the
entry it is in reply to, but all just slightly offset to the first entry.  

If you try to [completely] collapse the threaded mode to just one line per threaded topic - it doesn't.  Looks
(almost) the same as threaded.

I was hoping to get the list of entries collapsed to one line per thread, in order of the numeric attribute, but
I cannot seem to get this to happen.   Have I missed something here?  Or is it possible at all?

> > By default, elog enties are sorted by their ID number.  When viewing a logbook in Full or Summary, they are
> > shown in strict order of ID.  In Threaded, entries are shown in strict order of ID for the latest entry of each
> > thread, and then previous entries (in reply to) back from the latest one.  
> > 
> > In collapsed mode, it is only the starting entry of each thread is shown (or the latest one if "collapse to
> > last" chosen, but that's a detail).
> > 
> > I have a couple of logbooks where I'd like the default sorting to be by another numeric attribute that I enter. 
> > 
> > Now this works fine in Full or Summary mode.  In threaded mode (e.g. default for this forum, where every entry
> > is shown but are grouped by thread), it works in as much as all the entres are there and in order, but it
> > doesn't quite look the same as when sorting by ID - the replies are not each offset further right beneath the
> > entry it is in reply to, but all just slightly offset to the first entry.  
> > 
> > If you try to [completely] collapse the threaded mode to just one line per threaded topic - it doesn't.  Looks
> > (almost) the same as threaded.
> > 
> > I was hoping to get the list of entries collapsed to one line per thread, in order of the numeric attribute, but
> > I cannot seem to get this to happen.   Have I missed something here?  Or is it possible at all?
> 
> This is not possible at the moment, but I will add it to the wish list.

OK, Thanks Stefan.