Redmine

+1
I think it's very important. Legally we can need to prove something.
I think also that only my last note of an issue can be modified. It's inconsistent to modify a note edited although another has been written after.

+1
it's very useful, and every notes will be kept. History is very important.
So everyone can edit every notes safely.

+1
It's very useful. History is very important.

• I understand that the ability to edit the notes is from #527, #585 and #627.
• This edition of the notes permits to modify a note in case of mistake without having other entry in the log of history.
• As a consequence, having an history on the edition of a note is contradictory with the ability to edit in the current model of Redmine.

• adapt to the note the system of history that belongs to the wiki
• so we can have a link "History" next to the buttons "Quote" and "Modify"

+1
Sometimes content gets deleted accidently from comments. It would be very helpful, if these changes were also logged so content could get restored.

+1 (#6945)

+1
Would be great!

+1 would be very helpful Feature!

+1 If somebody edits a comment it should at least be visible to others.

+1 but only to indicate the message as "Edited" and show when it was edited, but maybe not to log the history of the edits of each message changes. They are usually not really necessary to store and it would generally be more rubbish to fill the database with.
However a mechanism which could be implemented on the front-end which could save the fields of an not yet posted form as real-time draft into the local storage and then read on next reload would be amazing.

Bernhard Rohloff wrote:

+1 If somebody edits a comment it should at least be visible to others.

I've added a patch to #31505 which implements this feature.

Since many issues on this have been opend and closed as duplicate in the last 10 years, I think there is a true need for that feature.

The Company I work at is also obliged to save all informations that is relevant to quality management including everything from our Redmine instance. We had to deactivate the edit button for comments, which lead to frustration when collegues where not able to correct their typos.

I've no experience in Ruby development, but I might be able to get it done with some help.

Could any experienced contributer just give me a highlevel rundown of what changes I would need to make to the codebase?

+1

+1

+1

I generally like the idea. An edit history for journal notes is something that I think Redmine core is currently missing.

A few thoughts after looking at the patch:

• The history currently does not show who modified a note and when it was modified.
  In the current JS view, I would initially assume that the displayed author and timestamp refer to the edit being viewed.
  Instead, they appear to refer to the user and timestamp of the latest edit.
• If edit authors and edit timestamps become part of the history, the purpose of updated_on and updated_by_id becomes less clear and may need to be reconsidered.
• I like the JS-based approach because it allows reviewing note changes without leaving the current issue page. That said, I'm not a big fan of displaying all revisions as inline expandable diffs.
• It could be useful to provide a comparison view between the first and the latest version of a note.
• For long notes, the current JS view may become difficult to navigate. Something similar to the wiki history view, where specific versions can be selected and compared, might scale better.
• One additional concern is that all corresponding JournalDetail records are currently preloaded, including the full old and new text values used for note history. For the common case where only an "edited" indicator or link is displayed, loading the complete history may not be necessary.
• Looking at #44274, another possible direction could be to store note edits as a dedicated journalized type instead of keeping the full history in JournalDetails. This would naturally provide authorship and timestamps for each edit, allow lazy loading of revision history, and further reduce Journal's responsibility for note-specific behavior.

Overall, I think having journal note edit history available in core would be a valuable addition.

+1 from me. I really like this feature, and I consider proper revision history for journal notes essential if Redmine is to be relied upon as part of an ISO-certified management system.

This is particularly important to me because the company I work for is currently evaluating to what extent we can rely on Redmine for processes and records that form part of our ISO certification. From that perspective, complete auditability and traceability of changes are not merely nice-to-have features.

For that reason, I fully agree with the previous comment that the history should record who made each edit, in addition to when it was made. In most cases, the editor will probably be the same user who originally wrote the note, but from an audit and traceability perspective, this cannot be assumed. The history itself should provide that information explicitly.

I also think we should separate the question of how the diff is displayed from how the revision history is stored. The proposed JS-based approach and the existing Wiki diff/history UI are different implementations of essentially the same concept. In the longer term, I would strongly prefer Redmine to have one consistent and reusable diff/history viewer for all types of text-based revision history, rather than maintaining separate implementations depending on whether the content happens to be a Wiki page, an issue description, or a journal note.

Regarding the underlying implementation, I am also leaning towards the approach proposed in #44274. Decoupling Journal from Issue and making journaling reusable for different journalized models seems like a much better foundation than implementing note history as another special case inside JournalDetail.

If journal note revisions can become proper journalized records, with their own author and timestamp, while sharing a common revision/diff UI with other revisioned content, I think that would provide both a cleaner architecture and the level of traceability needed for serious quality-management use cases.