Hi Michael,

Elog purists, look away now.

There is an "official" way to do this, which is to have fields for entry date (so can be in the past), but the yymmdda.log file will be of the date and time you make the entry.  This is in the offical documentation.

If you are not bothered by the ID number being out of sequence (and elog does not really mind, although it occasionally throws a hissy fit/throws its toys out of the pram, which a restart sorts out), but you are one who wants the date of the entry in the log file to also be in the past, skipping the entry date fields issue, it's perfectly do-able.  So long as you can access the yymmdda.log files.

What I, and some others, do is to create a new entry now (for ease, the first entry of the day, but that's not critical), then go to the log files, and with an editor open today's file, find the entry, and edit the day, date and if necessary time; I always set the time as post 22:00, as code for an edited late entry.  I also then cut-and-paste the entry into the log file for the day it should have been entered in (creating it if necessary, in linux make sure the permissions are correct, specifically the user).

If you have attachments, and want those also to reflect the date, you'll need to edit the Attachments section of the elog entry headers (format is obvious), and also rename the attachment files in the directory.

I've not tried an ID number being other than an integer, I guess it would not work.  ID numbers not being in sequence with the date doesn't seem to matter.  Messing with ID numbers can have a number of consequences, such as elog running away, burning CPU time etc (looking for a previous entry that does not exist), or rogue listings of a entry ID no./# 0 (looking for a later entry that does not exist).

One caveat; I use Linux, and on elog 2.9.2.  Later elogs and Windows may have a different reaction to what I've written above.

Elog purists can now look again.

Hi all,

I try to implement a shift check list for our facility. The attributes called "a1, a2, b1, b2 etc" are used in original shiftcheck.html， However, we would like to use "1.1, 1.2, 2.1, 2.2 etc". So I try to change the name of checkbox in shiftcheck.html and the attributes in elogd.cfg file to "1.1, 1.2, 2.1, 2.2 etc". The elog web page can display the attributes like "1.1, 1.2...", but the checked value of "on" seems not working. And I have used wirshark to monitor the http package, the request message seems correct, but the service response seems can't deal with attributes like "1.1, 1.2...", so is there a way to work around?

An attribute is similar to a variable. Do you know any programming language that allows to start a variable with a digit? I don't.

The solution is very obvious: start your attributes with a letter.

Cheers, Andreas

Hi all,

There are options "Restrict edit" and "Restrict edit time" for general logbooks, but it seems not work for shiftcheck logbook. I think the function only author can change their own entry is necessary for shiftcheck too. Any suggestion would be hightly appreciated.

Cheers,

Xuan

I've been trying to configured a Synology NAS to run my personal elog with a reverse proxy to the outside world.  The best way seems to be running Elog in a Docker instance and then running a separate connected Docker running a nginx-proxy (in this case jwilder/nginx-proxy). This second container manages the certificates to letsencrypt and mapping URL requests to relevant containers so that connection is secured properly.  

It worked great in the initial test. However, I have an issue with authentication.  When I password protect the elog it goes to a login page.  When I give an correct password it loops back to the login page (incidentally when I give an incorrect password it gives an 'Invalid user name or password!' warning).  So I know that its getting the correct password but there is some issue that is resetting or ignoring the authentication.  I am never able to actually get to the protected content. 

Does anyone have any experience in using Nginx to setup a secure reverse proxy? Any insights into why this would mess with the authentication of elog?

Side note: I have tried using Apache to do the same and authentication worked fine.  But the pre-canned jwilder/nginx-proxy docker manages all the certificates automatically and seamlessly and allows me to have multiple services running on the same outward facing port on my router.  There is no equivalent (as far as I know) that uses Apache for proxying with letsencrypt​.