Edgewall Software
Modify

Opened 6 years ago

Last modified 2 years ago

#8135 reopened enhancement

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

Reported by: srevill@… Owned by:
Priority: low Milestone: next-dev-1.1.x
Component: ticket system Version: 0.13dev
Severity: normal Keywords: tickets, templates, customize patch
Cc: bavison@…, franz.mayer@…
Release Notes:
API 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@… 3 years ago.
possible solution for this ticket

Download all attachments as: .zip

Change History (19)

comment:1 Changed 6 years ago by ebray

  • Component changed from web frontend to 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 Changed 6 years ago by srevill@…

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 Changed 6 years ago by srevill@…

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 Changed 6 years ago by ebray

  • Resolution set to worksforme
  • Status changed from new to 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 Changed 6 years ago by srevill@…

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 Changed 6 years ago by ebray

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.

Changed 3 years ago by franz.mayer@…

possible solution for this ticket

comment:7 follow-up: Changed 3 years ago by franz.mayer@…

  • Cc franz.mayer@… added
  • Component changed from general to ticket system
  • Keywords patch added
  • Milestone set to 0.13
  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Summary changed from Prev, Query, Next links at top of ticket page to [PATCH] Prev, Query, Next links at buttom of ticket page
  • Version changed from none to 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.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 3 years ago by cboos

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?)

comment:9 in reply to: ↑ 8 ; follow-up: Changed 3 years ago by 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").

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).

comment:10 in reply to: ↑ 9 ; follow-up: Changed 3 years ago by cboos

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 Changed 3 years ago by Alex Willmer <al.willmer@…>

  • Summary changed from [PATCH] Prev, Query, Next links at buttom of ticket page to [PATCH] Prev, Query, Next links at bottom of ticket page

comment:12 Changed 3 years ago by franz.mayer@…

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

comment:13 in reply to: ↑ 10 ; follow-up: Changed 3 years ago by osimons

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

comment:14 in reply to: ↑ 13 Changed 3 years ago by franz.mayer@…

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 Changed 3 years ago by framay <franz.mayer@…>

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 Changed 2 years ago by rblank

  • Milestone changed from 1.0 to 1.0-triage

Preparing for 1.0.

comment:17 Changed 2 years ago by cboos

Move feature requests to next-dev.

comment:18 Changed 2 years ago by cboos

  • Milestone changed from next-stable-1.0.x to next-dev-1.1.x

well, once again… next-dev

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as reopened The ticket will remain with no owner.
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'.
Author


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

 
Note: See TracTickets for help on using tickets.