Top Menu

Jump to content
Home
    Modules
      • Projects
      • Activity
      • Work packages
      • Gantt charts
      • Calendars
      • Team planners
      • Boards
      • News
    • Getting started
    • Introduction video
      Welcome to OpenProject Community
      Get a quick overview of project management and team collaboration with OpenProject. You can restart this video from the help menu.

    • Help and support
    • Upgrade to Enterprise edition
    • User guides
    • Videos
    • Shortcuts
    • Community forum
    • Enterprise support

    • Additional resources
    • Data privacy and security policy
    • Digital accessibility (DE)
    • OpenProject website
    • Security alerts / Newsletter
    • OpenProject blog
    • Release notes
    • Report a bug
    • Development roadmap
    • Add and edit translations
    • API documentation
  • Sign in
      Forgot your password?

      or sign in with your existing account

      Google

Side Menu

  • Overview
  • Activity
    Activity
  • Roadmap
  • Work packages
    Work packages
  • Gantt charts
    Gantt charts
  • Calendars
    Calendars
  • Team planners
    Team planners
  • Boards
    Boards
  • Wiki
    Wiki
  • News

Content

Updated by Wieland Lindenthal over 1 year ago

**As** a contributor writing long texts, e.g. work package descriptions or comments
**I want to** keep my unsaved inputs (let's call them drafts) even when the page closes or the browser crashes
**so that** I don't lose these messages (and lose a lot of time)

**Acceptance criteria**

* When composing/editing a work package description or comment and I kill the browser process, and I restart the browser and open the same URL, it will preload the input fields for with the drafted value.
* When I save the the work package, comment, wiki page,... the draft is removed.
* After X days the (let's say a week) drafts also get discarded in order to not pollute the browser's local storage too much.

The technical idea is assigning every rich text input field (a field that uses CKeditor) something like a URN. The URN could serve us as a key in the browser's local storage to identify that input field's drafted value.

So for example

* the draft for the description of a new work package could have the URN `work_packages/new/description`
* the draft for the description of an existing work package (ID 54) could have the URN `work_packages/54/description`
* the draft of a comment for work package (ID 54) could be `work_packages/54/comment`
* Similar for meetings agendas and minutes, wiki pages etc.

When a user starts composing a message, it will continuously save the current value in the local storage using that URN as the key.

Every time the front-end renders it will check for relevant URNs and change those fields into edit mode and prefill it with the value that was saved as draft in the local storage.

Every time a field gets saved the value in the local storage gets removed.

Back

Loading...