Hello,

We have a very large elog database, and executing a 'Find' on the whole range takes several minutes, locking other users out of the elog for that time. It would be very nice if there could be an option to set the default value of the 'search last ...' option on the find page. Thanks in advance!

Have you tried in the "Find" page to set a start date, or select "Show last: Month". This shoudl speed up searching quit a bit.

Yes, this works, but users inevitably forget to select "last week" or whatever, and just leave it blank, which means their search unintentionally takes a long time. It would be much better if one could configure it to default to something "fast".

Hi there, In the "Find" page, I changed the default of the "Show last" drop down box in the Entry Date section from the (unstated) "All time" to "Day", and added back in an "All Time" option at the very bottom.  This gives a default of searching the last day, and one has to think and select the period of time to search back on.

I did this on my 2.9.2-2475 version, recompiled and it works.  Two lines of code changed and even my cr*ppy coding was up to the task.  I don't know if Stefan would want to put this into the Master copy (I'll forward the changes if you want Stefan, but it's pretty easy if I can do it), but if you can edit and recompile (Eoin) I can tell you which to lines for immediate functionality.  Back up everything first, though!

It has just occurred to me that you may also have to check the non-English files, (./resorces/eloglang_xxxx) as this change introduces a new term "All time" that would need translation into the other lexicons.

By the way, in further testing, the "Show last" selection over-rides whatever two dates are selected, so if you ask for any entry in Dec 2014, but the "Show last" selects "week", nothing is found - very quickly.  I trust that is what you're after, Eoin.  I'll keep my change to the coding, but that's personal choice.

David.

I added a new optoin "Show last default = <days>", where one can pre-set the "Show last" drop-down box. I think this is a good idea, so now people can configure their elog to a certain default in this parameter. Of course all settings in the Find page are AND'ed together, so if one restricts the search to tha last week, but then looks for a date more in the past, the result will be zero by definition. The change is in the GIT repository. If you cannot recompile the code yourself, you have to wait for the next release.

This looks like exactly what I wanted, thanks!

If my coding had been up to it, I would have done this and submitted...  thanks Stefan.

Hi Stefan,

There's one pre-set value you forgot to include in this, which is the genuinely required "Show last all time".  I archive many logbooks by years, and so for the year 2005 (say), searching by anything other than all time will always bring up zero results.  And it gets annoying that the default default is "Day", the number of times I've forgotten...

I got around this by allowing a "Show last default = 0", modifying the relevent line in the block of code you modified when this was introduced to make this select "i==0", and that did the trick. 

Law of unintended consequences came into play.  If you use 0, then on the results page it says "Restricted search to last 0 Days".  So that also needs tweeking, and that's really put my c coding (or lack of it) to the test.  But I've changed that phrase to "Unrestricted search" followed by blank for when the parameter "last" is 0.

Oh, and a typo, "seach" instead of "search".

No doubt other features will show up...

Hi Andreas,

Yes, the empty string does exactly that, in the drop down menu, but before my changes, I could not set it to be the default setting in the configuration file.  In an archived logbook, it's perfectly possible for "all time" to be the only sensible value.  I tried "Show last default =  " and various other variants, with no success in getting what I actually required.  Also, in the documentation, there was no mention of a way to set the default as "all time", just a list of number of days (week (7), month (31), year (364) etc), which also led me to believe that it was not possible with the existing code.

I've sent an email to Stefan giving my coding changes for information.

Show last default = 0

always worked, even in my original code. It was just not documented. I added that.

Andreas Luedeke wrote:

Hi David, I was confused because one normally does not need to include a line in the configuration to set a default value. A default is exactly what you get if you don't specify anything in the configuration But I think I've figured it out: you were overriding the default in the global section for all logbooks and wanted to get back to the default for a particular logbook. Then another simple solution would have been to remove the line in the global section and add it just in those logbook configurations, where you actually need it. Anyway, it is good that one can now set the default in the configuration; I agree that this should always be possible. Cheers Andreas David Pilgram wrote: Hi Andreas, Yes, the empty string does exactly that, in the drop down menu, but before my changes, I could not set it to be the default setting in the configuration file.  In an archived logbook, it's perfectly possible for "all time" to be the only sensible value.  I tried "Show last default =  " and various other variants, with no success in getting what I actually required.  Also, in the documentation, there was no mention of a way to set the default as "all time", just a list of number of days (week (7), month (31), year (364) etc), which also led me to believe that it was not possible with the existing code. I've sent an email to Stefan giving my coding changes for information.

Hello, I have configuration file that already set on running logbook

but I want to change for example category and Atributes, and some other setting to match our language

If I just simply change category, or other option, when I log in on logbook, It wont show as I though. When I change back to original setting, it will show

How to change setting in configuration properly, so It will show and logbook still consistent using the new category and other option I just set.

thanx for the help

ok.

what *a.log ? is it all database from elog? so I need to open it with text editor and replace all . am I Correct?

ELOG is storing all entries as text files. Open text files and use search and replace in text editor. Or instead: export with Find and import in another ELOG with renamed attributes.

Email Downtime Yes = user1@xyz.com, user2@xyz.com

Are there any known or reported daemon stability issues with an increase of concurrent users logged in to view and search entries, while the elog client is also adding 5 to 10 new entries every minute during a peak 2-hour period each day?

By desing, there is no collision between different users, since all requests are executed in sequence (single thread). The only problem is that the server becomes unavailable for others if it executes a long search. This is why most users of large lobooks restrict their search to let's say the last month or so by default. This speeds up the search and limits the dead time for others. This can be done via the show last default = <days> directive.

We have reduced entries for Search reasons by removing older text files and that seems to speed up things. 
However, a recurring problem persists during peak period where the service connection is lost (site says "Not 
found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010 
x64 virtual server will make it available again. 

Any further info or details I can provide please advise. Thank you Stefan.

I grant that this may be a complete red herring, but your description below  - not available and having to reboot - 
might have another explanation.  At least in Linux.

I have found that if you have a broken thread, and you try to access that thread, the daemon goes into an endless
loop and
I could not kill off the daemon by normal means, but had to reboot the computer.  The daemon cannot cope with not
finding 
an entry where one is referenced by a subsequent (or previous, I assume) entry.

A broken thread can occur if you move a thread with a large number of subsequent entries - more than say 50 (I
don't know 
the precise number) from one log book to another.  The copy part of the move works, but the deleting of the entries
in the 
original log book is incomplete, leaving an orphan set of (later) entires.  Access those, and it's time for a
reboot.  Which makes 
finding them a potentially tedius and multiple rebooting exercise.  I know, because I've had to track a number in
my time.

Just a thought.

David.


> We have reduced entries for Search reasons by removing older text files and that seems to speed up things. 
> However, a recurring problem persists during peak period where the service connection is lost (site says "Not 
> found" on both client and directly on server), and it cannot be restarted or killed. Only a reboot of the 2010 
> x64 virtual server will make it available again. 
> 
> Any further info or details I can provide please advise. Thank you Stefan.

Being not able to kill a server running in an endless loop seems strange to me. If you put any program artificially into an endless loop, you can kill it via "kill -9 <pid>". Have you tried that? The only exception I 
can imagine is if there is a problem in the file system, like your elog logbooks are mounted via NFS or some other remote filesystem, and you have a problem there. Since the process might be stuck in kernel 
mode, you cannot kill it. That's why I have all my servers running on local file systems. Just another thought.

/Stefan

Is it possible to enter past date in logbook

I forgot to enter log yesterday, is it possible to add up now?

No. The date/time tag is there to actually document the time when the log was made. If you are late, you are late.

As an administrator of the logbook you could add an additional attribute, e.g. "when" of type datetime.

Each entry would then have the unchangeable entry time and an addtional time, e.g. of the event you are describing in the entry.

For more details look here: elog:67712

Hi

I am trying to install to mac 10.10.2 - everything works almost fine, but when I issue the sudo make install I get

Installing example logbook to /usr/local/elog/logbooks/demo
install: logbooks/demo/2001/011108a.log -> /usr/local/elog/logbooks/demo/2001/011108a.log
install: elogd.plist: No such file or directory
make: *** [install] Error 71

Any idea why ?

Thanks

Alex

Sorry I forgot to include the elogd.plist file in the distribution. I attached it to this entry, so just copy it into the elog root directory and run again "make install".

/Stefan

Thanks! now install works fine - but I cannot find how to open and start writing- I do

/usr/local/sbin/elogd
elogd 3.0.0 built Feb 13 2015, 16:42:32 revision 21dc563
CKeditor detected
ImageMagick detected
Indexing logbooks ... done
Server listening on port 8080 ...

but nothing pops up...I mean it is not possible to run "offline" ie locally on my mac ?

Point your browser to http://localhost:8080 as written in the documentation

Hi all,

It's possible my question is entirely within the domain of CKeditor, but I figure it may also have something to do with how it's plugged into ELOG. 

In essence, when attaching a PDF to an ELOG post as an image, the post body shows the generated thumbnail and there is a link to the full resolution PDF at the bottom of the post. 

However, if instead, I attach a JPG or PNG, the link to the full resolution image is not present in the post (though it can be accessed through the small paperclip icon).

Is there a way to show links to the thumbnailed images, or even for the thumbnail itself to be a hyperlink to the full resolution source?

Thanks for your time,

Eric Q. 

Strange. If I attach a big image to this post (see below), I see the thumbnail, but when I click on it it, I get redirected to the full resolution image. No idea why it is not working for you.

Sorry, I wasn't sufficiently clear. The issue I mentioned only applied to images that are inlined in the body of the post using the "Image" button in the CKeditor toolbar.

Oddly enough, on this logbook, I am not able to upload an image in that way; after selecting the image and pressing "Send it to the Server," nothing happens.

Since I am unable to attach an image to this logbook, I made a post over the the Linux Demo logbook showing an image that was uploaded with the CKeditor toolbar "Image" button that doesn't link to the full resolution image. 

Incidentially, Dario Milicic's recent commit to the git repository (83a10a5), adds the exact functionality I'm looking for to drag-and-drop attachments with the "dndfiles" CKeditor plugin. I've looked througe the "image2" code myself, but I don't have much experience with javascript, and haven't figure out how to do the equivalent for that plugin. 

Thanks for your time.

You make a valid point!

My perspective is from my lab's specific use case, in which we often post plots of data in the body of the text, and it is useful for the ELOG-generated thumbnails to link to the full resolution plot. In previous versions, I believe this was the behavior. It would be convenient for my users if this continued to be the case, but I understand that it is not neccesarily the appropriate default behavior for all users of ELOG. 

I put the functionality you requested into the current GIT version of ELOG. It works now with Drag & Drop, but not (yet) with the toolbar uploader.