I noticed a behavior that might be irritating. 

After attaching/uploading files to an entry and before submitting it, one might press 'Back' or close the browser window.

This in effect cancels the entry and sends into oblivion. HOWEVER the attachments and their thumbnail files remain on the server forever.

Would there be a way to either delete attachments after some time if they don't show up in an entry? Or some other magic trick with the browser? My logbook directories are already full of orphan files that I need to seek and destroy.

Also, any thoughts on automatically cleaning up a logbook directory when the damage is done?

Louis

How about this:

Whenever a new file is uploaded, it would first be stored in a temporary directory. When the entry gets submitted, the files would be moved to the logbook directory and the entry edited accordingly.

Any wrongfully stored file would remain in that temp dir. Starting/restarting the daemon would cleanup that directory. Seems like a simpler approach and does not involve scripting the browser.

Since you used the -a switch for ls, the current directory '.' i.e. work/ is included in the list. I have the same kind of output. No worries.

Are you experiencing problems with ELOG?

 Hi,

I am experiencing repeated crashing of the elog daemon.

If I go into select mode while in threaded view, I can select an entire thread by selecting the top entry.

When I do so then press the Edit button, the server crashes.

I have to manually restart it. Syslog shows no error.

This does not happen under Summary or Full view.

Running Ubuntu 12.04, ELOG 2.9.2-2455

I can provide my elog.cfg if necessary.

Cheers!

Louis

P.S. i just crashed the forums ELOG following those same steps!! Sorry!! At least it was restarted in no time.

The Debian init script contributed here has been working quite well for me for the last few Ubuntu versions. Unless you edit it, it sets the elog base directory to /etc  so that's where you have to put your themes dir, resources, .conf file, scripts, logbooks, etc. I use symlinks to actually store my logbooks elsewhere.

I would also vote for a sane deb package. Right now, when I upgrade ELOG, I don't even run make install, I just copy the compiled binaries to their respective directories (/usr/bin or /usr/sbin). The rest stays the same.

We want to develop separate mobile web pages for the web applications deployed at CSNS accelerator, including the PSI Elog.

In Elog, is there RESTful API or HTTP/JSON or HTTP/XML interface for other web clients to access?

Or is there any workaround?

When using the Webserver authentication in combination with "File" and "Self register = 3", it is possible to keep track of registrations and control access still. This is very useful, and upon clicking on the logbook for the first time, the user is asked to register by typing their username, full name and email address.

First issue here is that they can still edit the box with their username, which might cause confusion if somebody decides to choose a different username and is then surprised about why they cannot automatically login again. Is it possible to lock this field from being edited?

The second issue is more minor, but the user has to manually type their name and email address, even though the webserver may already be able to provide this information in the headers. Specifically, it would be useful to read the name from the X-Forwarded-Name header and email address from the X-Forwarded-Email header. 

My config file snippet is below:

Authentication = Webserver, File
allow password change = 0
Password file = webserver.passwords
Self register    = 3
 

Hello. We are using explicity subdir names on our elog server to manage a large number of "Top groups" and sub "groups". When we create a new logbook from a template in the same group, it would be beneficial to automatically give a new subdir based on the previous one. At the very least, it should not reuse the same parameter as the template (see below).

At the moment, it copies the subdir parameter from the template logbook, which results in the new logbook writing to the same location as the template. That is very confusing and has the potential to be harmful as people can (and recently did) decide to delete these "duplicate" entries. But they are not duplicates, they are the exact same entries as the template logbook and deleting them removes them forever!

The way around this at the moment is to manually update the subdir after copying, but then the logbooks need to be re-indexed before the new logbook will display correctly. That requires a manual restart of the elogd process, which is less than ideal.