Defect #7293

Activity page displays wrong status of modified issues

Added by Etienne Massip about 6 years ago. Updated 21 days ago.

Status:NewStart date:2011-01-11
Priority:HighDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:Candidate for next minor release
Resolution: Affected version:1.1.0

Description

Constated on Redmin's main website and demo site as well :

In the Activity tab, the (New) entry displayed for an issue creation changes for a (Resolved) entry if issue's status is modify to be Resolved and so on...

E.g., look at item 7292 on today's page.

This is very weird, so maybe is it a browser (IE8) bug...although I rebooted.

7293-redmine_org.png (47.9 KB) Go MAEDA, 2011-02-08 03:29

activity_new_issue_event_status.patch Magnifier - v2 (5.75 KB) Etienne Massip, 2011-02-08 16:35

activity_new_issue_event_status.patch Magnifier - v3 (19.9 KB) Etienne Massip, 2011-03-05 14:32

activity_new_issue_event_status_v4.patch Magnifier - v4 (14.9 KB) Etienne Massip, 2011-03-30 21:38

History

#1 Updated by Etienne Massip about 6 years ago

This is not a bug, I still don't understand the way events are recorded but it seems that issue creation event displayed in the Activity page is a pseudo-event, meanin it is not stored in database.

Which is wrong is that the status displayed in the title of the issue creation event is the actual status of the issue !

Either the pseudo event object's status should be forced to "New" or a real event should be stored (better, imho) ?

#2 Updated by Etienne Massip about 6 years ago

Etienne Massip wrote:

This is not a bug, I still don't understand the way events are recorded but it seems that issue creation event displayed in the Activity page is a pseudo-event, meanin it is not stored in database.

Which is wrong is that the status displayed in the title of the issue creation event is the actual status of the issue !

Either the pseudo event object's status should be forced to "New" or a real event should be stored (better, imho) ?

I meant this IS a bug, this is NOT a browser bug.

#3 Updated by Etienne Massip about 6 years ago

Easy fix ?

--- Base (BASE)
+++ Locally Modified (Based On LOCAL)
@@ -42,7 +42,7 @@
                      :include => [:project, :journals],
                      # sort by id so that limited eager loading doesn't break with postgresql
                      :order_column => "#{table_name}.id" 
-  acts_as_event :title => Proc.new {|o| "#{o.tracker.name} ##{o.id} (#{o.status}): #{o.subject}"},
+  acts_as_event :title => Proc.new {|o| "#{o.tracker.name} ##{o.id} (#{IssueStatus.default}): #{o.subject}"},
                 :url => Proc.new {|o| {:controller => 'issues', :action => 'show', :id => o.id}},
                 :type => Proc.new {|o| 'issue' + (o.closed? ? ' closed' : '') }

#4 Updated by Etienne Massip about 6 years ago

Etienne Massip wrote:

Easy fix ?

[...]

Bad fix actually, initial status may be any status.

#5 Updated by Shujah zeb about 6 years ago

  • Assignee set to Etienne Massip
  • % Done changed from 0 to 30
h2. werewrerewrewrerew****
> > 
erererwe!ererewr!erewrer
rtrer-reter-ret-erter+retert_ertrtret*rtr*_+---retrtrt

#6 Updated by Etienne Massip about 6 years ago

  • File activity_new_issue_event_status.patch added
  • Assignee deleted (Etienne Massip)
  • % Done changed from 30 to 0

I got a working fix !

See attachment, simply added an initial_status() method to Issue to get the actual status the Issue was open with.

#7 Updated by Go MAEDA about 6 years ago

I experienced same bug.

It can be also seen on redmine.org's activity page.

#8 Updated by Etienne Massip about 6 years ago

v2, with test and fixtures (not exactly the same implementation, theoretically not as fast but simpler).

#9 Updated by Etienne Massip about 6 years ago

  • Target version set to Candidate for next minor release

#10 Updated by Jean-Philippe Lang about 6 years ago

I agree with this issue but I think the patch has an undesirable side-effect as it will show the initial issue status on search results as well.

#11 Updated by Etienne Massip about 6 years ago

You're right ! I'll post a better patch soon !

#12 Updated by Etienne Massip about 6 years ago

  • File deleted (activity_new_issue_event_status.patch)

#13 Updated by Etienne Massip about 6 years ago

  • File activity_new_issue_event_status.patch added

Ok, v3.

Sorry, but I didn't find a better way than separating the event concept from the searchable one.
I don't know if this is some desirable thing or not, though, even if I would tend to say that searchables are not events, please tell me.

Also added options.assert_valid_keys in acts_as_searchable and modified the class of the HTML div containing the datetime of the searchable from "author" to "datetime" (none have specific css style).

Tests pass.

#14 Updated by Etienne Massip about 6 years ago

  • File deleted (activity_new_issue_event_status.patch)

#15 Updated by Etienne Massip about 6 years ago

  • File activity_new_issue_event_status.patch added

#16 Updated by Etienne Massip about 6 years ago

  • File deleted (activity_new_issue_event_status.patch)

#18 Updated by Etienne Massip almost 6 years ago

v4, in a very different style, maybe much cleaner.

Test pass.

#19 Updated by Etienne Massip almost 6 years ago

Weird, modified files containing a single line are not displayed in the preview page, although they do on my local trunk server.

#20 Updated by Etienne Massip about 4 years ago

Note: could use r11412 to solve this.

#21 Updated by Gennady Grechin almost 3 years ago

This bug is still present in version 2.5.1. Within 3 years...

#22 Updated by Marcin Szewczyk 21 days ago

Hi, are there any plans to fix this upstream in versions 3.x?

Also available in: Atom PDF