Redmine

The attached patch adds the add_note_to_closed_issue permission.
Only if you do not have the add_note_to_closed_issue permission, you cannot add notes to closed issues.

Go MAEDA wrote in #note-5:

Maybe this should be controlled by a tracker base rather than permission. To me, whether to accept comments or not when the issue is closed appears to be an element that defines the nature of an issue.

Here is a patch to add an "Allow comments on closed issues" option for each tracker.

The attached patch adds a per‑tracker setting to allow or disallow adding notes on closed issues. By making this setting configurable per tracker, teams can apply different rules for each type of work. It also keeps behavior consistent across projects because the same tracker enforces the same rule everywhere.

• It introduces an "Allow notes on closed issues" option for trackers. The option is enabled by default, so the behavior is compatible with the current version of Redmine.
• The notes field is hidden in the edit form when the issue is closed, and users cannot add notes.
• Notes can be added when closing an issue or reopening a closed issue.

Go MAEDA wrote in #note-9:

Thank you for the feedback.

The main reason I chose a tracker-level setting is that permission-based solutions (including Fields permissions) do not apply to users with Administrator privileges. For this feature, consistency across all users is important, because the risk of missed notes on closed issues exists regardless of role.

Administrators are administrators, they can do mostly what they want and adding a note to a closed issue is not something worst or better than other roles or trackers based permissions. Perhaps instead of implementing this change just because Admins can bypass it, we should eventually look at having an "Admin mode" (similar to sudo) so that even administrators operate under standard role restrictions unless they explicitly elevate their session.

Another reason is that Redmine already has a similar precedent: under Admin > Settings > Time tracking, the "Accept time logs on closed issues" setting controls behavior on closed issues independently of workflows and permissions.

Indeed, this is true, but for time logs we have a very basic permission scheme. From my experience with time logs in organisations, there are quite often cases when someone needs to bypass this kind of restrictions.

Maybe we can have more feedback about this before choosing one or another solution, especially because it depends a lot on the context, for some company this is good enough, for other not.