> I think it would be nice to have three options:
> - "Submit": making the draft entry a "real" entry, with an ID
> - "Abort": keeping the entry as a draft entry as it currently is (or was 10 sec ago)
> - "Delete": removing the draft entry.
> 
> I understand that the draft is overwritten currently by the "Back" button, but why does it get an ID and does not stay as a "Draft"?
> As a quick fix you may skip the "Abort" for now and just provide "Submit" and "Delete".

Any entry in elog (also drafts) need an ID in order to be stored on the server, no way around that.

The "Abort" button is exactly the same as the "Back" button, just the name is different. But I think the meaning will not be so clear
to the users. They could expect to abort the edit, and get the version as it was before they started editing (which is not possible).

So I'm tempted to just have "Submit" and "Delete". If one wants to abort, one can navigate away from the page, and confirm the "Leave page"
dialog box. So experts who know what they do can still do an abort if necessary.

Stefan

> - elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist

I removed that check completely. The old format was used up to 2002, so I expect that all users have upgraded in meantime.

Stefan

On my linux box, every time I select a thread, or start a new entry etc, I see that one or many cookies are sent.

On a terminal, I get the message

Received unknown cookie "CalciumDisplayParams"

Now I do have a perl script called Calcium, (Calendar viewed through the browser) but it's definately not running now, not in any browser window, and in any case why should an action of ELOG trigger this?  I realise it may be due to an idiocyncratic set up of this box.  But in normal operation, I doubt the user would see these cookies being received.

Cookies are sent from your browser. ELOG has no influence on what the browser sends where. Probably you run your calender at the same machine where ELOG is running, so all the cookies your calender app stores in your browser are sent to ELOG as well. ELOG just complains about something it does not know, but otherwise this message can be simply ignored. Of course you can delete your cookies in your browser, but after the next call to your calendar app they will show up again.

Hi Stefan,

Thanks for the explanation.  I realised it was just an error message of no real import, but it can get irritating at times.

I have multiple elogs running on a server.  Is it possible to set one elog to a different timezone?  For example, I run an elog for a group in Washington state, and another elog for a collaboration group in Germany.  I would like to set each elog to their respective timezone. 

thanks,

Gary

Andreas,

I am running the latest version of the elogd source RPM that I could find - ELOG V3.1.0-2411f95 on Red Hat Enterprise Linux Server release 6.6 (Santiago), with kernel level 2.6.32-504.16.2.el6.x86_64. I can try grabbing the latest source code from Git and try building that. There are a couple other fixes I'd like to apply anyway. Thanks!

The elog server grabs the local timezone from the underlying OS. Under Linux, you can change the timezone using the TZ environment variable. See here: http://www.cyberciti.biz/faq/howto-linux-set-time-zone-per-user-basis/

If you need different time zones on the same server, you have to create two accounts and run two instances of elogd on these accounts.