| ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
|
68461
|
Thu Nov 17 09:14:15 2016 |
 | Andreas Luedeke | andreas.luedeke@psi.ch | Request | All | 3.1.2 | Re: Cancel button missing when editing an entry | Yes, "Save Drafts = 0" does the trick. But it is the "zero-option": trivial, but not satisfying ;-)
Warning: the "back" button of the browser has a very undesired effect: the entry is then converted into a draft and not shown anymore in list view!
So if you ever wondered where your entries vanished to: it might be that someone opened them in edit view, started to edit them and then closed the browser window. I will make that known at my institute.
| Grant Jeffcote wrote: |
|
Andreas,
Doesn't using the Save Drafts = 0 option result in the old 'Back' button returning (replacing the Delete option) meaning you can revert back to your old (unmodified) version without saving, sure it doesn't save a draft but I'd rather be able to return back and lose the changes I didn't want then mess up an old entry, I guess the back button on the browser could also do what you want?
The issue I had was that entries were being deleted accidently by persons other than those that created them, I reduced the edit time to try and mitigate it but ended up going back to what we had in Ver 2.9.2, a 'Back' button.
Grant
| Stefan Ritt wrote: |
|
The problem is that the elog database does not allow for a copy of an entry before you make modifications (and therefore get a "draft"). This is actually very simila to other note taking programs. I use Evernote, which constantly synchronizes between devices, and there I also cannot go back to the version before I started making modification. What one would need is a version system (and Evernote has one), so you can go back to the previous verison, the pre-previous version and so on. But this requires a complete redesign of the elog database.
A quick and dirty solution would be to store the origianal entry inside the browser (using JavaScript). You could then restore the initial version with a "cancel" button. But this mechanism relies then on the browser. If you just leave the page, there is no way the browser can put back the old version.
Stefan
| Andreas Luedeke wrote: |
|
If I edit an old entry, and do some mistake while editing, then there is currently no way to savely discard the changes.
The problem is that the entry will become a draft: if I close the window without saving, then the whole entry is gone: it will be converted into a draft entry. But the draft does contain my changes, it is not the originally saved entry!
The draft mechanism should keep a copy of the entry before I opened it in edit mode, and allow to go back to that copy. The edit form has currently the buttons "Submit", "Save", "Preview" and "Delete"; it should have in addition the button "Cancel", that just closes the edit window without saving the entry and even deleting the draft that was saved while the entry was modified. This should bring you back to the previous list view.
Is anyone out there in favour of this change?
|
|
|
|
|
68464
|
Mon Nov 21 15:07:05 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | 3.1.2 | Re: Cancel button missing when editing an entry | 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
| Grant Jeffcote wrote: |
|
Andreas,
Doesn't using the Save Drafts = 0 option result in the old 'Back' button returning (replacing the Delete option) meaning you can revert back to your old (unmodified) version without saving, sure it doesn't save a draft but I'd rather be able to return back and lose the changes I didn't want then mess up an old entry, I guess the back button on the browser could also do what you want?
The issue I had was that entries were being deleted accidently by persons other than those that created them, I reduced the edit time to try and mitigate it but ended up going back to what we had in Ver 2.9.2, a 'Back' button.
Grant
| Stefan Ritt wrote: |
|
The problem is that the elog database does not allow for a copy of an entry before you make modifications (and therefore get a "draft"). This is actually very simila to other note taking programs. I use Evernote, which constantly synchronizes between devices, and there I also cannot go back to the version before I started making modification. What one would need is a version system (and Evernote has one), so you can go back to the previous verison, the pre-previous version and so on. But this requires a complete redesign of the elog database.
A quick and dirty solution would be to store the origianal entry inside the browser (using JavaScript). You could then restore the initial version with a "cancel" button. But this mechanism relies then on the browser. If you just leave the page, there is no way the browser can put back the old version.
Stefan
| Andreas Luedeke wrote: |
|
If I edit an old entry, and do some mistake while editing, then there is currently no way to savely discard the changes.
The problem is that the entry will become a draft: if I close the window without saving, then the whole entry is gone: it will be converted into a draft entry. But the draft does contain my changes, it is not the originally saved entry!
The draft mechanism should keep a copy of the entry before I opened it in edit mode, and allow to go back to that copy. The edit form has currently the buttons "Submit", "Save", "Preview" and "Delete"; it should have in addition the button "Cancel", that just closes the edit window without saving the entry and even deleting the draft that was saved while the entry was modified. This should bring you back to the previous list view.
Is anyone out there in favour of this change?
|
|
|
|
|
68465
|
Wed Nov 23 09:25:15 2016 |
| Christine Quicot | christine.quicot@meteo.fr | Request | All | 3.1.2 | Re: Cancel button missing when editing an entry | 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
| Stefan Ritt wrote: |
|
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
| Grant Jeffcote wrote: |
|
Andreas,
Doesn't using the Save Drafts = 0 option result in the old 'Back' button returning (replacing the Delete option) meaning you can revert back to your old (unmodified) version without saving, sure it doesn't save a draft but I'd rather be able to return back and lose the changes I didn't want then mess up an old entry, I guess the back button on the browser could also do what you want?
The issue I had was that entries were being deleted accidently by persons other than those that created them, I reduced the edit time to try and mitigate it but ended up going back to what we had in Ver 2.9.2, a 'Back' button.
Grant
| Stefan Ritt wrote: |
|
The problem is that the elog database does not allow for a copy of an entry before you make modifications (and therefore get a "draft"). This is actually very simila to other note taking programs. I use Evernote, which constantly synchronizes between devices, and there I also cannot go back to the version before I started making modification. What one would need is a version system (and Evernote has one), so you can go back to the previous verison, the pre-previous version and so on. But this requires a complete redesign of the elog database.
A quick and dirty solution would be to store the origianal entry inside the browser (using JavaScript). You could then restore the initial version with a "cancel" button. But this mechanism relies then on the browser. If you just leave the page, there is no way the browser can put back the old version.
Stefan
| Andreas Luedeke wrote: |
|
If I edit an old entry, and do some mistake while editing, then there is currently no way to savely discard the changes.
The problem is that the entry will become a draft: if I close the window without saving, then the whole entry is gone: it will be converted into a draft entry. But the draft does contain my changes, it is not the originally saved entry!
The draft mechanism should keep a copy of the entry before I opened it in edit mode, and allow to go back to that copy. The edit form has currently the buttons "Submit", "Save", "Preview" and "Delete"; it should have in addition the button "Cancel", that just closes the edit window without saving the entry and even deleting the draft that was saved while the entry was modified. This should bring you back to the previous list view.
Is anyone out there in favour of this change?
|
|
|
|
|
|
68466
|
Thu Nov 24 07:38:52 2016 |
| Andreas Luedeke | andreas.luedeke@psi.ch | Request | All | 3.1.2 | Re: Cancel button missing when editing an entry | Hi Stefan,
actually what you refer to as the "quick and dirty" solution is probably the only feasible one: to store a copy of the entry in the browser and restore that copy with a "cancel" button.
Otherwise you would need a full-fledged revision management, to deal with multiple copies of the same entry open in several browsers.
Yet, that does not solve the "problem" of a crashed/closed browser: the entries will go back to drafts and might got overlooked. As you rightly say: this is a feature, not a bug.
This is only a problem when editing existing entries, not for new entries. Maybe a note right of the button "delete" would help, in case you edit an old entry: "This entry is now a draft; press Submit to make it a real entry again".
But as a first step, it might be worthwhile to document this behaviour in the ELOG "User's Guide". Drafts are currently only mentioned in the elogd.cfg syntax pages under "Save drafts" and "autosave". I'll try to propose a text :-)
Kind Regards
Andreas
| Stefan Ritt wrote: |
|
The problem is that the elog database does not allow for a copy of an entry before you make modifications (and therefore get a "draft"). This is actually very simila to other note taking programs. I use Evernote, which constantly synchronizes between devices, and there I also cannot go back to the version before I started making modification. What one would need is a version system (and Evernote has one), so you can go back to the previous verison, the pre-previous version and so on. But this requires a complete redesign of the elog database.
A quick and dirty solution would be to store the origianal entry inside the browser (using JavaScript). You could then restore the initial version with a "cancel" button. But this mechanism relies then on the browser. If you just leave the page, there is no way the browser can put back the old version.
Stefan
| Andreas Luedeke wrote: |
|
If I edit an old entry, and do some mistake while editing, then there is currently no way to savely discard the changes.
The problem is that the entry will become a draft: if I close the window without saving, then the whole entry is gone: it will be converted into a draft entry. But the draft does contain my changes, it is not the originally saved entry!
The draft mechanism should keep a copy of the entry before I opened it in edit mode, and allow to go back to that copy. The edit form has currently the buttons "Submit", "Save", "Preview" and "Delete"; it should have in addition the button "Cancel", that just closes the edit window without saving the entry and even deleting the draft that was saved while the entry was modified. This should bring you back to the previous list view.
Is anyone out there in favour of this change?
|
|
|
|
68467
|
Thu Nov 24 08:40:31 2016 |
| Stefan Ritt | stefan.ritt@psi.ch | Request | All | 3.1.2 | Re: Cancel button missing when editing an entry |
| Andreas Luedeke wrote: |
|
But as a first step, it might be worthwhile to document this behaviour in the ELOG "User's Guide". Drafts are currently only mentioned in the elogd.cfg syntax pages under "Save drafts" and "autosave". I'll try to propose a text :-)
|
Yes, I would be more than happy to include your text in the documentation.
Stefan |
|
987
|
Wed Mar 16 22:14:19 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.5.7 | Re: Can't use the command-line client | > There is a read password ("Read Password=..." entry in elogd.cfg) on
> the logbook which I cannot bypass from the client.
This is correct. The elog utility works with write passwords and user level access
(specifying a password file), but not with read passwords, that's not implemented. Use a
password file and you should be fine.
> There is a required attribute called "Publiek", and it's defined as
> MOptions. Whenever I try to upload, I keep getting the message that
> it misses this attribute.
Your problem is that you try to combine a MOptions with a "-r <n>" (reply-to) option. I
have never tried that and found there is a problem. I changed the way MOptions are
submitted. Instead of using <name>_0, <name>_1 etc, you can now do a
-a "<attrib>=<value1> | <value2>"
This also solves the problem with the "-r" option. You have to upgrade elogd.c from CVS. |
|
988
|
Thu Mar 17 09:56:21 2005 |
 | Pieter Edelman | elog@pde.slimblondje.nl | Question | Linux | 2.5.7 | Re: Can't use the command-line client | This solved the problems, thanks for the fast response!
On a side note, one would expect that when "Fixed Attributes Edit" or "Fixed Attributes
Reply" is set, the attributes in this list shouldn't be supplied with the command line client.
Anyway, my problem is solved. Thanks for the great product.
Pieter. |
|
989
|
Thu Mar 17 10:02:45 2005 |
| Stefan Ritt | stefan.ritt@psi.ch | Question | Linux | 2.5.7 | Re: Can't use the command-line client | > On a side note, one would expect that when "Fixed Attributes Edit" or "Fixed Attributes
> Reply" is set, the attributes in this list shouldn't be supplied with the command line client.
Well, don't shoot yourself in the foot! The communication between elog and elogd is limited. elog
more or less submits "blindly" whatever you give it on the command line. If "Fixed Attributes
Edit/Reply" is set in the configuration, this only affects the web page with the entry form, so
these attributes are not shown as edit boxes. They are not checked during submission by elogd. Now
to get the same functionality with elog, elog whould have to retrieve the full entry form, analyze
the HTML code, find out which attributes have edit boxes and which ones not. So that's a lot of
work. Since most people use elog in scripts, they set it up once and forever correctly. There are
actually a few people which even want the functionality that elog can change attributes which are
normally fixed.
- Stefan |
|