Well, the "undesired effect" you describe is exactly the reason for having drafts. Somebody works on a lengthy message, then the browser dies, or the user by accident hits the "back" button and (by accidnt, ehem...) confirms the dialog popping up which says "changes will be lost". In that case the draft mechanism should take care of that the lengthy message is not lost. That's where it is for. If one does not like it, one can always turn it off. If one now hits "New", there is the option to continue the previous draft message rather than creating a blank message. Originally, draft messages were shown on the list of entries in a different colors, but people got confused by that, since the draft message appears already during the editing of the message by the user writing it. So upon request I removed it from the listing. Actually the system cannot differentiate between "user still has the message open and works on it" and "browser has crashed". So there is no elegant way to make everybody happy. The only option I can think of is to make the listing of draft messages optioinal (with a new flag in the config file). Would that make sense? Or does anybody see another conecpt?

Stefan

Hello,

In my opinion, there should be a "close/return" button (discard changes), even with the drafts enabled, but effectively there will have to be several saves made (at least before/after).
I chose to unable the drafts because of this unwanted behaviour: when I modify an entry without any change and click on another tab/logbook without saving, then choose to close the window, the entry is deleted.

Chris 

Yes, I would be more than happy to include your text in the documentation.

Stefan

Dear all,

there seems to be still lots of confusion with the new "draft modus" introduced in elog 3.1.2. Here is how it works:

If you edit an old or new entry, your changes are written to the elog server every few seconds. The entry in the elog database is marked as "draft". The idea behind that is that if your browser crashes or you navigate away from the elog page without saving your entry, the "draft" entry is sill in the elog database and can be recovered later. This is typically useful on some shift logbooks, where people keep the entry open for many hours and add things every few minutes. If they have a crash, they would loose a few hours of information.

The draft modus now has a few drawbacks:

• If you have some draft entries in your elog database, you don't see them until you hit "New" the next time. Then the system offers you to continue the open draft entries.
• Once you change an existing entry, you cannot go back to the version of that entry before you started to make modifications. The only option is to keep the current version or delete the whole entry. The old version of your entry in the database is overwritten every few seconds with the current contents of your edit text field.

To fix the first problem, I introduced a new flag "List drafts = 0|1". If this flag is 1, the draft entries are shown in the list view. The default value for this flag is 1, so normally you should see the draft entries in the database. You should refrain from editing these entries if you know that currently somebody else is working on them, otherwise you will overwrite each other's modifications. The modification is in the current git version of elog which is 3.1.2-6ec506b.

The scond drawback is harder to address. In order to go back to previous version, you would need a full version system (ala git), which is far beyond the scope of elog. I'm working on a partial fix by storing the contents on an entry inside the browser when you start editing an entry. You can then "cancel" your modifications by pasting back the original version from your browser. This works of course only if your browser does not crash or you do not navigate away from the elog page, in which case the original version will be lost.

If anybody has a strong opinion about these changes, please post them here.

Stefan

In version 3.1.2-416db9f I implemented a "Restore" button, which should fix the second drawback. If you press it, you should be able to go back to where you started when editing an entry.

Hi Stefan,

PS: Here's a patch that works:

I've quickly checked: there are a couple more commands in the source code that are not language encoded. I guess some of them needs correction.

> egrep -n "cmd=[A-Za-z]" elogd.c
10293:   rsprintf("    r.open('GET', '?jcmd=Unlock&edit_id=%d', true);\n", message_id);
11784:                      ("<label for=\"ELCode\"><a target=\"_blank\" href=\"?cmd=HelpELCode\">ELCode</a>&nbsp;&nbsp;</label>\n");
13663:                                "\r\n%s URL         : %s?cmd=Config&cfg_user=%s&unm=%s\r\n", loc("Logbook"),
14562:      redirect(lbs, "?cmd=Config");
14625:      sprintf(str, "../%s/?cmd=Config", getparam("lbname"));
14678:      sprintf(str, "../%s/?cmd=Config", lbn);
15703:   combine_url(lbs, host, "?cmd=GetMD5", url, sizeof(url), &ssl);
16378:         strcat(str, "?cmd=GetConfig"); // request complete config file
16380:         strcat(str, "?cmd=Download");  // request config section of logbook
16570:      strcat(str, "?cmd=GetPwdFile");   // request password file
17575:            rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17577:            rsprintf("<br><b><a href=\"%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
17579:            rsprintf("<br><b><a href=\"../%s/?cmd=Synchronize&confirm=1\">", lbs->name_enc);
18959:   if (strstr(ref, "cmd=Search&"))
18960:      strlcpy(strstr(ref, "cmd=Search&"), strstr(ref, "cmd=Search&") + 11, sizeof(str));
26728:         rsprintf("<a href=\"?cmd=Synchronize\">%s</a></td>\n", loc("Synchronize all logbooks"));