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.

Attributes = Time Start, Time End

Type Time Start = datetime
Type Time End = datetime

Time format = %H:%M:%S

Attributes = Time Start, Time End

Type Time Start = datetime
Type Time End = datetime

Time format Time Start = %H:%M:%S
Time format Time End = %H:%M:%S

Converting from elog 2.9.something to new elog 3.1.0 elogd refuses to start, instructs running elconv in one logbook.

When I do so, elconv converts a existing mhttpd-style elog entries to the new format (the corresponding new-format entries already exist)
and deletes everything else - this is very bad.

So there are 2 bugs:
- elogd should not tell us to run elconv when both old-style and corresponding new-style elog entries exist
- elconv should not delete all existing new-style elog entries.

I confirm that elconv *does* delete all new-style elog entries - with strace, I see it issue "unlink" on every elog entry.

What a disaster!

K.O.

> - 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

I just updated to the latest official release (V3.1.0-2411f95) and have this problem:

The Time Stamp button pastes the logbook name when "Time format" is not specified in elogd.cfg, and when it is set to "%m/%d/%Y %H:%M", it adds the string "5/28/."

My users are loving the new functionality added in 3.1!

I wanted to reply to the post "Three problems..." and then changed my mind. 
But since this logbook does not allow to delete entries (not even my own) I was neither able to remove the draft
nor the final entry.

Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.

Cheers
Andreas

> Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.

Well, this is a problem indeed. When edit entries now, drafts gets saved regularly, overwriting your original entry. This is a limitation of the elog database, which cannot do full versioning. So "Back" is actually the same as "Commit without email notification". Or better "Commit some ten seconds ago". Now I 
don't know what the best solution is. I'm tempted to just remove the "Back" button and replace it with a "Delete" button. So people can either submit an entry or delete it completely. Any thoughts?

> > Another strange thing: the draft got submitted when I hit the "Back" button after reopening it.
> 
> Well, this is a problem indeed. When edit entries now, drafts gets saved regularly, overwriting your original entry. 
> This is a limitation of the elog database, which cannot do full versioning. 
> So "Back" is actually the same as "Commit without email notification". Or better "Commit some ten seconds ago". 
> Now I don't know what the best solution is.
> I'm tempted to just remove the "Back" button and replace it with a "Delete" button.
> So people can either submit an entry or delete it completely. Any thoughts?

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".

> 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

Additional info:

"Time format = %Y" results in "2015" being pasted into the edit window when I hit the "time stamp" button.

"Time format = %m/%Y" results in the string "06/2015"

"TIme format = %m/%d/%Y" results in the string "06/04"

"Time format = %m/%d %H" results in the string "06/04 "

PS to David: The subject "Three problems ..." is not giving any indication what it is about. I would find it better in this case to post three entries to the Forum, each with a striking title :-)

Andreas,

I too was able to track the problem down to the "gettimedate" function in elogd.c. It looks like the code is using a variable named "str" for several different purposes. I haven't had a chance to do any testing, but my suspsicion is that the size of the dynamically allocated variable is ending up too small for the time stamp string, so it gets truncated.

Your point about the topic title is a good one - I'll split this into separate issues, thanks!

Indeed the "str" variable at the gettimedate function had the wrong string size, so that all date strings got truncated at 8 characters. That's what you've seen. Also the ../../?cmd=gettimedate was wrong and it should be ./?cmd=gettimedate. I committed the fix to GIT so it will be contained in the next release ofe log.

Hi,

I updated an old elog entry and resubmit it as new by checking the box resubmit as new.   Does the subject line should said it is a "New ELOG entry" instead of "Updated ELOG entry"?  Thank you.

Also when some people submit a new elog, the subject line is "Updated ELOG entry".  This is a bit odd.  I can't reproduce that bug when I did my test. 

Jacky 

I fixed both issues, now resubmitting an entry or submitting a new entry both yields "New LEOG entry".

Hi Stefan,

I see that you've updated the elog running this forum today, 5 versions after you reported fixing the "A new elog entry has been entered" and "An old elog entry has been updated" issue.  But the emails coming out are still all of the "An old elog entry...", rather than "A new..."

David.

Any better now?

Hi Stefan,

The email sent from here had he expected (correct) message "A new ELOG entry..."

Thanks, David.

Hi,

I compiled the 3.1.0-2 source rpm from the download area.  Unless there is a minor release, I think the problem is still there.  Thank you.

Jacky

Making a new release takes me about an hour (compile under Windows, Linux, Mac OSX), so I don't do it for each little change. If you want to follow the development closely, I recommend that you learn to compile elog from the GIT repository. It's pretty easy: a git pull, followed by a make and make install.

If you want to see which changes are already in the version you are running, look at the 7 digit GIT hash at the bottom of each elog page and compare it with the bitbucket repository:

Hi Stefan,

I had started to write a completely different bug report, but then realised I had not checked a detail.  I had written about one sentence.  So I decided to abort the message, and hit the "back" button.  Only I found that this had created a new entry in the elog listings.  I immediately went in and deleted it, but I had expected the "Back" button to have aborted the entry (as it does in 2.9.x) not to submit the entry!

It doesn't seem to have created an email, though.  And for the sake of all your users, I'd not want to experiment here on the matter too much!

Just to comment that I submitted the entry below by pressing the "Back" button!

Just to comment that the expected emails that one would have expected with the last two entries have either
been held up or simply have not been generated and sent - both the preceeding entries were submitted by using the "Back" button, this time I'll use the "Submit" button, which should generate a email.

Just read what I wrote at elog:67983

I missed or don't remember that post.  My vote is replace "Back" with "Delete" - or "Abort"

Hi Stefan,

I am happy to see that you include the webserver authentication.
So I can now login at some other page and then access elog.
However, I would also need some means of logging out some where else.

For this I propose a new Configuration option "Logout to page" which redirects to another page if set and "Logout to main" is 0.

See the attached patch (against git HEAD)

Does this make sense to you ?

Christof

PS: Many thanks for the autosave mode,  I already used it ;-)
 

I implemented it, but actually called it Logout to URL = <URL>

Yes, I saw it on bitbucket, also all the commits. Thanks!

Hi Stefan,

here is a draft of how you could describe the webserver authentication in your docs.

T/Christof

Also this made it now to the docs. Thanks.