Can sort order of change history be reversed

[trac@…]

The sort order of the change history (of tickets) is now such that the latest change is (nearly) at the bottom of the page.

Since I am almost always most interested in the latest change(s), could it be made a configuration option to have the latest change at the top?

[Christian Boos]

It has been decided a while ago to list the history of changes in chronological order, which is easier to read when you see a ticket for the first time and try to follow what happened, especially the sequence of questions/replies.

In order to modify this default, I think that a user setting would be more appropriate than a server side configuration option.

Alternatively, we could have that triangular switch next to the Change History title, for changing the display order in a case by case way.

Finally, note that latest trunk will directly lead you to the latest change, when you click on a ticket event in the Timeline, in a RSS Feed reader, or on the URL in a notification mail, so the location of that latest change in the ticket page is not that important.

[Christian Boos]

#5053 closed as duplicate.

[Christian Boos]

#7565 closed as duplicate.

(as usual for the milestone, if someone provides a patch, feel free to move it to an earlier milestone)

[Christian Boos]

This is the typical situation of something which would be better defined as a user preference.

It's time we get a new 'User Interface' tab, with some groups Ticket, Wiki, etc.

The Options could get a new flag user to indicate that the setting is configurable and at the same time give the corresponding translatable label, so that we can collect them automatically to populate the above tab.

Finally, we could create some Section descriptors, similar to Option but for documenting the sections and, useful here, get a translated name for the corresponding user configuration section.

e.g.

    section = Section('ticket', N_('Ticket Settings'))

    chronological_order = BoolOption('ticket', 'chronological_order',
        default=True, 
        user=N_("Show Change History in Chronological Order"),
        doc="""Controls in which direction the Change history is displayed. ''(since 0.13)''""")

[Evgenij <evgenij.fokin@…>]

When ticket has a lot of comments it's waste of time to scroll a well known history every time when you need to read a new comment.

The ticket has been created 5 years ago. Is it really difficult enhancement?

[Mikael Relbe]

Replying to Evgenij <evgenij.fokin@…>:

When ticket has a lot of comments it's waste of time to scroll a well known history every time when you need to read a new comment.

I usually press the "Change" link to the right of the ticket id header; scrolling a bit upwards reveals the last comment(s). Works quite ok, I think.

[psuter <petsuter@…>]

Patch against r10730 adding a prefs box with user settings Reverse sort order and View comments only

[psuter <petsuter@…>]

Screenshots of above patch (and one alternative mockup)

[psuter <petsuter@…>]

I started experimenting with the patch above, adding a prefs box (similar to e.g. the one on timeline) to the Change history. As you can see in the above screenshots it includes a Reverse sort order and a (unrelated to this ticket) View comments only setting.

Only then did I remember about the Threaded Comments checkbox, which ignores the reverse sort order and also makes the UI look quite inconsistent. I briefly tried to move my new options to a more consistent place (also shown in the above screenshots in the bottom right corner.) However with that approach I guess one should implement this in JQuery and get rid of the Update button, too.

Finally, only now have I remembered about comment:4 by cboos above:

new 'User Interface' tab

As the options do start to take up a lot of space and get cramped up otherwise, I now guess that would in a way make more sense, too.

[Remy Blank]

Replying to psuter <petsuter@…>:

… and a (unrelated to this ticket) View comments only setting.

Funny, I was thinking just yesterday that such a setting would be very useful, after reading a few tickets that consisted mostly of description edits.

The option box indeed looks awkward.

I briefly tried to move my new options to a more consistent place (also shown in the above screenshots in the bottom right corner.) However with that approach I guess one should implement this in JQuery and get rid of the Update button, too.

Yes, we could require JavaScript for this functionality. It's still a bit inconsistent, because "Threaded comments" and "Reverse sort order" are mutually exclusive, but "View comments only" is independent. Using checkboxes that uncheck other checkboxes is not a good UI design, in theory you should use three radio buttons (Ascending, Descending, Threaded) or a combo box.

Finally, only now have I remembered about comment:4 by cboos above:

new 'User Interface' tab

As the options do start to take up a lot of space and get cramped up otherwise, I now guess that would in a way make more sense, too.

The preference tab would allow setting the per-user default value of the settings, but you would probably still want to be able to change them temporarily when viewing a ticket.

[psuter <petsuter@…>]

Replying to rblank:

The option box indeed looks awkward.

Maybe it would help to move it to the right, outside the parent's borders.

"Threaded comments" and "Reverse sort order" are mutually exclusive

Not necessarily, if both are activated the comments could be ordered like this:

• second message
  • second reply
  • first reply
• first message

[Remy Blank]

Replying to psuter <petsuter@…>:

Not necessarily, if both are activated the comments could be ordered like this:

Mmh… Nah, you don't want that. It looks like top-posting :)

[psuter <petsuter@…>]

JavaScript implementation of prefs box with radio buttons

[psuter <petsuter@…>]

Replying to rblank:

Yes, we could require JavaScript for this functionality. It's still a bit inconsistent, because "Threaded comments" and "Reverse sort order" are mutually exclusive, but "View comments only" is independent. Using checkboxes that uncheck other checkboxes is not a good UI design, in theory you should use three radio buttons (Ascending, Descending, Threaded) or a combo box.

This new patch​ uses JavaScript to implement this with radio buttons. It's still a prefs box, but now outside the main box. (This looks nicer to me, but using margin-right: -15em feels ugly. Can it be done in some cleaner way?)

[Remy Blank]

I'll test the patch, but not today. Too tired :)

[Christian Boos]

Very nice! I have a few follow-up suggestions however.

• the meaning of Ascending vs. Descending was not immediately obvious to me; I'd prefer Oldest first and Newest first
• the placement trick of -15em didn't work for me (​TH:WikiExtrasPlugin forces the #prefs margin…), but that's not a problem because I don't think it's such a good idea to place it outside the #content ;-) It's perhaps nice visually when you have a wide page, but otherwise you can easily miss it on a narrow one, so I'd suggest that we use a more vertically compact #prefs panel instead
• there was a problem when switching to "Threaded" and back when "Comments only" was already selected, in presence of changes without comment having a follow-up: all the comments in these follow-up changes were also hidden
• the "un-threading" done at the occasion of the automatic preview was broken by the transition from checkbox to radiobutton
• better use <label for=...>Label than <label><input />Label, as it's nicer for i18n
• finally, I think it's really important to have the selected order saved in the session; imagine someone going through a ticket list, she would expect to keep using that order after having set it once

prefs-box-javascript-follow-up.patch​ addresses all those points but the last.

[Christian Boos]

a few follow-ups to attachment:prefs-box-javascript.patch​

[psuter <petsuter@…>]

Replying to cboos:

• I'd prefer Oldest first and Newest first
• I'd suggest that we use a more vertically compact #prefs panel instead

Looks great.

• there was a problem when switching to "Threaded" and back when "Comments only" was already selected, in presence of changes without comment having a follow-up
• the "un-threading" done at the occasion of the automatic preview was broken

I must have been tired myself. :) Thanks for fixing.

[psuter <petsuter@…>]

Save to session (on top of attachment:prefs-box-javascript-follow-up.patch​)

[psuter <petsuter@…>]

Replying to cboos:

• finally, I think it's really important to have the selected order saved in the session;

prefs-box-javascript-save-session.patch​ should apply on top of your follow ups and saves / loads the preferences to /from the session. (If the saved preferences are threaded, fall back to oldest.)

[psuter <petsuter@…>]

Replying to psuter <petsuter@…>:

(If the saved preferences are threaded,

… and there are no threaded replies …

fall back to oldest.)

[Remy Blank]

This works pretty well. I have a few comments:

• The un-threading on automatic preview still doesn't work reliably. Even though the un-threading happens, the controls remain as they were before. And at some point, through some kind of combination of entering text in the comment box and changing the changlog order, I ended up with threaded comments with newest comments first!
• The prefs box pushes the "comment: 1 follow-up: 39" text to the left, which doesn't look too good. Adding clear:both to the CSS for #prefs pushes the whole changelog down, which leaves an ugly gap, so that's not a solution either. How about using a <select> instead of radio buttons, so that the checkbox could be placed on the same line?
• The AJAX request to save the preferences has a dataType of "json", but the request doesn't return any data. This is flagged by Firefox as an error. We should rather set a type of "text".

To facilitate working together on this, I have imported the three patches above into branch ticket-3360 of my repository.

[Christian Boos]

Replying to rblank:

This works pretty well. I have a few comments:

• The un-threading on automatic preview still doesn't work reliably. Even though the un-threading happens, the controls remain as they were before. And at some point, through some kind of combination of entering text in the comment box and changing the changlog order, I ended up with threaded comments with newest comments first!

Funny ;-)

Well, and also do we really need this un-threading?

• The prefs box pushes the "comment: 1 follow-up: 39" text to the left, which doesn't look too good. Adding clear:both to the CSS for #prefs pushes the whole changelog down, which leaves an ugly gap, so that's not a solution either. How about using a <select> instead of radio buttons, so that the checkbox could be placed on the same line?

Are you using ​TH:WikiExtrasPlugin by any chance? I also see this, but it's clearly a side effect of that plugin; I think it's a problem that needs to be fixed there.

The other possibility would be your custom font size ;-)

• The AJAX request to save the preferences has a dataType of "json", but the request doesn't return any data. This is flagged by Firefox as an error. We should rather set a type of "text".

… and perhaps we even need to come up with a set of utility functions and a generic handler for this (in /prefs?)

To facilitate working together on this, I have imported the three patches above into branch ticket-3360 of my repository.

Perfect, thanks!

[Remy Blank]

Replying to cboos:

Well, and also do we really need this un-threading?

I think so. The reason for the un-threading is that we fetch new comments and highlight them so the user sees that there are concurrent edits. If we didn't unthread, the new comments could end up anywhere in the changelog (or at the very top when sorting by descending time), so they would be invisible to the user.

Are you using ​TH:WikiExtrasPlugin by any chance? I also see this, but it's clearly a side effect of that plugin; I think it's a problem that needs to be fixed there.

The other possibility would be your custom font size ;-)

Neither the plugin, nor my font size. The same happens on Chromium, where I didn't tune the fonts.

… and perhaps we even need to come up with a set of utility functions and a generic handler for this (in /prefs?)

We could do that, yes.

[Christian Boos]

Replying to rblank:

Replying to cboos:

Well, and also do we really need this un-threading?

I think so. The reason for the un-threading is that we fetch new comments and highlight them so the user sees that there are concurrent edits. If we didn't unthread, the new comments could end up anywhere in the changelog (or at the very top when sorting by descending time), so they would be invisible to the user.

Ok, I remember now ;-) Perhaps we simply need to disable the controls in the #prefs while updating the #changelog?

Are you using ​TH:WikiExtrasPlugin by any chance? I also see this, but it's clearly a side effect of that plugin; I think it's a problem that needs to be fixed there.

The other possibility would be your custom font size ;-)

Neither the plugin, nor my font size.

Ok, we need to tweak this further then.

[psuter <petsuter@…>]

Replying to rblank:

• The un-threading on automatic preview still doesn't work reliably.

I think un-threading works, but it also needs to be un-reversed.

• The AJAX request to save the preferences has a dataType of "json", but the request doesn't return any data. This is flagged by Firefox as an error. We should rather set a type of "text".

Right, a Content-Type header was required to make Firefox happy here.

Fixed ​here and ​here.

• The prefs box pushes the "comment: 1 follow-up: 39" text to the left,

Doesn't happen here on Windows with Firefox 5 or Chrome 12, but it does with IE8. Oh, when changing Zoom factor it unpredictably happens in all of them.

[psuter <petsuter@…>]

Replying to psuter <petsuter@…>:

Replying to rblank:

• The prefs box pushes the "comment: 1 follow-up: 39" text to the left,

Doesn't happen here on Windows with Firefox 5 or Chrome 12, but it does with IE8. Oh, when changing Zoom factor it unpredictably happens in all of them.

After some ​tweaking it kind of works in all three browsers here, at any zoom level. (The prefs box overlaps the first "comment: 1" a tiny bit in IE8 or when far zoomed out. Doesn't seem too bad though.)

[Peter Suter]

Replying to cboos:

Replying to rblank:

• The AJAX request to save the preferences has a dataType of "json", but the request doesn't return any data. This is flagged by Firefox as an error. We should rather set a type of "text".

… and perhaps we even need to come up with a set of utility functions and a generic handler for this (in /prefs?)

In my repository I added Request.send_no_content() for sending a 204 HTTP response and a generic /prefs handler that saves any req.args to the session. Was this about what you had in mind here?

[Peter Suter]

If there are no further concerns I'll soon commit this to trunk. (​diff)

[Remy Blank]

Just one doubt: do you use a GET request to save the preferences? This opens the door to XSRF attacks. Normally, all mutating operations must use POST requests, and must include the __FORM_TOKEN. The token should be available in JavaScript in the global variable form_token, and can be passed with the request.

[Peter Suter]

Replying to rblank:

Just one doubt: do you use a GET request to save the preferences? This opens the door to XSRF attacks. Normally, all mutating operations must use POST requests, and must include the __FORM_TOKEN. The token should be available in JavaScript in the global variable form_token, and can be passed with the request.

Right, thanks. Does this look ok?

Edit: Oops, I forgot to require POST requests. Added here. (​Full diff)

[Remy Blank]

Replying to psuter:

Right, thanks. Does this look ok?

Yep, looks about right :)

[Peter Suter]

Applied in [10989].

[Ryan J Ollos]

Normalizing keywords.