Edgewall Software
Modify

Opened 11 years ago

Closed 6 years ago

Last modified 3 years ago

#3360 closed enhancement (fixed)

Can sort order of change history be reversed

Reported by: trac@… Owned by: Peter Suter
Priority: high Milestone: 1.0
Component: ticket system Version:
Severity: minor Keywords: option, trac.ini, preferences
Cc: martin@…, itamarost@…
Release Notes:
API Changes:

Description

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?

Attachments (5)

prefs-box-reversedsortorder-viewcommentsonly.patch (5.5 KB ) - added by psuter <petsuter@…> 6 years ago.
Patch against r10730 adding a prefs box with user settings Reverse sort order and View comments only
prefs-box-reversedsortorder-viewcommentsonly.png (63.8 KB ) - added by psuter <petsuter@…> 6 years ago.
Screenshots of above patch (and one alternative mockup)
prefs-box-javascript.patch (4.0 KB ) - added by psuter <petsuter@…> 6 years ago.
JavaScript implementation of prefs box with radio buttons
prefs-box-javascript-follow-up.patch (6.9 KB ) - added by Christian Boos 6 years ago.
a few follow-ups to attachment:prefs-box-javascript.patch
prefs-box-javascript-save-session.patch (4.2 KB ) - added by psuter <petsuter@…> 6 years ago.
Save to session (on top of attachment:prefs-box-javascript-follow-up.patch)

Download all attachments as: .zip

Change History (39)

comment:1 Changed 11 years ago by Christian Boos

Milestone: 0.11
Owner: changed from Jonas Borgström to Christian Boos
Priority: normallow
Severity: normalminor

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.

comment:2 Changed 11 years ago by Christian Boos

#5053 closed as duplicate.

comment:3 Changed 9 years ago by Christian Boos

Milestone: 0.11.30.13
Owner: Christian Boos deleted
Priority: lownormal

#7565 closed as duplicate.

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

comment:4 Changed 7 years ago by Christian Boos

Keywords: option tracini user preferences added
Owner: set to Christian Boos
Priority: normalhigh

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)''""")

comment:5 Changed 7 years ago by Christian Boos

Keywords: userpreferences added; user preferences removed

comment:6 Changed 7 years ago by Martin Scharrer <martin@…>

Cc: martin@… added

comment:7 Changed 7 years ago by Itamar Ostricher

Cc: itamarost@… added

comment:8 Changed 6 years ago by 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?

comment:9 in reply to:  8 Changed 6 years ago by 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.

Changed 6 years ago by psuter <petsuter@…>

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

Changed 6 years ago by psuter <petsuter@…>

Screenshots of above patch (and one alternative mockup)

comment:10 Changed 6 years ago by 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.

comment:11 in reply to:  10 ; Changed 6 years ago by 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.

comment:12 in reply to:  11 ; Changed 6 years ago by 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

comment:13 in reply to:  12 Changed 6 years ago by 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 :)

Changed 6 years ago by psuter <petsuter@…>

Attachment: prefs-box-javascript.patch added

JavaScript implementation of prefs box with radio buttons

comment:14 in reply to:  11 Changed 6 years ago by 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?)

comment:15 Changed 6 years ago by Remy Blank

Milestone: next-major-0.1X0.13
Owner: changed from Christian Boos to Remy Blank

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

comment:16 Changed 6 years ago by 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.

Changed 6 years ago by Christian Boos

comment:17 in reply to:  16 Changed 6 years ago by 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.

Changed 6 years ago by psuter <petsuter@…>

comment:18 in reply to:  16 ; Changed 6 years ago by 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.)

comment:19 in reply to:  18 Changed 6 years ago by psuter <petsuter@…>

Replying to psuter <petsuter@…>:

(If the saved preferences are threaded,

… and there are no threaded replies …

fall back to oldest.)

comment:20 Changed 6 years ago by 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.

comment:21 in reply to:  20 ; Changed 6 years ago by 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!

comment:22 in reply to:  21 ; Changed 6 years ago by 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.

comment:23 in reply to:  22 Changed 6 years ago by 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.

comment:24 in reply to:  20 ; Changed 6 years ago by 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.

comment:25 in reply to:  24 Changed 6 years ago by 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.)

comment:26 Changed 6 years ago by Remy Blank

Owner: changed from Remy Blank to Peter Suter

comment:27 in reply to:  21 Changed 6 years ago by 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?

comment:28 Changed 6 years ago by Peter Suter

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

comment:29 Changed 6 years ago by 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.

comment:30 in reply to:  29 ; Changed 6 years ago by 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)

Last edited 6 years ago by Peter Suter (previous) (diff)

comment:31 in reply to:  30 Changed 6 years ago by Remy Blank

Replying to psuter:

Right, thanks. Does this look ok?

Yep, looks about right :)

comment:32 Changed 6 years ago by Peter Suter

Resolution: fixed
Status: newclosed

Applied in [10989].

comment:33 Changed 4 years ago by Ryan J Ollos

Keywords: trac.ini added; tracini removed

Normalizing keywords.

comment:34 Changed 3 years ago by Ryan J Ollos

Keywords: preferences added; userpreferences removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Peter Suter.
The resolution will be deleted.
to The owner will be changed from Peter Suter to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .

 
Note: See TracTickets for help on using tickets.