I looked into implementing this, and it might have to get a little invasive. I was thinking instead of setting @issue_before_change in init_journal, do something like:
<pre>
attr_reader :original_attributes
def after_find
original_attributes = attributes
end
</pre>

Then anywhere you need to, you can access the original_attributes hash to see what's being changed with this save. So in before_save, you could:

<pre>closed_at = Time.now if IssueStatus.find(original_attributes.status_id).is_closed? && !self.closed</pre>

Or to save some syntax you could clone the whole issue into an :original_issue attr_reader.
--------------------------------------------------------------------------------
What would happen if you reopen the issue?
--------------------------------------------------------------------------------
Henrique Bastos wrote:
> What would happen if you reopen the issue?

The answer to this question seems obvious, but I suppose it might as well be stated....

In that case it would maintain it's previous closed_on attribute, which would be updated again later if/when it is re-closed. The fact that the issue was reopened does not change the fact that it was once closed.

--------------------------------------------------------------------------------
I'm not sure I agree. If I search for issues closed in the last 7 days, I don't think I should need a separate filter to constrain the search to issues that are currently closed, and I don't think the data in closed_on is useful for issues that aren't closed.
--------------------------------------------------------------------------------
As mentioned in #4730, this feature is provided by the "Issue Closed Date plugin":http://www.redmine.org./plugins/closed_date
--------------------------------------------------------------------------------
+1 for core implementation.
--------------------------------------------------------------------------------
Two things to add here:

# I agree with leaving a closed field populated even after reopening. Requiring an extra filter is added robustness, not tedium, and allows you to rapidly filter issues that were previously closed regardless of their current status. Everything gained by keeping this value recorded outweighs this one extra act of filtering for one particular use case.
# I highly recommend the Custom Workflows plugin to achieve this in the meantime. It's much more versatile than a dedicated plugin for this purpose, and is much more likely to maintained (already the Issue Closed Date plugin is far out of date). If using this plugin, here's my junky contribution to the topic:

<pre>if @issue.status_id_changed?
if @issue.closing?
@issue.custom_field_values = {'1' => Time.now.strftime("%Y-%m-%d")}
# Where 1 is the ID of a 'closed on' date custom field
end
end
</pre>

Create a custom field, date type, for the closing date value. Make note of its ID. Create a new custom workflow with the above in the before-saving box, replacing the ID with the one you'll be using. Enable the field and the script on whatever trackers and projects you want this recorded for.

I advise this over a single-use plugin because this one plugin will give you this _plus_ everything else it can do, and that means more customization with fewer plugin dependencies in your Redmine build.
--------------------------------------------------------------------------------
Henrique Bastos wrote:
> What would happen if you reopen the issue?

Always show the date of last closed status. If never has been closed before, don't show any date.
+1
--------------------------------------------------------------------------------
Feature added.

Filou Centrinov wrote:

> Always show the date of last closed status. If never has been closed before, don't show any date.

This is how it was implemented as most people requested this behaviour. The closed_on column is preserved when the issue is reopened.
--------------------------------------------------------------------------------
For roadmap/changelog: extending subject to better circumscribe the new feature.
--------------------------------------------------------------------------------
It would be very usefull to be able to change the closed_on date as we can change the start and due dates (for example if someone forgot to close the issue and we want to record the real closed_on date).
--------------------------------------------------------------------------------
Bruno Spyckerelle wrote:
> It would be very usefull to be able to change the closed_on date as we can change the start and due dates (for example if someone forgot to close the issue and we want to record the real closed_on date).

Please open a new feature request for this. This issue is completed and released.
--------------------------------------------------------------------------------
Mischa The Evil wrote:
> Bruno Spyckerelle wrote:
> > It would be very usefull to be able to change the closed_on date as we can change the start and due dates (for example if someone forgot to close the issue and we want to record the real closed_on date).
>
> Please open a new feature request for this. This issue is completed and released.

FTR: There is #8002 already.
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

relates,Closed,20210,Issue closed_on date is not reset after issue is reopened
relates,Closed,31420,issues-table; closed_on - column should be updated to NULL whenever issue's status is changed to a 'is_closed == 0' status
duplicates,Closed,13014,Record issue closing date
duplicates,Closed,2225,Provide a Date Closed element for queries
blocks,Closed,4730,Add Closed Date to Issue Filter
blocks,New,6795,View issue close date on the gantt view
blocks,New,5705,Display Issue Closed Date on Calendar View