Moodle
  1. Moodle
  2. MDL-18014

Automatically and periodically save WYSIWYG editor content as a draft/concept

    Details

    • Rank:
      29

      Description

      This emerged during the discussion at MDL-13370. Shortly: use AJAX to automatically and periodically (eg. every minute) save the content of a WYSIWYG editor to the concepts (drafts) space. See GMail for the working example.

      It seems to me that we could use table mdl_post for this therefore not DB changes should be required. There will be a flag for a rich text field definitions that enables this feature. Every WYSIWYG will have to have some uniq identifier. Concepts are accessible to their owners only (and admins?) - maybe via a card in their profiles? Their lifetime is a subject of configuration - couple of hours by default.

      1. MDL-18014-autosave-alpha1.diff.txt
        19 kB
        David Mudrak
      1. autosave-1.png
        28 kB
      2. autosave-2.png
        29 kB
      3. autosave-3.png
        7 kB
      4. autosave-4.png
        9 kB

        Issue Links

          Activity

          David Mudrak created issue -
          David Mudrak made changes -
          Field Original Value New Value
          Link This issue has been marked as being related by MDL-13370 [ MDL-13370 ]
          David Mudrak made changes -
          Link This issue will help resolve MDL-16732 [ MDL-16732 ]
          David Mudrak made changes -
          Link This issue will help resolve MDL-14963 [ MDL-14963 ]
          Hide
          David Mudrak added a comment -

          By Olli Savolainen at http://moodle.org/mod/forum/discuss.php?d=74710 :

          "A similar thing could be done, yes, for forum posting, too, or for that matter any other form field. Since Moodle uses YUI instead of prototype, it should be done with that, and probably we should try to make it more general than just something that works for quiz or for forum; i.e. this kind of functionality should be integrated in the editor itself and a general backend to receive the autosaves would need to be created."

          Show
          David Mudrak added a comment - By Olli Savolainen at http://moodle.org/mod/forum/discuss.php?d=74710 : "A similar thing could be done, yes, for forum posting, too, or for that matter any other form field. Since Moodle uses YUI instead of prototype, it should be done with that, and probably we should try to make it more general than just something that works for quiz or for forum; i.e. this kind of functionality should be integrated in the editor itself and a general backend to receive the autosaves would need to be created."
          David Mudrak made changes -
          Link This issue will help resolve MDL-15220 [ MDL-15220 ]
          David Mudrak made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          David Mudrak added a comment -

          I've got first working prototype of autosaving. At the moment it can support all form fields rendered by print_textarea(). There are several important aspects to be discussed:

          1. at the moment, I save the content of the field into the table 'post' where module is 'autosave'. Is it ok?
          2. how shall we implement a recovery procedure? i mean - what the user has to do to get the autosaved contents? I can see two possible approaches:
          2.1. add another tab into the user profile where she can find all her recent autosaved fields. This is easy to implement and might be enough given that autosave feature is just a backup&rescue tool
          2.2. after the page with a supported field is loaded, try to check if we have a previously autosaved content and offer it to user. This is more difficult to implement. How to make sure we are at the same page again? URL may have changed since the field was autosaved...

          Show
          David Mudrak added a comment - I've got first working prototype of autosaving. At the moment it can support all form fields rendered by print_textarea(). There are several important aspects to be discussed: 1. at the moment, I save the content of the field into the table 'post' where module is 'autosave'. Is it ok? 2. how shall we implement a recovery procedure? i mean - what the user has to do to get the autosaved contents? I can see two possible approaches: 2.1. add another tab into the user profile where she can find all her recent autosaved fields. This is easy to implement and might be enough given that autosave feature is just a backup&rescue tool 2.2. after the page with a supported field is loaded, try to check if we have a previously autosaved content and offer it to user. This is more difficult to implement. How to make sure we are at the same page again? URL may have changed since the field was autosaved...
          David Mudrak made changes -
          Component/s HTML Editor [ 10070 ]
          David Mudrak made changes -
          Attachment autosave-1.png [ 16135 ]
          David Mudrak made changes -
          Attachment autosave-2.png [ 16136 ]
          Hide
          Tim Hunt added a comment -

          This is a valuable feature, but ...

          1. I don't think that the post table is the right place for this. Make a new table specifically for this purpose.

          2. Recovery should be as transparent as possible.

          3. If this is worth doing, surely it is worth doing for all form fields.

          4. What does this do to server load. For example it is not much good auto-saving data during a quiz attempt, if the result is to overload the server and crash it when otherwise everything would be fine.

          5. What are the security implications. For example, if an malicious person can insert arbitrary content into the admin's autosaved fields area, then when the admin goes to look at that content, he is vulnerable to XSS vulnerabilities. Of course, the more validation you try to do, the more the performance implications.

          6. Whatever happens, we need an on/off switch in the admin settings, so admins can control this.

          7. What are we actually trying to achieve here anyway? Are we saving people from browser crashes, session problems, server crashes, what?

          Show
          Tim Hunt added a comment - This is a valuable feature, but ... 1. I don't think that the post table is the right place for this. Make a new table specifically for this purpose. 2. Recovery should be as transparent as possible. 3. If this is worth doing, surely it is worth doing for all form fields. 4. What does this do to server load. For example it is not much good auto-saving data during a quiz attempt, if the result is to overload the server and crash it when otherwise everything would be fine. 5. What are the security implications. For example, if an malicious person can insert arbitrary content into the admin's autosaved fields area, then when the admin goes to look at that content, he is vulnerable to XSS vulnerabilities. Of course, the more validation you try to do, the more the performance implications. 6. Whatever happens, we need an on/off switch in the admin settings, so admins can control this. 7. What are we actually trying to achieve here anyway? Are we saving people from browser crashes, session problems, server crashes, what?
          Hide
          David Mudrak added a comment -

          Thanks for your "buts", Tim.

          re 1. I have chosen the current post table because they are simply there and ready, which makes the development and testing much much easier (no need to upgrade, bump versions etc.). I will keep in mind that the physical storage can be change in the future. However, all I/O operation are wrapped so it won't be hard task to rewrite this part.

          re 2. well, it matters. I understand this feature as a rescue tool for users whose browsers do not cache the content of our HTML editor. Moreover, because TinyMCE does not update the content of the textarea it is linked to automatically but at the moment of saving the form (using tinyMCE.triggerSave(} call), the browser has nothing to cache. So, I do not think we really need a transparent recovery. Ask somebody who spent half an hour writing a forum post, then lost the focus of the editor (by a popup for example), returned back (after closing the popup) and pressed the backspace because of a typo. He is redirected to the previous page and after returning back, the HTML editor is empty. Such user will be more than happy if he is able to find a minute old draft of his post anywhere in the Moodle, without the need to get the content automatically. Of course, I would like to see a transparent and silent recovery more, but it makes the whole mechanism more complicated. I like things simply stupid.

          re 3. sure it is. Let us start with the support of HTML editor. Usually standard form fields are pretty well cached by the browser itself and the input is not so long.

          re 4 + 6. totally agree. Admins will have to enable this feature and set the frequency of the autosaving (influnce the server load) and the draft lifetime

          5. a priority issue, of course. That is why I wanted to put automatically saved drafts into a user space, ie. his profile. No automatic pre-filling of forms from drafts. If I loose something, I will find it in a rescue box at my profile page. Should standard sesskey() validation be enough in this case?

          7. see the users' stories in the linked issues. Basically this should protect from browser crashes, accidental redirections, window/tab close, connectivity problems, server crash etc. Actually I can't see the point of this question.

          Show
          David Mudrak added a comment - Thanks for your "buts", Tim. re 1. I have chosen the current post table because they are simply there and ready, which makes the development and testing much much easier (no need to upgrade, bump versions etc.). I will keep in mind that the physical storage can be change in the future. However, all I/O operation are wrapped so it won't be hard task to rewrite this part. re 2. well, it matters. I understand this feature as a rescue tool for users whose browsers do not cache the content of our HTML editor. Moreover, because TinyMCE does not update the content of the textarea it is linked to automatically but at the moment of saving the form (using tinyMCE.triggerSave(} call), the browser has nothing to cache. So, I do not think we really need a transparent recovery. Ask somebody who spent half an hour writing a forum post, then lost the focus of the editor (by a popup for example), returned back (after closing the popup) and pressed the backspace because of a typo. He is redirected to the previous page and after returning back, the HTML editor is empty. Such user will be more than happy if he is able to find a minute old draft of his post anywhere in the Moodle, without the need to get the content automatically. Of course, I would like to see a transparent and silent recovery more, but it makes the whole mechanism more complicated. I like things simply stupid. re 3. sure it is. Let us start with the support of HTML editor. Usually standard form fields are pretty well cached by the browser itself and the input is not so long. re 4 + 6. totally agree. Admins will have to enable this feature and set the frequency of the autosaving (influnce the server load) and the draft lifetime 5. a priority issue, of course. That is why I wanted to put automatically saved drafts into a user space, ie. his profile. No automatic pre-filling of forms from drafts. If I loose something, I will find it in a rescue box at my profile page. Should standard sesskey() validation be enough in this case? 7. see the users' stories in the linked issues. Basically this should protect from browser crashes, accidental redirections, window/tab close, connectivity problems, server crash etc. Actually I can't see the point of this question.
          Hide
          David Mudrak added a comment -

          Well. After submitting the previous post I repeated some tests to be sure and realized that maybe my arguments are useless. TinyMCE in HEAD is cached in my FF3 when navigating to the previous page and back again :-/ It does not work with the current editor (HTMLArea is it?) in 1.9 stable but does in HEAD. Hmm... much ado about nothing? I will test IE and Opera yet. Can some Apple fan try Safari please?

          Show
          David Mudrak added a comment - Well. After submitting the previous post I repeated some tests to be sure and realized that maybe my arguments are useless. TinyMCE in HEAD is cached in my FF3 when navigating to the previous page and back again :-/ It does not work with the current editor (HTMLArea is it?) in 1.9 stable but does in HEAD. Hmm... much ado about nothing? I will test IE and Opera yet. Can some Apple fan try Safari please?
          Hide
          Matt Gibson added a comment -

          Regarding point 7, there is also simply forgetting about a tab you've been working on and shutting the browser. I've done this three times in the last two weeks whilst writing long schemes of work into a wiki and it's driving me nuts.

          It occurred to me that it may not be obvious to people that they have a saved draft at all (new feature may not be widely publicised by admins), which would be a real waste of a great feature, so it might be handy if there was some visual indicator e.g. an 'unsaved work' icon next to the item on the main course page and also within the activity itself.

          Show
          Matt Gibson added a comment - Regarding point 7, there is also simply forgetting about a tab you've been working on and shutting the browser. I've done this three times in the last two weeks whilst writing long schemes of work into a wiki and it's driving me nuts. It occurred to me that it may not be obvious to people that they have a saved draft at all (new feature may not be widely publicised by admins), which would be a real waste of a great feature, so it might be handy if there was some visual indicator e.g. an 'unsaved work' icon next to the item on the main course page and also within the activity itself.
          Hide
          Mark Nielsen added a comment -

          What about implementing this through the Moodle form API? The form could have a unique ID (perhaps just use the form's class name?), which is saved with its data into the database. If the form is loaded and there is info for that user in the db, then automatically load the form with the data or ask the user if s/he would like to load it with the data. On submit, the data in the database gets cleared. This route would be transparent for users and turn the form API into an even more powerful tool for developers.

          I would also suggest using the YUI since it is part of Moodle's codebase and it is relatively simple to have it submit a form's data to a URL. Also, it has a nice event listener API that's very helpful for this sort of work.

          A note on performance, one way to help reduce the number of saves is not just by doing it periodically, but also not saving while the user is typing because as soon as you save, it is out of date anyways. You can accomplish this with timeouts by setting one when you detect a change in the form, and then if you detect another change before the timeout has come to pass, then clear/cancel the old timeout and set a new one.

          Show
          Mark Nielsen added a comment - What about implementing this through the Moodle form API? The form could have a unique ID (perhaps just use the form's class name?), which is saved with its data into the database. If the form is loaded and there is info for that user in the db, then automatically load the form with the data or ask the user if s/he would like to load it with the data. On submit, the data in the database gets cleared. This route would be transparent for users and turn the form API into an even more powerful tool for developers. I would also suggest using the YUI since it is part of Moodle's codebase and it is relatively simple to have it submit a form's data to a URL. Also, it has a nice event listener API that's very helpful for this sort of work. A note on performance, one way to help reduce the number of saves is not just by doing it periodically, but also not saving while the user is typing because as soon as you save, it is out of date anyways. You can accomplish this with timeouts by setting one when you detect a change in the form, and then if you detect another change before the timeout has come to pass, then clear/cancel the old timeout and set a new one.
          Hide
          David Mudrak added a comment -

          IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved.

          Yes, the current implementation is based on YUI.

          Hmm, I don't think it is good to wait for the user stop typing. It means that the work of "quick-typers" is never autosaved. Instead, there is no need to send an update call to server in case of no change. We could do some statistics based on moodle.org logs: how long does it take to write an average forum post? Ie. the time from displaying the form to the submitting.

          Show
          David Mudrak added a comment - IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved. Yes, the current implementation is based on YUI. Hmm, I don't think it is good to wait for the user stop typing. It means that the work of "quick-typers" is never autosaved. Instead, there is no need to send an update call to server in case of no change. We could do some statistics based on moodle.org logs: how long does it take to write an average forum post? Ie. the time from displaying the form to the submitting.
          Hide
          Mark Nielsen added a comment -

          "IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved."

          What about using $CFG->pagepath? On the other hand, I wasn't necessarily thinking that we would just enable autosave automatically for every form in Moodle, might be better to have devs implement in the necessary areas. In which case, the dev could assign an appropriate ID. Just another though.

          Show
          Mark Nielsen added a comment - "IMHO the form's class is not enough here - the autosave ID should combine the field id and the URL. But in theory the URL may change while still pointing to the same page where the draft was saved." What about using $CFG->pagepath? On the other hand, I wasn't necessarily thinking that we would just enable autosave automatically for every form in Moodle, might be better to have devs implement in the necessary areas. In which case, the dev could assign an appropriate ID. Just another though.
          Hide
          David Mudrak added a comment -

          Yes, that might be a solution. Of course that fields that should be autosaved will be manually flaged by a developer. I was thinking of forum post bodies only at this moment and there should be no problem identifying such fields.

          Show
          David Mudrak added a comment - Yes, that might be a solution. Of course that fields that should be autosaved will be manually flaged by a developer. I was thinking of forum post bodies only at this moment and there should be no problem identifying such fields.
          Hide
          Sam Marshall added a comment -

          Re screenshot:

          1 'Saving' should prob. be 'Saving draft' or even 'Autosaving draft'. Don't want to scare users into thinking it's already been submitted.

          2 The saving text should be much smaller

          Show
          Sam Marshall added a comment - Re screenshot: 1 'Saving' should prob. be 'Saving draft' or even 'Autosaving draft'. Don't want to scare users into thinking it's already been submitted. 2 The saving text should be much smaller
          Hide
          David Mudrak added a comment -

          I like sam's idea (from the jabber chatroom):

          (15:29:09) sam: can it store the page id (mod-forum-editpost or whatever) and then when you go to that page again (any forum post), display a little '1 recent autosaved draft is available' thing that you can click on to see it and/or get it back somehow?

          Show
          David Mudrak added a comment - I like sam's idea (from the jabber chatroom): (15:29:09) sam: can it store the page id (mod-forum-editpost or whatever) and then when you go to that page again (any forum post), display a little '1 recent autosaved draft is available' thing that you can click on to see it and/or get it back somehow?
          Hide
          David Mudrak added a comment -

          More screenshots to demonstrate the current implementation:

          1. after the page is loaded, an AJAX based check is performed to get know if there is some previously autosaved draft
          2. if no saved draft is found, the autosaving feature is enabled and the field content is saved every xxx seconds
          3. if there is a draft found, an information appears (with a "yellow fade efect" to draw user's attention) and the draft can be restored with a single click

          Show
          David Mudrak added a comment - More screenshots to demonstrate the current implementation: 1. after the page is loaded, an AJAX based check is performed to get know if there is some previously autosaved draft 2. if no saved draft is found, the autosaving feature is enabled and the field content is saved every xxx seconds 3. if there is a draft found, an information appears (with a "yellow fade efect" to draw user's attention) and the draft can be restored with a single click
          David Mudrak made changes -
          Attachment autosave-3.png [ 16183 ]
          Attachment autosave-4.png [ 16184 ]
          Hide
          David Mudrak added a comment -

          The actual state of my patch has been attached as autosave-alpha1.diff.txt. Any comments/review/suggestions etc. warmly welcome

          Show
          David Mudrak added a comment - The actual state of my patch has been attached as autosave-alpha1.diff.txt. Any comments/review/suggestions etc. warmly welcome
          David Mudrak made changes -
          Attachment MDL-18014-autosave-alpha1.diff.txt [ 16206 ]
          David Mudrak made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Hide
          David Mudrak added a comment -

          Stopping progress on this for a while. Petr informed me there are some planned changes in the HEAD leading to introduce a new form element. The element will integrate wysiwyg editor, image uploader and attachment uploader. It looks reasonable for me to wait for this component to be included and than support autosave of it.

          Show
          David Mudrak added a comment - Stopping progress on this for a while. Petr informed me there are some planned changes in the HEAD leading to introduce a new form element. The element will integrate wysiwyg editor, image uploader and attachment uploader. It looks reasonable for me to wait for this component to be included and than support autosave of it.
          David Mudrak made changes -
          Priority Major [ 3 ] Minor [ 4 ]
          Minh-Tam Nguyen made changes -
          Link This issue will help resolve MDL-15855 [ MDL-15855 ]
          Hide
          Mauno Korpelainen added a comment -

          David - can you check http://moodle.org/mod/forum/discuss.php?d=130005&parent=569051#p569547 and http://code.google.com/p/tinyautosave/

          TinyAutoSave plug-in works very well in moodle 2.0 (for textareas of tinymce) as an additional / optional autosave feature (should be possible to enable/disable from administration of course)

          Show
          Mauno Korpelainen added a comment - David - can you check http://moodle.org/mod/forum/discuss.php?d=130005&parent=569051#p569547 and http://code.google.com/p/tinyautosave/ TinyAutoSave plug-in works very well in moodle 2.0 (for textareas of tinymce) as an additional / optional autosave feature (should be possible to enable/disable from administration of course)
          Hide
          Martin Dougiamas added a comment -

          I would still very like to see this in 2.0 if it's not going to be very hard to do.

          Show
          Martin Dougiamas added a comment - I would still very like to see this in 2.0 if it's not going to be very hard to do.
          Martin Dougiamas made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          Hide
          David Mudrak added a comment -

          The purpose of TinyAutoSave is just to prevent from accidental navigating away from the page (by clicking a link or pressing Backspace button). The disadvantage is that it does not store the draft on the server so it is not the same concept as discussed above. But the advantage is that it does not store the draft on the server so there are no performance/bandwidth issues.

          This issue requires some decisions on the required functionality so that we decide about the target version.

          1. Should the embedded media and attached files be autosaved, too? I am not sure our File API can support this at the moment. What file area would we used? What would be the context of the files? And itemids?
          2. Should the draft be saved on server side or client side?

          Show
          David Mudrak added a comment - The purpose of TinyAutoSave is just to prevent from accidental navigating away from the page (by clicking a link or pressing Backspace button). The disadvantage is that it does not store the draft on the server so it is not the same concept as discussed above. But the advantage is that it does not store the draft on the server so there are no performance/bandwidth issues. This issue requires some decisions on the required functionality so that we decide about the target version. 1. Should the embedded media and attached files be autosaved, too? I am not sure our File API can support this at the moment. What file area would we used? What would be the context of the files? And itemids? 2. Should the draft be saved on server side or client side?
          Hide
          Minh-Tam Nguyen added a comment -

          I think that saving the draft on the server is a better solution, as this will protect the draft from getting lost if the user's computer crashes.

          A case that is occasionally reported to us here is that students start typing their post, but then for whatever reason their computer crashes.
          This means that they have to log on again, potentially on a different computer, and in our particular case on a computer that has been deep-frozen. As such, any cached drafts will be lost.

          I think that if the draft was saved on the server, the user could then pick up where they left no matter if they switched computer or not.

          Show
          Minh-Tam Nguyen added a comment - I think that saving the draft on the server is a better solution, as this will protect the draft from getting lost if the user's computer crashes. A case that is occasionally reported to us here is that students start typing their post, but then for whatever reason their computer crashes. This means that they have to log on again, potentially on a different computer, and in our particular case on a computer that has been deep-frozen. As such, any cached drafts will be lost. I think that if the draft was saved on the server, the user could then pick up where they left no matter if they switched computer or not.
          Hide
          Koen Roggemans added a comment -

          It is a difficult question. A network connection failure at saving time will probably cause the text and the draft to be lost.
          I guess saving it simultaneously local and server side is not an option ?

          Show
          Koen Roggemans added a comment - It is a difficult question. A network connection failure at saving time will probably cause the text and the draft to be lost. I guess saving it simultaneously local and server side is not an option ?
          Hide
          Mauno Korpelainen added a comment -

          Server side and/or client side solutions could be used at the same time - current core autosave plugin of tinymce has supported local storage methods since January (no more need to download separate TinyAutoSave plugin anymore) - moodle 2.0 should just be upgraded to use the latest version of tinymce (3.3.6) and moodle sites can add/enable client side autosave feature in init code for those textareas that use tinymce with possible functionality settings http://code.google.com/p/tinyautosave/wiki/Functionality . Autosave plugin supports all the browsers that tinymce supports.

          The primary solution for temporary autosaving user input data might still be a server side solution as far as it can be used and we might need a setting to administration to be able to enable/disable either one or both of these options. In my opinion it does not need to be too complex (at first), the most common failure is that users accidentally press some link or button that moves them away from editor screen or they press some button that closes window/moodle. HTMLArea has failed to keep input data in such cases, tinymce with autosave plugin can in most cases restore the last data.

          Keeping track of user processes might be usefull for other purposes as well - for example Version control here in tracker offers a nice way to track back last changes in files and in Wiki it is useful to find the last changes saved by different users. The main difficulty in autosaving data is in my opinion the choice of deleting unnecessary data - particularly duplicate files - as soon as possible

          So if we need to autosave also attachments (clone attachments) clones should be deleted immediatelly after the actual data & attachments have been saved (or small hosted sites run easily out of hard disc space

          Show
          Mauno Korpelainen added a comment - Server side and/or client side solutions could be used at the same time - current core autosave plugin of tinymce has supported local storage methods since January (no more need to download separate TinyAutoSave plugin anymore) - moodle 2.0 should just be upgraded to use the latest version of tinymce (3.3.6) and moodle sites can add/enable client side autosave feature in init code for those textareas that use tinymce with possible functionality settings http://code.google.com/p/tinyautosave/wiki/Functionality . Autosave plugin supports all the browsers that tinymce supports. The primary solution for temporary autosaving user input data might still be a server side solution as far as it can be used and we might need a setting to administration to be able to enable/disable either one or both of these options. In my opinion it does not need to be too complex (at first), the most common failure is that users accidentally press some link or button that moves them away from editor screen or they press some button that closes window/moodle. HTMLArea has failed to keep input data in such cases, tinymce with autosave plugin can in most cases restore the last data. Keeping track of user processes might be usefull for other purposes as well - for example Version control here in tracker offers a nice way to track back last changes in files and in Wiki it is useful to find the last changes saved by different users. The main difficulty in autosaving data is in my opinion the choice of deleting unnecessary data - particularly duplicate files - as soon as possible So if we need to autosave also attachments (clone attachments) clones should be deleted immediatelly after the actual data & attachments have been saved (or small hosted sites run easily out of hard disc space
          Martin Dougiamas made changes -
          Fix Version/s 2.0.1 [ 10420 ]
          Fix Version/s 2.0 [ 10122 ]
          Martin Dougiamas made changes -
          Workflow jira [ 30402 ] MDL Workflow [ 44403 ]
          Martin Dougiamas made changes -
          Fix Version/s 2.0.2 [ 10421 ]
          Fix Version/s 2.0.1 [ 10420 ]
          Martin Dougiamas made changes -
          Fix Version/s 2.0.3 [ 10537 ]
          Fix Version/s 2.0.2 [ 10421 ]
          David Mudrak made changes -
          Fix Version/s DEV backlog [ 10464 ]
          Fix Version/s 2.0.3 [ 10537 ]
          Hide
          David Mudrak added a comment -

          Re-triage: this must be re-considered for some future version, not in stable.

          Show
          David Mudrak added a comment - Re-triage: this must be re-considered for some future version, not in stable.
          Martin Dougiamas made changes -
          Workflow MDL Workflow [ 44403 ] MDL Full Workflow [ 72778 ]
          Hide
          Koen Roggemans added a comment -

          Please bump this feature request to a near Moodle release. A lot of Web 2.0 applications support auto-save by now, Moodle can't stay behind on this. This request crops up every now and then on the work floor.

          Show
          Koen Roggemans added a comment - Please bump this feature request to a near Moodle release. A lot of Web 2.0 applications support auto-save by now, Moodle can't stay behind on this. This request crops up every now and then on the work floor.
          Hide
          Dimuthu Upeksha added a comment -

          I am new for moodle development and hope to participate gsoc 2012. I think we can use AJAX support to implement this feature. Autosaving is done in background and we can specify the way it should be saved (auto save per minute or when some events are triggered by html elements). I think it is easy if we can add new a new table to store those auto saved items. In that table we can specify user id, last edited time, edited url, data.
          In data field, we can store values of those elements as key value pairs
          eg: (element1 Id: value),(element2 Id: value) likewise
          From url we can identify correct position.

          We can extend this structure to even forms in the applications.
          Those auto saved values are shown in different color so that user can identify it.

          Any ideas?

          Show
          Dimuthu Upeksha added a comment - I am new for moodle development and hope to participate gsoc 2012. I think we can use AJAX support to implement this feature. Autosaving is done in background and we can specify the way it should be saved (auto save per minute or when some events are triggered by html elements). I think it is easy if we can add new a new table to store those auto saved items. In that table we can specify user id, last edited time, edited url, data. In data field, we can store values of those elements as key value pairs eg: (element1 Id: value),(element2 Id: value) likewise From url we can identify correct position. We can extend this structure to even forms in the applications. Those auto saved values are shown in different color so that user can identify it. Any ideas?
          Hide
          David Mudrak added a comment -

          Dimuthu, thanks for considering this for the GSoC project. The HTML text contents itself is not a big issue. Earlier in the 2.0 development branch (before TinyMCE and the new Files API were integrated), I already had a working prototype for that. But the real issue here are files - embedded media and attachments. While editing a form, they are stored in a temporary draft file area and we need to come with a solution, where and how store these files during the lifetime of the form draft/concept. This is the real challenge of this project. It requires deep understanding of the Files API and TinyMCE integration in Moodle. The rest is just fun with YUI and AJAX

          Show
          David Mudrak added a comment - Dimuthu, thanks for considering this for the GSoC project. The HTML text contents itself is not a big issue. Earlier in the 2.0 development branch (before TinyMCE and the new Files API were integrated), I already had a working prototype for that. But the real issue here are files - embedded media and attachments. While editing a form, they are stored in a temporary draft file area and we need to come with a solution, where and how store these files during the lifetime of the form draft/concept. This is the real challenge of this project. It requires deep understanding of the Files API and TinyMCE integration in Moodle. The rest is just fun with YUI and AJAX
          Hide
          Dimuthu Upeksha added a comment -

          David, thank you for reply In the case of uploading attachments and media files I think major issue is having enough server space for that drafts. Now I'm looking at the areas you have explained. However I have some ideas about managing those files.
          1. Allowing maximum draft file storage size for each user (about 20 MB). If it is exceeded old files are deleted and gives chance to new files
          2. If the draft is not reused for some period those drafts are automatically deleted.
          3. Using external server space to store those files. It will reduce the external load on moodle server.

          Show
          Dimuthu Upeksha added a comment - David, thank you for reply In the case of uploading attachments and media files I think major issue is having enough server space for that drafts. Now I'm looking at the areas you have explained. However I have some ideas about managing those files. 1. Allowing maximum draft file storage size for each user (about 20 MB). If it is exceeded old files are deleted and gives chance to new files 2. If the draft is not reused for some period those drafts are automatically deleted. 3. Using external server space to store those files. It will reduce the external load on moodle server.
          Hide
          Josh Johnston added a comment -

          What about skipping the server side storage and using a prebuilt html 5 localStorage API like http://garlicjs.org/ ?

          Show
          Josh Johnston added a comment - What about skipping the server side storage and using a prebuilt html 5 localStorage API like http://garlicjs.org/ ?
          Michael de Raadt made changes -
          Labels triaged
          Affects Version/s 2.4.1 [ 12461 ]
          Michael de Raadt made changes -
          Link This issue will help resolve MDL-37980 [ MDL-37980 ]
          Hide
          Rex Lorenzo added a comment -

          Bumping this issue as a possible UI improvement for the FRONTEND team to focus on for Moodle 2.6. Lots of different ideas and possible solutions, but anything would be an improvement.

          Although, a downside to using HTML local storage is that the user has to hit a confirmation approval before a website can store anything in their browser. Which is potentially very annoying and can cause confusion if they say "No", but later want to enable it.

          Show
          Rex Lorenzo added a comment - Bumping this issue as a possible UI improvement for the FRONTEND team to focus on for Moodle 2.6. Lots of different ideas and possible solutions, but anything would be an improvement. Although, a downside to using HTML local storage is that the user has to hit a confirmation approval before a website can store anything in their browser. Which is potentially very annoying and can cause confusion if they say "No", but later want to enable it.
          David Mudrak made changes -
          Assignee David Mudrak [ mudrd8mz ] moodle.com [ moodle.com ]
          David Mudrak made changes -
          Fix Version/s FRONTEND [ 12581 ]
          Martin Dougiamas made changes -
          Rank Ranked lower
          Hide
          Stuart Lamour added a comment -

          Mark had this working a while back https://moodle.org/mod/forum/discuss.php?d=191050

          Show
          Stuart Lamour added a comment - Mark had this working a while back https://moodle.org/mod/forum/discuss.php?d=191050
          Martin Dougiamas made changes -
          Rank Ranked higher
          Hide
          Martin Dougiamas added a comment -

          I'll make sure this gets included in the "Editor upgrade project" for FRONTEND in 2.7.

          Show
          Martin Dougiamas added a comment - I'll make sure this gets included in the "Editor upgrade project" for FRONTEND in 2.7.
          Rex Lorenzo made changes -
          Link This issue has been marked as being related by MDL-38537 [ MDL-38537 ]
          Damyon Wiese made changes -
          Link This issue will be (partly) resolved by MDL-43434 [ MDL-43434 ]
          Martin Dougiamas made changes -
          Rank Ranked higher
          Hide
          Martin Dougiamas added a comment - - edited

          I like the idea of keeping it simple and using client-side storage. Even if (worst case) it was without the embedded files support initially, it would still be very useful to people.

          Show
          Martin Dougiamas added a comment - - edited I like the idea of keeping it simple and using client-side storage. Even if (worst case) it was without the embedded files support initially, it would still be very useful to people.
          Damyon Wiese made changes -
          Epic Link MDL-43841 [ 73298 ]
          Damyon Wiese made changes -
          Component/s HTML Editor (Atto) [ 13230 ]
          Component/s HTML Editor (TinyMCE) [ 10070 ]
          Component/s Forms Library [ 10091 ]
          Martin Dougiamas made changes -
          Assignee moodle.com [ moodle.com ] Andrew Nicols [ dobedobedoh ]
          Hide
          Andrew Nicols added a comment -

          I've created a proof-of-concept atto plugin for this. It's still not complete and I'll work more on it after the 2.7 release.
          The plugin can be found at https://github.com/andrewnicols/moodle-atto_storage

          Note: It currently does not deal with embedded files at all.

          Show
          Andrew Nicols added a comment - I've created a proof-of-concept atto plugin for this. It's still not complete and I'll work more on it after the 2.7 release. The plugin can be found at https://github.com/andrewnicols/moodle-atto_storage Note: It currently does not deal with embedded files at all.
          Hide
          Dan Poltawski added a comment -

          Looking at that POC it seems the the privacy of the local storage is not considered.

          From a philosophical point of view I think the 'browser session' should be protected by the user. From a practical point of view Moodle is often used in a shared-browser environment so we need to deal with this. One solution of the top of my head is that we could encrypt the data with a secret stored as a user preference.

          Show
          Dan Poltawski added a comment - Looking at that POC it seems the the privacy of the local storage is not considered. From a philosophical point of view I think the 'browser session' should be protected by the user. From a practical point of view Moodle is often used in a shared-browser environment so we need to deal with this. One solution of the top of my head is that we could encrypt the data with a secret stored as a user preference.
          Hide
          Andrew Nicols added a comment -

          Yup - I'm aware of that limitation at present and it's one I've been considering how best to plug. The problem is that there is no native cryptographic encryption in JavaScript, and even if there was it would inherently unsafe (see http://www.matasano.com/articles/javascript-cryptography/ for a pretty good summary).

          In reality someone would have to be actively and maliciously trying to steal data from the store, and have the key (fairly easy to get if we're talking non-SSL), or manipulate the page in some way in order to get the key or data (again, non-SSL or a direct browser attack). However, if someone can access the key in this way, then any way in which we store the data (e.g. AJAX queries to store in the DB) are also probably affected, and we will generally lose against a direct browser attack (that's to say a browser plugin hijacking data for example) so we would be no worse off.

          There is one main user-space Crypto suite - The Stanford Javascript Crypto Library (SJCL - https://github.com/bitwiseshiftleft/sjcl) but I need to look at how best to include it. It is compiled with ES6-style exports so I should be able to convert it into an ES6 YUI module now that we're on 3.15.0, but that's still beta code and pretty new. There is another way that I can include it, but I haven't had a chance to try implementing it yet.

          But rest assured, this is something I intend to address though before I create an official release of the plugin.

          Show
          Andrew Nicols added a comment - Yup - I'm aware of that limitation at present and it's one I've been considering how best to plug. The problem is that there is no native cryptographic encryption in JavaScript, and even if there was it would inherently unsafe (see http://www.matasano.com/articles/javascript-cryptography/ for a pretty good summary). In reality someone would have to be actively and maliciously trying to steal data from the store, and have the key (fairly easy to get if we're talking non-SSL), or manipulate the page in some way in order to get the key or data (again, non-SSL or a direct browser attack). However, if someone can access the key in this way, then any way in which we store the data (e.g. AJAX queries to store in the DB) are also probably affected, and we will generally lose against a direct browser attack (that's to say a browser plugin hijacking data for example) so we would be no worse off. There is one main user-space Crypto suite - The Stanford Javascript Crypto Library (SJCL - https://github.com/bitwiseshiftleft/sjcl ) but I need to look at how best to include it. It is compiled with ES6-style exports so I should be able to convert it into an ES6 YUI module now that we're on 3.15.0, but that's still beta code and pretty new. There is another way that I can include it, but I haven't had a chance to try implementing it yet. But rest assured, this is something I intend to address though before I create an official release of the plugin.
          Hide
          Dan Poltawski added a comment -

          Lets be clear about the 'attack scenario' I am referring to, because it is confusing the issue by talking about SSL and the security of ajax data transmission.

          1. Teacher 'Bob' uses shared browser in a university library to make a correction to their upcoming quiz questions
          2. Student 'Dan' sees the teacher on that workstation and uses it after the teacher
          3. Student 'Dan' uses the localstorage inspector to collect next weeks quiz questions before other students
          Show
          Dan Poltawski added a comment - Lets be clear about the 'attack scenario' I am referring to, because it is confusing the issue by talking about SSL and the security of ajax data transmission. Teacher 'Bob' uses shared browser in a university library to make a correction to their upcoming quiz questions Student 'Dan' sees the teacher on that workstation and uses it after the teacher Student 'Dan' uses the localstorage inspector to collect next weeks quiz questions before other students
          Hide
          Andrew Nicols added a comment -

          Yes - that's my understanding too. The attack comes in two forms:

          • someone has installed a browser plugin to inject additional code, or retrieve the key - this is a problem regardless and affects everything anyway so let's ignore it;
          • someone on the network sniffs for the key or manipulates the HTML during transmission to add additional code - again, this is already a concern, but only for sites not running SSL.

          The real difference here comes that we're now talking about data which may not be transferred over the wire so an attacker could sniff for the key, then see what content was left partially written.

          Mostly it's not a concern though because the attacker would just be getting access to data they already have access to.

          I should point out that on form submission, it nullifies the storage anyway so unless Bob makes his changes, then closes the browser without saving the changes, they won't be there anyway.

          Show
          Andrew Nicols added a comment - Yes - that's my understanding too. The attack comes in two forms: someone has installed a browser plugin to inject additional code, or retrieve the key - this is a problem regardless and affects everything anyway so let's ignore it; someone on the network sniffs for the key or manipulates the HTML during transmission to add additional code - again, this is already a concern, but only for sites not running SSL. The real difference here comes that we're now talking about data which may not be transferred over the wire so an attacker could sniff for the key, then see what content was left partially written. Mostly it's not a concern though because the attacker would just be getting access to data they already have access to. I should point out that on form submission, it nullifies the storage anyway so unless Bob makes his changes, then closes the browser without saving the changes, they won't be there anyway.
          Hide
          Andrew Nicols added a comment -

          Also your attack assumes that they're using the same browser, on the same user profile but this is of course a possibility.
          Either way, I do intend to address this wth the SCJL library.

          Show
          Andrew Nicols added a comment - Also your attack assumes that they're using the same browser, on the same user profile but this is of course a possibility. Either way, I do intend to address this wth the SCJL library.

            People

            • Votes:
              79 Vote for this issue
              Watchers:
              53 Start watching this issue

              Dates

              • Created:
                Updated: