| 203 | === Position padding === |
| 204 | Whether or not you cast the {{position}}} field into an integer for report ordering, you still may want to pad your position numbers so that they sort correctly in any report or custom query in which they appear. You set this up globally in {{{trac.ini}}}: |
| 205 | {{{ |
| 206 | [queues] |
| 207 | pad_length = 2 |
| 208 | }}} |
| 209 | |
| 210 | A {{{pad_length}}} of {{{2}}} is the default. This means that position 1 will become position {{{01}}}, etc. Position 10 remains {{{10}}}, and 100 remains {{{100}}}. |
| 211 | |
| 212 | === Maximum position === |
| 213 | Typically, the further down a queue you go, the less accurate the ordering becomes. This is natural. Which means that after a point, ordering doesn't really matter anymore. One way to help reinforce this is by defining a {{{max_position}}} value: |
| 214 | {{{ |
| 215 | [queues] |
| 216 | max_position = 99 |
| 217 | }}} |
| 218 | |
| 219 | A {{{max_position}}} of {{{99}}} is the default. This means that positions 100 and beyond will get set to position {{{99}} whenever they appear in a queue. |
| 220 | |
| 221 | === "Max items per page" === |
| 222 | Trac automatically paginates reports longer than the defined "Max items per page". Depending on your usage of queues, you may want to either set this value lower (or higher) globally in {{{trac.ini}}}: |
| 223 | {{{ |
| 224 | [report] |
| 225 | items_per_page = 100 |
| 226 | }}} |
| 227 | |
| 228 | .. or bookmark reports setting {{{max=N}}} as desired. For example, seeing a logn queue can be overwhelming to some, so you may want to encourage them to only look at the first 10 or 20 using this param/argument. However, note that queue reordering only works on the first page (it's disabled for subsequent pages). So if you need to reorder items on the second or third pages, increase the "Max items per page" argument as needed. |
| 229 | |
| 230 | === Enhanced user experience === |