Tickets and ticket comments are not saved automatically

[chealer]

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

Good ITSs 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 here, either in Trac’s 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 when Microsoft Windows helpfully took the initiative to reboot. I am therefore confident that this website 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, this is caused by a missing Trac feature tracked in ​ticket #13891.

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 on the server.

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

Solution

Unfortunately, I dug into Trac’s ITS while filing the above ticket, which revealed it is in a pretty bad shape (see notably issues ​#13888, ​#13889 and ​#13892). I would not expect a solution from upstream this decade.

In fact, Trac’s situation looks so bad that I suggest considering switching to a different engine. Unfortunately, I don’t know any option as good as JetBrains YouTrack.

---

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

[chealer]

This was initially reported as ticket #8185, which was lost (as reported in ticket #8196).

[dd32]

Hello,

We're not the Authors of Trac, this is the Trac for reporting issues on the WordPress.org Website.

You're looking for ​https://trac.edgewall.org/

[chealer]

Hi Dion,

Replying to dd32:

Hello,

We're not the Authors of Trac, this is the Trac for reporting issues on the WordPress.org Website.

This is a report for the Meta team, ​which “is responsible for maintaining and managing WordPress.org websites”, including this Trac instance. Trac is free software; anyone can improve it―thankfully, since Trac’s authors seem to have abandoned it years ago.

Regardless of whether Trac’s authors help or whether this gets solved in upstream Trac, the only team which can solve this alone is this one.

You're looking for ​https://trac.edgewall.org/

Thank you for reading reports before marking them as invalid

[dd32]

I'll close this as wontfix then.

We're not interested in adding additional complexity to our WordPress Trac instances at this time.

Your report does not suggest this was a WordPress-Trac-specific report, but rather a Trac-specific feature request.

[chealer]

Replying to dd32:

I'll close this as wontfix then.

What do you mean?

We're not interested in adding additional complexity to our WordPress Trac instances at this time.

Nobody asked anyone to add additional complexity to WordPress Trac instances at any time. This merely tracks the lack of autosaves in WordPress’s ITSs (which complicates usage of WordPress issue trackers).

Your report does not suggest this was a WordPress-Trac-specific report, but rather a Trac-specific feature request.

As the report’s Solution section suggests, this is neither. At the risk of being simplistic, Trac was abandoned years ago. Ideally, WordPress issue trackers would migrate to a healthy engine.