Edgewall Software
Modify ↓

Opened 16 years ago

Last modified 10 years ago

#8135 new enhancement

[PATCH] Prev, Query, Next links at bottom of ticket page

Reported by: srevill@… Owned by:
Priority: low Milestone: next-major-releases
Component: ticket system Version: 0.13dev
Severity: normal Keywords: tickets, templates, customize patch
Cc: bavison@…, franz.mayer@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

When you're viewing a ticket after selecting it from some report/query, there are usually three links at the top of the page saying (roughly):

  • Previous ticket
  • Back to Query
  • Next ticket

Is there some way to have these links repeated at the bottom of the page? When updating tickets, most of the work happens at the bottom of the page and it's a pain to keep scrolling to the bottom to do the work, then to the top to click "Next ticket" then back to the bottom again…

I tried looking around for some HTML templates that I can edit to achieve this but I got as far as finding that the changes I need to make are probably in ticket/web_ui.py before calling it a day.

Can I request this feature be added? Also, if there is a quick hack I can make to my existing (trac 0.11.3) install, I'm all ears…

Ta.

Attachments (1)

ticket.html.diff​ (847 bytes ) - added by franz.mayer@… 13 years ago.
possible solution for this ticket

Download all attachments as: .zip

Change History (21)

comment:1 by ebray, 16 years ago

Component: web frontend → general

I'd say this is mostly a matter of customizing your site template to add an additional copy of the context nav elsewhere. So unless a good case can be made to have this in Trac's default template this should probably be closed.

comment:2 by srevill@…, 16 years ago

This sounds a bit like I need to RTFM the site template stuff and try to get my head around it… if that's the case, then you probably can close this ticket. I hint at the kind of site.html template I would need (e.g. for a default trac install with my tweak) would be very much appreciated.

comment:3 by srevill@…, 16 years ago

Well, I've tried RTFM but it's hardly an enlightening experience. Here's the best I could think of - remember I don't understand a word of this Genshi stuff and close to zero python… 

    <py:choose test="req.environ['PATH_INFO'].find('/ticket/') >= 0">
      <py:when test="True">
        <div py:match="div[@class='buttons']" py:attrs="select('@*')">
          ${select('*')}
          <div py:match="div[@id='ctxtnav' and @class='nav']" py:attrs="select('@*')">
            ${select('*')}
          </div>
         </div>
         ${select('*|text()')}
      </py:when>
      <py:otherwise>
         <p>Flibble, wibble</p>
         ${select('*|text()')}
      </py:otherwise>
    </py:choose>

which didn't work of course. So I got even more desparate… 

    <py:choose test="req.environ['PATH_INFO'].find('/ticket/') >= 0">
      <py:when test="True">
        <py:with vars="myvar = select('@*')">
          <div py:match="div[@class='buttons']" py:attrs="select('@*')">
            ${select('*')}
            <div py:match="div[@id='ctxtnav' and @class='nav']" py:attrs="myvar">
              ${select('*')}
            </div>
           </div>
         </py:with>
         ${select('*|text()')}
      </py:when>
      <py:otherwise>
         <p>Flibble, wibble</p>
         ${select('*|text()')}
      </py:otherwise>
    </py:choose>

which also doesn't work. I just don't understand what the select() stuff does, the text() thing, why my myvar variable always seems to contain nothing - I basically don't have a clue what's going on because it all looks magic.

Answers from the enlightened, please.

comment:4 by ebray, 16 years ago

Resolution: → worksforme
Status: new → closed

Yeah, you're all over the place with those attempts. It doesn't need to be nearly so involved. Here's what I did: 

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:py="http://genshi.edgewall.org/" py:strip="">
  <py:if test="context and context.resource.realm == 'ticket' and context.resource.id">
    <py:match path="//div[@id='main']" once="true">
      <div py:attrs="select('@*')">
        ${select('*|text()')}
        <div id="ctxtnav2" class="nav">
          ${select('div[@id="ctxtnav"]/*')}
        </div>
      </div>
    </py:match>
  </py:if>
</html>

It gives the second context nav an id of "ctxtnav2" so you can add the appropriate stylings for it in your site.css.

Otherwise, if you want to better understand Genshi I'd encourage you to post your questions on the Genshi mailing list.

comment:5 by srevill@…, 16 years ago

Thanks for your help. Sorry to bang on about this one - I have one last dumb question: where would you put that fragment - e.g. which file?

comment:6 by ebray, 16 years ago

That would go in <path_to_env>/templates/site.html. See hTracInterfaceCustomization#SiteAppearance if you haven't already—it also gives an example of how to include your own stylesheet.

by franz.mayer@…, 13 years ago

Attachment: ticket.html.diff​ added

possible solution for this ticket

comment:7 by franz.mayer@…, 13 years ago

Cc: franz.mayer@… added
Component: general → ticket system
Keywords: patch added
Milestone: → 0.13
Resolution: worksforme
Status: closed → reopened
Summary: Prev, Query, Next links at top of ticket page → [PATCH] Prev, Query, Next links at buttom of ticket page
Version: none → 0.13dev

IMO this is a nice little enhencement, which does not hurt. So why not include it in Trac standard? The provided patch is a slightly adjusted copy of ctxtnav-div in theme.html.

in reply to:  7 ; comment:8 by Christian Boos, 13 years ago

Replying to franz.mayer@…:

IMO this is a nice little enhencement, which does not hurt. So why not include it in Trac standard?

Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.

We could perhaps instead search for ways to make those links always reachable? (JIRA like?)

in reply to:  8 ; comment:9 by franz.mayer@…, 13 years ago

Replying to cboos:

Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.

Yes, this is probably the nicest way for users.

We could perhaps instead search for ways to make those links always reachable? (JIRA like?)

I don't know what you mean with "JIRA like" (tried ​Jira Sandbox but could not find any "always reachable links").

But I played a little around with fixed menus and here's some hack for fixing mainnav and ctxtnav on top of browser page (see ​http://limpid.nl/lab/css/fixed/header and ​stackoverflow entry for CSS details): 

#mainnav {
 background-color: #ffffff;
 position:fixed;
 top:0;
 width:100%;
 z-index:100;
 margin-top: 0px;
 padding-top:0px;
}

#ctxtnav {
 background-color: #ffffff;
 position: fixed;
 top:1.2em;
 width:100%;
 z-index:100;
 margin-top: 0px;
 padding-top:0px;
}

I tried above hack on my test Trac Test system by using Component ​CssTemplate for inserting CSS file (but of course you can simply change / override it in Firebug or Trac itself).

in reply to:  9 ; comment:10 by Christian Boos, 13 years ago

Replying to franz.mayer@…:

Replying to cboos:

Because we already have too many links cropping up everywhere. If we were to always duplicate the contextual navigation ones, this would only be getting worse, especially on pages with a small height where you'd see both the (same) top and bottom links.

Yes, this is probably the nicest way for users.

We could perhaps instead search for ways to make those links always reachable? (JIRA like?)

I don't know what you mean with "JIRA like" (tried ​Jira Sandbox but could not find any "always reachable links").

Look into an "issue", in particular when you're coming from a query, you'll see the issue title at the top left and some links at the top right (e.g. (^) 3 of 135 <br> (v) Return to search) and below that, even some action buttons; they'll all stick at the top of the page when you scroll down.

But I played a little around with fixed menus and here's some hack for fixing mainnav and ctxtnav on top of browser page (see ​http://limpid.nl/lab/css/fixed/header and ​stackoverflow entry for CSS details):

Yes, something like that. The JIRA way also involves a bit of Javascript to only make it stick when scrolling down (and to "unstick" it again when scrolling up). I'm not saying we should do exactly the same, but we could find something similar and fitting in Trac.

I already experimented a bit with the action buttons in particular (for the Wiki), but this could also be extended to (some) nav links (probably just the contextual ones, not the mainnav).

comment:11 by Alex Willmer <al.willmer@…>, 13 years ago

Summary: [PATCH] Prev, Query, Next links at buttom of ticket page → [PATCH] Prev, Query, Next links at bottom of ticket page

comment:12 by franz.mayer@…, 13 years ago

Replying to cboos:

Look into an "issue", in particular when you're coming from a query, you'll see the issue title at the top left and some links at the top right (e.g. (^) 3 of 135 <br> (v) Return to search) and below that, even some action buttons; they'll all stick at the top of the page when you scroll down.

Ahh … now I see … with Chrome, because with my very old Firefox 8 it is not working :-P

in reply to:  10 ; comment:13 by osimons, 13 years ago

Replying to cboos:

Yes, something like that. The JIRA way also involves a bit of Javascript to only make it stick when scrolling down (and to "unstick" it again when scrolling up). I'm not saying we should do exactly the same, but we could find something similar and fitting in Trac.

It is the strategy I used for my 'Talk' plugin, where the interactive chats may extend to become quite long pages. I use a sidebar that flows with the activity. I think I have anonymous read access for the demo talk room, so you can have a look at it:

​https://www.coderesort.com/p/open/talk/1#line-1

in reply to:  13 comment:14 by franz.mayer@…, 13 years ago

Replying to osimons:

It is the strategy I used for my 'Talk' plugin, where the interactive chats may extend to become quite long pages. I use a sidebar that flows with the activity. I think I have anonymous read access for the demo talk room, so you can have a look at it:

​https://www.coderesort.com/p/open/talk/1#line-1

Well, honestly I do not like this solution so much, because there is always a delay of a few ticks. So you get the feeling of having a jumping box on your side. I would prefer having a fix menu / navigation bar (like a frame in old HTML) - but maybe this feels ancient in times of Web 2.0 …

comment:15 by framay <franz.mayer@…>, 13 years ago

I implemented the requested enhancement as a plugin: ​NavigationDisplayPlugin

When setting user preference to buttom_ctx_menu it performs the action as described in ticket description. When setting fixed_menu it performs action as described in comment:9. There might also be more options, like described in comment:13.

Note: this plugin is quite a hack - for better handling of option fixed_menu (which is my personal favourite) the structure of Trac-HTML needs to be reorganized

If you would like to have another option (osimons?!) please let me know or be welcome to add it to the plugin. Comments to that plugin are also welcome (kind of RFC), since I'm not a native Python programmer.

comment:16 by Remy Blank, 13 years ago

Milestone: 1.0 → 1.0-triage

Preparing for 1.0.

comment:17 by Christian Boos, 13 years ago

Move feature requests to next-dev.

comment:18 by Christian Boos, 13 years ago

Milestone: next-stable-1.0.x → next-dev-1.1.x

well, once again… next-dev

comment:19 by Ryan J Ollos, 10 years ago

Milestone: next-dev-1.1.x → next-major-releases

Retargetting tickets to narrow focus for milestone:1.2. Please move the ticket back to milestone:next-dev-1.1.x if you intend to resolve it by milestone:1.2.

comment:20 by Ryan J Ollos, 10 years ago

Status: reopened → new

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment
E-mail address and name can be saved in the Preferences .
Attachments ↑ Description ↑
 
Note: See TracTickets for help on using tickets.