Redmine

Greg T wrote:

When you have a journal entry with both notes and property changes, this code in application.js hides it completely on the property changes tab.

I agree that "Property changes" tab should not skip journals that have notes.

OTOH, property changes won't be hidden on the notes tab for this entry.

But I prefer the current behavior. I want to just exclude journals without notes in "Notes" tab. Changes in fields such as status and assignee are important information even in "Notes" tab.

Hiding property changes completely in the notes tab is a big change, so I am concerned that many users (including me :)) may complain. How about changing only "Property changes" tab with the following patch for now?

diff --git a/public/javascripts/application.js b/public/javascripts/application.js
index ac2d5f8b0..6ac145f00 100644
--- a/public/javascripts/application.js
+++ b/public/javascripts/application.js
@@ -371,15 +371,18 @@ function showIssueHistory(journal, url) {

   switch(journal) {
     case 'notes':
+      tab_content.find('.journal').show();
       tab_content.find('.journal:not(.has-notes)').hide();
-      tab_content.find('.journal.has-notes').show();
+      tab_content.find('.journal .wiki').show();
       break;
     case 'properties':
-      tab_content.find('.journal.has-notes').hide();
-      tab_content.find('.journal:not(.has-notes)').show();
+      tab_content.find('.journal').show();
+      tab_content.find('.journal:not(.has-details)').hide();
+      tab_content.find('.journal .wiki').hide();
       break;
     default:
       tab_content.find('.journal').show();
+      tab_content.find('.journal .wiki').show();
   }

   return false;

Go MAEDA wrote:

Hiding property changes completely in the notes tab is a big change, so I am concerned that many users (including me :)) may complain. How about changing only "Property changes" tab with the following patch for now?

Do as you please. I'd still find that counter-intuitive, but I don't even need these tabs, so I could live with that.

This is a tricky issue consisting of two independent but inter-related parts:

1. journals with both notes and property changes are not shown on the property changes tab
2. journals with both notes and property changes are shown on the notes tab with property changes

Regarding the first: I agree with Go MAEDA and Greg T that this is a true issue.
Regarding the second: I agree with Greg T that this might be counter-intuitive (from a consistency perspective), however, given the goal of the notes tab (and the other inconsistencies that are already present [eg. attachments and issue relations "being tracked" as file/relation properties, associated revisions/time entries "being tracked" as if they are journals, etc.]), I agree with Go MAEDA that, from a usability perspective, this inconsistency is (desirable and) acceptable.

Translating the above into a redefinition of what should be rendered in which tabs would look like:

Tab:	What to render:
Notes	journals with notes, with their property changes
Property changes	journals with property changes, without their notes

Regarding the posted solutions, both of them have one or more side-effects that might need to be taken care of. There might be others too.

Solution:	Side-effect(s):
by Greg T (history_tabs.patch)	thumbnails are rendered for journals on property changes tab1
by Go MAEDA (#33338#note-2)	thumbnails are rendered for journals on property changes tab1
	journal action buttons (which are in fact journal note action buttons) are rendered for journals on property changes tab2

Alternative patch incorporating solutions for both side-effects mentioned in the table above:

 public/javascripts/application.js | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/public/javascripts/application.js b/public/javascripts/application.js
index e4e902d..66b254a 100644
--- a/public/javascripts/application.js
+++ b/public/javascripts/application.js
@@ -371,15 +371,24 @@ function showIssueHistory(journal, url) {

   switch(journal) {
     case 'notes':
+      tab_content.find('.journal').show();
       tab_content.find('.journal:not(.has-notes)').hide();
-      tab_content.find('.journal.has-notes').show();
+      tab_content.find('.journal .wiki').show();
+      tab_content.find('.journal .thumbnails').show();
+      tab_content.find('.journal .contextual .journal-actions').show();
       break;
     case 'properties':
-      tab_content.find('.journal.has-notes').hide();
-      tab_content.find('.journal:not(.has-notes)').show();
+      tab_content.find('.journal').show();
+      tab_content.find('.journal:not(.has-details)').hide();
+      tab_content.find('.journal .wiki').hide();
+      tab_content.find('.journal .thumbnails').hide();
+      tab_content.find('.journal .contextual .journal-actions').hide();
       break;
     default:
       tab_content.find('.journal').show();
+      tab_content.find('.journal .wiki').show();
+      tab_content.find('.journal .thumbnails').show();
+      tab_content.find('.journal .contextual .journal-actions').show();
   }

   return false;

¹ thumbnails shouldn't be rendered in this tab IMHO

² the buttons make the journal appear as if the property changes can be altered, while these buttons affect/relate to the journal notes only (leading to all kinds of weird behavior)

Thank you all for the feedback on this. The solution proposed by Mischa sounds good to me (I didn't test the patch yet).

Mischa The Evil wrote:

[...], however, given the goal of the notes tab (and the other inconsistencies that are already present [eg. attachments and issue relations "being tracked" as file/relation properties, associated revisions/time entries "being tracked" as if they are journals, etc.]), [...]

Mischa, how do you see a better implementation of this feature? Maybe we can improve it in the following releases.