Defect #7293
openActivity page displays wrong status of modified issues
Added by Etienne Massip almost 14 years ago. Updated over 7 years ago.
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.
Files
7293-redmine_org.png (47.9 KB) 7293-redmine_org.png | Go MAEDA, 2011-02-08 03:29 | ||
activity_new_issue_event_status.patch (5.75 KB) activity_new_issue_event_status.patch | v2 | Etienne Massip, 2011-02-08 16:35 | |
activity_new_issue_event_status.patch (19.9 KB) activity_new_issue_event_status.patch | v3 | Etienne Massip, 2011-03-05 14:32 | |
activity_new_issue_event_status_v4.patch (14.9 KB) activity_new_issue_event_status_v4.patch | v4 | Etienne Massip, 2011-03-30 21:38 |
Updated by Etienne Massip almost 14 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) ?
Updated by Etienne Massip almost 14 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.
Updated by Etienne Massip almost 14 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' : '') }
Updated by Etienne Massip almost 14 years ago
Etienne Massip wrote:
Easy fix ?
[...]
Bad fix actually, initial status may be any status.
Updated by Shujah zeb almost 14 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
Updated by Etienne Massip almost 14 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.
Updated by Go MAEDA almost 14 years ago
- File 7293-redmine_org.png 7293-redmine_org.png added
I experienced same bug.
It can be also seen on redmine.org's activity page.
Updated by Etienne Massip almost 14 years ago
v2, with test and fixtures (not exactly the same implementation, theoretically not as fast but simpler).
Updated by Etienne Massip over 13 years ago
- Target version set to Candidate for next minor release
Updated by Jean-Philippe Lang over 13 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.
Updated by Etienne Massip over 13 years ago
You're right ! I'll post a better patch soon !
Updated by Etienne Massip over 13 years ago
- File deleted (
activity_new_issue_event_status.patch)
Updated by Etienne Massip over 13 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.
Updated by Etienne Massip over 13 years ago
- File deleted (
activity_new_issue_event_status.patch)
Updated by Etienne Massip over 13 years ago
- File activity_new_issue_event_status.patch added
Updated by Etienne Massip over 13 years ago
- File deleted (
activity_new_issue_event_status.patch)
Updated by Etienne Massip over 13 years ago
Updated by Etienne Massip over 13 years ago
v4, in a very different style, maybe much cleaner.
Test pass.
Updated by Etienne Massip over 13 years ago
Weird, modified files containing a single line are not displayed in the preview page, although they do on my local trunk server.
Updated by Etienne Massip over 11 years ago
Note: could use r11412 to solve this.
Updated by Gennady Grechin over 10 years ago
This bug is still present in version 2.5.1. Within 3 years...
Updated by Marcin Szewczyk over 7 years ago
Hi, are there any plans to fix this upstream in versions 3.x?