The viewport thing and the IE7 mode thing are separate issues.

OK, maybe it's a CKEditor thing then. I thought it might be. It seems pretty stupid that the default setting in IE is to emulate an older browser - although I guess a lot of people have very outdated intranet sites. Anyway, we have a fix here so I don't think you need to do anything. Just thought you might want to know.

The viewport tag issue - see attachments. The first two are the log selection page and the list page, both without the viewport tag. Obviously you can zoom in, but this is how they appear by default, as (apparently) Chrome tries to render the whole page width. The third one is how the list page appears when the viewport tag is added, and the fourth is with my custom CSS to put the columns on separate lines. It's probably very bad CSS, so I'm certain that it's not robust or cross-platform, but it works for me :)

/* make things look a bit nicer on smaller screens */
@media (max-width: 700px) {
	table.listframe td, table.listframe th {
		display: none;
	}

	/* show id, date, personnel, summary in separate lines */
	table.listframe td:nth-of-type(-n+2), table.listframe td:nth-of-type(4), table.listframe td:nth-last-of-type(2) {
		display: block;
		border: 0px;
	}
}

The viewport thing and the IE7 mode thing are separate issues.

OK, maybe it's a CKEditor thing then. I thought it might be. It seems pretty stupid that the default setting in IE is to emulate an older browser - although I guess a lot of people have very outdated intranet sites. Anyway, we have a fix here so I don't think you need to do anything. Just thought you might want to know.

The viewport tag issue - see attachments. The first two are the log selection page and the list page, both without the viewport tag. Obviously you can zoom in, but this is how they appear by default, as (apparently) Chrome tries to render the whole page width. The third one is how the list page appears when the viewport tag is added, and the fourth is with my custom CSS to put the columns on separate lines. It's probably very bad CSS, so I'm certain that it's not robust or cross-platform, but it works for me :)

/* make things look a bit nicer on smaller screens */
@media (max-width: 700px) {
	table.listframe td, table.listframe th {
		display: none;
	}

	/* show id, date, personnel, summary in separate lines */
	table.listframe td:nth-of-type(-n+2), table.listframe td:nth-of-type(4), table.listframe td:nth-last-of-type(2) {
		display: block;
		border: 0px;
	}
}

I have had to play around with viewports for other reasons than elog, but I do have a couple of comments to make.  Obviously the meta tag viewpoint has to be added in.  Also, elog was written for large screens (no-one thought anything else was possible when elog was started), and it is relatively recent that mobile devices have become a significant percentage of views of web pages.  Google is downgrading websites that are not mobile-friendly - that is, not starting with the viewport meta tag.  So there may have to be a fair re-arrangement of the default layout of elog for it to remain sensible on mobile devices. 

The attached css file (I made minor edits to someone else's - and they were freely giving it away), allows tabs running along the top of the page (below the title) for navigation.  So it would be nice if the elog tabs could operate in the same way when being used on a mobile device.  If select on one, it can become a drop down menu to select other tabs under that general top layer (I don't think that function is in the attached css file).  I've put a sample of such tabs (not drop down) in header.html attached.  Though I'm sure everyone else can write far better css and html code.

As I'm not a heavy mobile user, and often do need the whole screen to view matters, it would be nice if all of this could be optional in the elog.cfg file.

/* make things look a bit nicer on smaller screens */
@media (max-width: 700px) {
	table.listframe td, table.listframe th {
		display: none;
	}

	/* show id, date, personnel, summary in separate lines */
	table.listframe td:nth-of-type(-n+2), table.listframe td:nth-of-type(4), table.listframe td:nth-last-of-type(2) {
		display: block;
		border: 0px;
	}
}

In the emails generated by anyone making an entry in this log book, every apostrophe is followed by a semi-colon.  So the text "I don't think..."  appears in the email as "I don';t think...", and possibly that comment will appear in the email as "I don';;t think...." - not sure on the last bit.  It has been around in the past few versions of elog, but don't recall precisely when this started occurring.  It was fine back in February, with v2.9.2 (presumably) running.

Older versions of elogd have a problem with sending long attachements - the send() syscall is not protected against interrupt by SIGALARM. This seems to be fixed in non-SSL builds of current elog (version 3+), 
but for SSL builds, the error handling for the SSL_write() function looks incorrect. In addition, from OpenSSL documentation it is not clear if SSL_write() can handle signal interrupts at all.
K.O.

URL causes elogd to crash when a global password file name doesn't match any group's password file name. 

The offending URL is copied from the address field of the browser after sorting a logbook by on of the fileds.

After login out and using the copied URL, elogd shows the authentication dialog and then crashes after the credentials are submited.

Some debugging point me to a NULL pointer on the following instruction in line   25502  of elogd.c :

  if (lbs->pwd_xml_tree) {

The work around was to name the global password file as the password file of one of the groups.

I could not reproduce your problem. I can only fix it if I can reproduce it, so let's agree on a common test base. May I ask you to do the following:

• Download the most recent elog version from bitbucket and compile it
• Create two new logbooks "demo1" and "demo2" with minimal configuration, but using yor global password file which differs from the group ones
• Send me step-by-step instructions how to trigger the problem, including your elogd.cfg file and your password files (of course with fake accounts)

If I can reproduce the crash, I can fix it.

Apostrophes are encoded as "'" inside the CKEditor used by elog, which sents the raw HTML text as email notification. You can test this by pressing the "Source" button at the top left menu in the CKEditor, then you see it. In my mail program (both Apple Mail and Thunderbird) this HTML enocding is correctly shown as the original apostroph, so I suspect that your mail program has an issue interpreting HTML encodings.