Hi Thomas,

Menu commands = List, New, Reply, Delete, Duplicate, Copy to, Move to, Find, Help

The problem is that we now get auto-saved messages, but no ability for the user to actually go back and finish the draft message.  You can see an example of this state in this test elog

I changed the code such that editing of draft messages is always possible, even if the "edit" command is not allowed otherwise. Update is in GIT. Please check if that works at ND280.

Menu commands = List, New, Reply, Delete, Duplicate, Copy to, Move to, Find, Help

The problem is that we now get auto-saved messages, but no ability for the user to actually go back and finish the draft message.  You can see an example of this state in this test elog

Arghhhh! Guess how many people asked me for the autosave feature! I worked really hard on it (including an airplane flight to Japan!), not the next guy comes "can we disable that feature?". 

I agree that this feature has many side effects, and I have to adress one by one, but in the end the community will benefit. Think of starting a draft at one computer, and finishing at another one. Lazarus won't help you there.

Nevertheless , I added a "Save drafts" which you can set to zero. But I would rather prefer if people tell me their problems, and I fix them, instead of siletnly just disabling this feature and keeping the bugs there unresolved.

Oups, now I feel almost a little bit sorry for asking    But thank you anyway!!!

You should see it that way: there are millions of possible applications for a smart electronic logbook like ELOG, and most possible combinations of flags and options will make sense for some of them

Greetings,

  Running elog 3.1.0 on CentOS 6.6.  When I try to access a nonexistent file, elog reveals a path in the 404 page.  For example:

Not Found

The requested file /usr/local/elog/themes/default/blortblortblort7854.htm was not found on this server

I have a little problem with elogd 3.1.0. The problem persists up to the latest ELOG version, even in the
development branch (V3.1.0-8196b81):

When I want to "Submit" a new entry, I get a javascript pop-up that asks me:

_This page is asking you to confirm that you want to leave - data you have entered may not be saved._

with the options:
"Stay on page" or "Leave page".

The entry is properly submitted if I agree to "Leave page".
But it is very confusing for my users: they are afraid to loose their entry text.

This problem only shows for some specific logbook configurations.
Below is a minimal logbook configuration that shows this problem:
if you select "entry = short", the pop-up is shown;
if you select "entry = long", the pop-up is not shown, the entry is created immediately.

Attributes = entry, when
Options entry = short{1}, long
Type when = datetime
{1} Show Attributes Edit = entry


(PS: it took me several hours to boil down my 120 line configuration into four lines :-) )

Thanks for the "boiling-down" of your config file. That helped me to reproduce the error quickly. It only occurs if you have a date/time attribute which is hidden as a conditional attribute. This is a unusual combination, that's why I haven't seen that bug before. Actually some 
JavaScript code checks the validity of the date attribute, but since it is conditionally not there, the JavaScript code crashes, which triggers the dialog box you see. It's now fixed in the repository.

/Stefan


> I have a little problem with elogd 3.1.0. The problem persists up to the latest ELOG version, even in the
> development branch (V3.1.0-8196b81):
> 
> When I want to "Submit" a new entry, I get a javascript pop-up that asks me:
> 
> _This page is asking you to confirm that you want to leave - data you have entered may not be saved._
> 
> with the options:
> "Stay on page" or "Leave page".
> 
> The entry is properly submitted if I agree to "Leave page".
> But it is very confusing for my users: they are afraid to loose their entry text.
> 
> This problem only shows for some specific logbook configurations.
> Below is a minimal logbook configuration that shows this problem:
> if you select "entry = short", the pop-up is shown;
> if you select "entry = long", the pop-up is not shown, the entry is created immediately.
> 
> Attributes = entry, when
> Options entry = short{1}, long
> Type when = datetime
> {1} Show Attributes Edit = entry
> 
> 
> (PS: it took me several hours to boil down my 120 line configuration into four lines :-) )

> Thanks for the "boiling-down" of your config file. That helped me to reproduce the error quickly. It only occurs if you have a date/time attribute which is hidden as a conditional attribute. This is a unusual combination, that's why I haven't seen that bug before. Actually some 
> JavaScript code checks the validity of the date attribute, but since it is conditionally not there, the JavaScript code crashes, which triggers the dialog box you see. It's now fixed in the repository.
> 
> /Stefan
> 

Thank you Stefan!
That works nicely now.
Apparently it was less work to fix than to isolate it ;-)

Andreas