Tickets and ticket comments are not saved automatically

[Philippe Cloutier <chealer@…>]

Writing a ticket or replying to one often takes a lot of time. For instance, writing Debian ticket #677948 must have taken hours. Much of that is research, but losing the text shortly before it is submitted can be costly.

Good ITS engines feature some form of autosaving, so that a mere browser crash does not require spending hours to recover. Even GitHub, a fighter-brand forge, somewhat supports autosaves. Unfortunately, I can see no sign of that on Trac, either in documentation or empirically. This website does not seem to automatically save even just the description when creating a ticket, nor the comment when modifying. I also lost a draft ticket I was reporting to WordPress’s Meta Trac when my PC rebooted. I am therefore confident that trac.edgewall.org does not save tickets and ticket comments automatically, most likely because the Trac version it uses does not do that by default.

Assuming this is not a configuration issue or due to an outdated Trac version, solving issue #3204 would provide almost all the backend needed to automatically save draft tickets on the server.

Ideally, autosaves would:

1. cover all fields in all contexts:
   1. ticket fields when creating
   2. ticket fields and the comment when modifying
2. save contents constantly on the client, and semi-regularly (perhaps at a configurable frequency) on the server.

But I would happily consider a basic implementation saving textarea fields anywhere as a sufficient solution.

Workaround

Using a clipboard manager and frequently copying the contents of text fields allows reducing the risk with reasonable efficiency.

---

This report is from Philippe "Chealer" Cloutier. I am subscribing to this ticket, but notifications are broken. Please manually notify me when you write to me or report important progress. I struggle to display my full email address or link to my contact information from this ticket, but my email address is available on Kune ni povos’s contact page.

This report (including all comments and attachments I add to it) is offered under the terms of CC0 1.0 (unless otherwise noted).

[Jun Omae]

This feature can be implemented as a Trac plugin. I've considered implementing a Trac plugin to auto-save new tickets, comments, and wiki page drafts, but not implemented yet.

GitHub provides the auto-save drafts feature using ​Web session storage.

[Jun Omae]

I disagree that draft data saving to Trac database. It is enough to save the drafts to web session storage.

[Philippe Cloutier <chealer@…>]

Replying to Jun Omae:

I disagree that draft data saving to Trac database.

Server-side storage does have a cost (bandwidth, storage and computing), but what matters is to make the frequency and retention configurable.

It is enough to save the drafts to web session storage.

Unfortunately, session storage is quite fragile. Obviously, if the storage device (HDD) crashes, its contents is likely lost, but there are many more scenarios where it is lost. Several factors worsen this:

1. Many browsers, including Firefox, defaulting not to resume sessions on startup. As ridiculous as this may be, I personally served several organizations even this decade (and even 1 IT organization) which had group policy preventing even developers from configuring Google Chrome to restore sessions.
2. Issue #9457
3. Trac’s failure to warn when closing a dirty tab/window or navigating away.

So, some scenarios likely sufficient to lose drafts even with session autosaves:

1. The PC rebooting
   1. due to a crash
   2. due to a Windows update
   3. due to a power failure
   4. due to an exhausted laptop battery
2. The browser restarting
   1. due to a crash
   2. because Firefox insists on upgrading
3. The tab/window being closed
   1. after attaching a file
   2. by accidentally closing the wrong tab/window
   3. after navigating to a link (for example, WikiFormatting).

[Jun Omae]

A duplicate of #9457.

• Enough to use web (local|session) storage to provide the feature.
• Feature should be provided as a plugin if it is able a feature via a plugin.
  • We should keep Trac core simple. If a feature would be added to Trac core, we must maintain it.
  • Trac is a lightweight project management tool (TracFeatures)
• Patch rather than just a idea (comment:3:ticket:9457)

[Philippe Cloutier <chealer@…>]

Replying to Jun Omae:

A duplicate of #9457.

This is not a duplicate of #9457. Duplicates report the same issue. While #9457 exposes this issue, solving #9457 would not solve this one (it would merely mitigate).

Please be careful when modifying tickets. If solving the issue tracked by ticket A would not necessarily solve the issue tracked by ticket B, then B should not be marked as a duplicate of A. #9457 was even mentioned in comment:2.

• Feature should be provided as a plugin if it is able a feature via a plugin.

It is unclear what you mean, but no, this should not be provided as a plugin. Autosaving comments is a basic feature, which even GitLab CE has provided for about a decade. Perhaps advanced elements (like a UI for retention configuration) can be provided via a plugin, but all basic autosave features (saving wiki pages, tickets and comments) should be built-in.

• We should keep Trac core simple. If a feature would be added to Trac core, we must maintain it.

Wherever this is added, it will need to be maintained. Adding it to the core ensures that occasional adaptations happen when they need to, rather than having a different developer fix things after a Trac release broke compatibility. Providing core features as plugins just because it is possible to do so creates dependency hell.

• Trac is a lightweight project management tool (TracFeatures)

If your concern is storage size, don't worry. Trac is much smaller than even the vast majority of browsers (including Firefox). Adding this will not even add 1 s to download times.

• Patch rather than just a idea (comment:3:ticket:9457)

What?