That's strange. Might have to do with the SSL library elog uses. I just tried this forum (actually the "Demo"), and it worked fine through SSL, but I use an Apache proxy server for elog implementing the SSL protocol, which might be slightly different.

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

Hej,

I discovered a problem uploading images taken with the cameras of mobile devices to new elog entries directly from said devices. When selecting the image and choosing "Upload", either the blue page loading indicator gets stuck at around 10% (mobile Safari, iOS 8.3, iPhone 4 and iPad mini) or the error message "failed secure connection; connection reset while page was being loaded" ("Fehler: gesicherte Verbindung fehlgeschlagen. Verbindung zum Server wurde zurueckgesetzt waehrend die Seite geladen wurde") appears shortly after (Android 5.02, Firefox 37.0.2, Motorola G).

From the desktop browser (Firefox 38.0.5, OSX 10.10) there is no problem uploading images at all.

So far, this problem is very reproducible, but only when using ELOG with SSL enabled. Without SSL, the problem disappears on all platforms.

The ELOG daemon runs under Linux (Fedora 18) and I have also tried using the latest development version of ELOG.

Running ELOG with debug messages the only output after the page has been loaded is:

TCP connection #0 on socket 4 closed
TCP connection #0 on socket 4 closed

After these, there is no further output and the mobile devices do not indicate any progress either even after many mi.

The minimal config file I have been using is:

[global]
; network
port = 443
SSL = 1
URL = https://my.server.somewhere/
; paths
Logbook dir = /usr/local/elog/logbooks
Resource dir = /usr/local/elog
Logfile = /tmp/elog.log

[demo]
Attributes = Author, Type, Category, Subject
Required Attributes = Author, Type
Options Type = Status, Modification, Problem Report, Problem Details, Problem Fixed, Other
Options Category = Facility, Experiment, IT, Other
List Page Title = $logbook - $subject

As mentioned before, removing the first three lines fixes the problem (the URL line points to my actual server of course).

I would appreciate any pointers on how to debug this further! The functionality of posting images directly from mobile devices is quite important for the planed deployment of ELOG and I would very much prefer to have SSL enabled when doing so.

Thanks and cheers,

Hanno

> 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

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

What URL did you use? If I try here on this forum I get:

which looks fine to me.