Trac Ticket Queries

In addition to reports, Trac provides support for custom ticket queries, used to display lists of tickets meeting a specified set of criteria.

To configure and execute a custom query, switch to the View Tickets module from the navigation bar, and select the Custom Query link.

Filters

When you first go to the query page the default filter will display tickets relevant to you:

  • If logged in then all open tickets it will display open tickets assigned to you.
  • If not logged in but you have specified a name or email address in the preferences then it will display all open tickets where your email (or name if email not defined) is in the CC list.
  • If not logged and no name/email defined in the preferences then all open issues are displayed.

Current filters can be removed by clicking the button to the left with the minus sign on the label. New filters are added from the pulldown lists at the bottom corners of the filters box ('And' conditions on the left, 'Or' conditions on the right). Filters with either a text box or a pulldown menu of options can be added multiple times to perform an or of the criteria.

You can use the fields just below the filters box to group the results based on a field, or display the full description for each ticket.

Once you've edited your filters click the Update button to refresh your results.

Clicking on one of the query results will take you to that ticket. You can navigate through the results by clicking the Next Ticket or Previous Ticket links just below the main menu bar, or click the Back to Query link to return to the query page.

You can safely edit any of the tickets and continue to navigate through the results using the Next/Previous/Back to Query links after saving your results. When you return to the query any tickets which were edited will be displayed with italicized text. If one of the tickets was edited such that it no longer matches the query criteria the text will also be greyed. Lastly, if a new ticket matching the query criteria has been created, it will be shown in bold.

The query results can be refreshed and cleared of these status indicators by clicking the Update button again.

Saving Queries

Trac allows you to save the query as a named query accessible from the reports module. To save a query ensure that you have Updated the view and then click the Save query button displayed beneath the results. You can also save references to queries in Wiki content, as described below.

Note: one way to easily build queries like the ones below, you can build and test the queries in the Custom report module and when ready - click Save query. This will build the query string for you. All you need to do is remove the extra line breaks.

Note: you must have the REPORT_CREATE permission in order to save queries to the list of default reports. The Save query button will only appear if you are logged in as a user that has been granted this permission. If your account does not have permission to create reports, you can still use the methods below to save a query.

You may want to save some queries so that you can come back to them later. You can do this by making a link to the query from any Wiki page.

[query:status=new|assigned|reopened&version=1.0 Active tickets against 1.0]

Which is displayed as:

Active tickets against 1.0

This uses a very simple query language to specify the criteria (see Query Language).

Alternatively, you can copy the query string of a query and paste that into the Wiki link, including the leading ? character:

[query:?status=new&status=assigned&status=reopened&group=owner Assigned tickets by owner]

Which is displayed as:

Assigned tickets by owner

Using the [[TicketQuery]] Macro

The TicketQuery macro lets you display lists of tickets matching certain criteria anywhere you can use Wiki Formatting.

Example:

[[TicketQuery(version=0.6|0.7&resolution=duplicate)]]

This is displayed as:

No results

Just like the query: wiki links, the parameter of this macro expects a query string formatted according to the rules of the simple ticket query language. This also allows displaying the link and description of a single ticket:

[[TicketQuery(id=123)]]

This is displayed as:

#123
remove the explicit loop which is not necessary in the computation of [uv]_oce(:,:) arrays

A more compact representation without the ticket summaries is also available:

[[TicketQuery(version=0.6|0.7&resolution=duplicate, compact)]]

This is displayed as:

No results

Finally, if you wish to receive only the number of defects that match the query, use the count parameter.

[[TicketQuery(version=0.6|0.7&resolution=duplicate, count)]]

This is displayed as:

0

Customizing the table format

You can also customize the columns displayed in the table format (format=table) by using col≤field> - you can specify multiple fields and what order they are displayed by placing pipes (|) between the columns like below:

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter)]]

This is displayed as:

Full rows

In table format you can also have full rows by using rows≤field> like below:

[[TicketQuery(max=3,status=closed,order=id,desc=1,format=table,col=resolution|summary|owner|reporter,rows=description)]]

This is displayed as:

Results (1 - 3 of 2312)

1 2 3 4 5 6 7 8 9 10 11
Ticket Resolution Summary Owner Reporter
#2486 fixed Fixing irregularities revealed by namelist integrity checks acc acc
Description

Context

The application of namelist integrity checking tools to 4.0-HEAD@13089 revealed several irregularities that this ticket seeks to address. Most are resolved with trivial changes but a couple of the changes proposed here should be reviewed by those more familiar with those parts of the code. Namely the changes to the PISCES reference namelist and to the stochastic parameterisation module.

Analysis

Firstly, there are two changes to the code base to replace valid code with code more conformant with the conventions used elsewhere. These are merely to allow the namelist integrity checks to correctly identify namelists.

The first is uncontroversial and merely inserts a leading ampersand on a continuation line:

  • OCE/SBC/sbcwave.F90

     
    391391                             &   sn_tauwoc, sn_tauwx, sn_tauwy     ! informations about the fields to be read 
    392392      ! 
    393393      NAMELIST/namsbc_wave/  sn_cdg, cn_dir, sn_usd, sn_vsd, sn_hsw, sn_wmp, sn_wfr, & 
    394                              sn_wnum, sn_tauwoc, sn_tauwx, sn_tauwy 
     394                          &  sn_wnum, sn_tauwoc, sn_tauwx, sn_tauwy 
    395395      !!--------------------------------------------------------------------- 
    396396      ! 
    397397      REWIND( numnam_ref )              ! Namelist namsbc_wave in reference namelist : File for drag coeff. from wave model 

The second should also be uncontroversial unless there was an obscure reason for appending to the namelist in the manner used uniquely in bdydta.F90 (alignment of variables? Problems with a particular compiler?). Otherwise, the proposal is to replace the multiple declarations with a single declaration and continuation lines:

  • OCE/BDY/bdydta.F90

     
    395395      TYPE(FLD_N), DIMENSION(:), POINTER ::   bn_alias                        ! must be an array to be used with fld_fill 
    396396      TYPE(FLD  ), DIMENSION(:), POINTER ::   bf_alias 
    397397      ! 
    398       NAMELIST/nambdy_dta/ cn_dir, bn_tem, bn_sal, bn_u3d, bn_v3d, bn_ssh, bn_u2d, bn_v2d 
    399       NAMELIST/nambdy_dta/ bn_a_i, bn_h_i, bn_h_s, bn_t_i, bn_t_s, bn_tsu, bn_s_i, bn_aip, bn_hip 
    400       NAMELIST/nambdy_dta/ rn_ice_tem, rn_ice_sal, rn_ice_age, rn_ice_apnd, rn_ice_hpnd 
    401       NAMELIST/nambdy_dta/ ln_full_vel, ln_zinterp 
     398      NAMELIST/nambdy_dta/ cn_dir, bn_tem, bn_sal, bn_u3d, bn_v3d, bn_ssh, bn_u2d, bn_v2d,         & 
     399                         & bn_a_i, bn_h_i, bn_h_s, bn_t_i, bn_t_s, bn_tsu, bn_s_i, bn_aip, bn_hip, & 
     400                         & rn_ice_tem, rn_ice_sal, rn_ice_age, rn_ice_apnd, rn_ice_hpnd,           & 
     401                         & ln_full_vel, ln_zinterp 
    402402      !!--------------------------------------------------------------------------- 
    403403      ! 
    404404      IF(lwp) WRITE(numout,*) 

With these changes the namelist integrity checks reveal the issues shown in part 3 of: Namelist checks Many of the issues flagged relating to derived type variables (sn*) or array varaibles are not real issues. They are flagged simply because only the derived type name or array name appears in the namelist declaration but individual elements are set in the namelists. Ignoring these items there are still the following issues to be addressed:

Recommendation

OCE

ln_rnf_icb             declared in namsbc_rnf (sbcrnf.F90) with no namelist_ref entry
sn_i_rnf               declared in namsbc_rnf (sbcrnf.F90) with no namelist_ref entry
ln_time_average_weight declared in namberg (icb_oce.F90, icbini.F90) with no namelist_ref entry
a large block of 23 variables declared in namsto (stopar.F90) with no namelist_ref entries

The first two of these are related and seem to be a simple omission. The proposed change is to add them to the namelist_ref:

  • SHARED/namelist_ref

     
    416416      rn_rnf_max  = 5.735e-4  !  max value of the runoff climatologie over global domain ( ln_rnf_depth_ini = .true ) 
    417417      rn_dep_max  = 150.      !  depth over which runoffs is spread ( ln_rnf_depth_ini = .true ) 
    418418      nn_rnf_depth_file = 0   !  create (=1) a runoff depth file or not (=0) 
     419   ln_rnf_icb  = .false.   !  read in iceberg flux from a file (fill sn_i_rnf if .true.) 
    419420 
    420421   cn_dir      = './'      !  root directory for the runoff data location 
    421422   !___________!_________________________!___________________!___________!_____________!________!___________!__________________!__________!_______________! 
     
    426427   sn_s_rnf    = 'runoffs'               ,        24.        , 'rosaline',   .true.    , .true. , 'yearly'  , ''               , ''       , '' 
    427428   sn_t_rnf    = 'runoffs'               ,        24.        , 'rotemper',   .true.    , .true. , 'yearly'  , ''               , ''       , '' 
    428429   sn_dep_rnf  = 'runoffs'               ,         0.        , 'rodepth' ,   .false.   , .true. , 'yearly'  , ''               , ''       , '' 
     430   sn_i_rnf    = 'NOT_USED'              ,        -1.        , 'sorunoff',   .true.    , .true. , 'yearly'  , ''               , ''       , '' 
    429431/ 
    430432!----------------------------------------------------------------------- 
    431433&namsbc_apr    !   Atmospheric pressure used as ocean forcing           (ln_apr_dyn =T) 

The next variable is a logical switch which has no code to activate and no explanation of its intention. The proposed change is to remove it:

  • OCE/ICB/icb_oce.F90

     
    121121   REAL(wp), PUBLIC ::   rn_sicn_shift                   !: Shift of sea-ice concentration in erosion flux modulation (0<sicn_shift<1) 
    122122   LOGICAL , PUBLIC ::   ln_operator_splitting           !: Use first order operator splitting for thermodynamics 
    123123   LOGICAL , PUBLIC ::   ln_passive_mode                 !: iceberg - ocean decoupling 
    124    LOGICAL , PUBLIC ::   ln_time_average_weight          !: Time average the weight on the ocean    !!gm I don't understand that ! 
    125124   REAL(wp), PUBLIC ::   rn_speed_limit                  !: CFL speed limit for a berg 
    126125   ! 
    127126   !                                     ! Mass thresholds between iceberg classes [kg] 
  • OCE/ICB/icbini.F90

     
    381381         &              rn_distribution, rn_mass_scaling, rn_initial_thickness, nn_verbose_write     ,   & 
    382382         &              rn_rho_bergs   , rn_LoW_ratio   , nn_verbose_level    , ln_operator_splitting,   & 
    383383         &              rn_bits_erosion_fraction        , rn_sicn_shift       , ln_passive_mode      ,   & 
    384          &              ln_time_average_weight          , nn_test_icebergs    , rn_test_box          ,   & 
    385          &              ln_use_calving , rn_speed_limit , cn_dir, sn_icb 
     384         &              nn_test_icebergs                , rn_test_box         , ln_use_calving       ,   & 
     385         &              rn_speed_limit , cn_dir, sn_icb 
    386386      !!---------------------------------------------------------------------- 
    387387 
    388388#if defined key_agrif 
     
    467467            &                    '(0<sicn_shift<1)    rn_sicn_shift  = ', rn_sicn_shift 
    468468         WRITE(numout,*) '   Do not add freshwater flux from icebergs to ocean                ',   & 
    469469            &                    '                  passive_mode            = ', ln_passive_mode 
    470          WRITE(numout,*) '   Time average the weight on the ocean   time_average_weight       = ', ln_time_average_weight 
    471470         WRITE(numout,*) '   Create icebergs in absence of a restart file   nn_test_icebergs  = ', nn_test_icebergs 
    472471         WRITE(numout,*) '                   in lon/lat box                                   = ', rn_test_box 
    473472         WRITE(numout,*) '   Use calving data even if nn_test_icebergs > 0    ln_use_calving  = ', ln_use_calving 

The unused stochastic parameterisation variables present more of a dilemma. The entire namsto namelist declared in stopar.F90 is:

      NAMELIST/namsto/ ln_sto_ldf, rn_ldf_std, rn_ldf_tcor, &
        &              ln_sto_hpg, rn_hpg_std, rn_hpg_tcor, &
        &              ln_sto_pstar, rn_pstar_std, rn_pstar_tcor, nn_pstar_flt, nn_pstar_ord, &
        &              ln_sto_trd, rn_trd_std, rn_trd_tcor, &
        &              ln_sto_eos, nn_sto_eos, rn_eos_stdxy, rn_eos_stdz, &
        &              rn_eos_tcor, nn_eos_ord, nn_eos_flt, rn_eos_lim, &
        &              ln_sto_trc, nn_sto_trc, rn_trc_stdxy, rn_trc_stdz, &
        &              rn_trc_tcor, nn_trc_ord, nn_trc_flt, rn_trc_lim, &
        &              ln_rststo, ln_rstseed, cn_storst_in, cn_storst_out

but of these only:

      NAMELIST/namsto/ ln_sto_eos, nn_sto_eos, rn_eos_stdxy, rn_eos_stdz, &
        &              rn_eos_tcor, nn_eos_ord, nn_eos_flt, rn_eos_lim,   &
        &              ln_rststo, ln_rstseed, cn_storst_in, cn_storst_out

are reported to ocean.output. The intent seems to be to limit access to only these options but the other options could be activated via the namelist and will activate code within the stochastic parameterisation module. The proposed change here is to properly disable the other options by:

  • OCE/STO/stopar.F90

     
    244244      !! 
    245245      !! ** Purpose :   define the stochastic parameterization 
    246246      !!---------------------------------------------------------------------- 
    247       NAMELIST/namsto/ ln_sto_ldf, rn_ldf_std, rn_ldf_tcor, & 
    248         &              ln_sto_hpg, rn_hpg_std, rn_hpg_tcor, & 
    249         &              ln_sto_pstar, rn_pstar_std, rn_pstar_tcor, nn_pstar_flt, nn_pstar_ord, & 
    250         &              ln_sto_trd, rn_trd_std, rn_trd_tcor, & 
    251         &              ln_sto_eos, nn_sto_eos, rn_eos_stdxy, rn_eos_stdz, & 
    252         &              rn_eos_tcor, nn_eos_ord, nn_eos_flt, rn_eos_lim, & 
    253         &              ln_sto_trc, nn_sto_trc, rn_trc_stdxy, rn_trc_stdz, & 
    254         &              rn_trc_tcor, nn_trc_ord, nn_trc_flt, rn_trc_lim, & 
     247      ! stochastic equation of state only (for now) 
     248      NAMELIST/namsto/ ln_sto_eos, nn_sto_eos, rn_eos_stdxy, rn_eos_stdz, & 
     249        &              rn_eos_tcor, nn_eos_ord, nn_eos_flt, rn_eos_lim,   & 
    255250        &              ln_rststo, ln_rstseed, cn_storst_in, cn_storst_out 
     251      !NAMELIST/namsto/ ln_sto_ldf, rn_ldf_std, rn_ldf_tcor, & 
     252      !  &              ln_sto_hpg, rn_hpg_std, rn_hpg_tcor, & 
     253      !  &              ln_sto_pstar, rn_pstar_std, rn_pstar_tcor, nn_pstar_flt, nn_pstar_ord, & 
     254      !  &              ln_sto_trd, rn_trd_std, rn_trd_tcor, & 
     255      !  &              ln_sto_trc, nn_sto_trc, rn_trc_stdxy, rn_trc_stdz, & 
     256      !  &              rn_trc_tcor, nn_trc_ord, nn_trc_flt, rn_trc_lim 
    256257      !!---------------------------------------------------------------------- 
    257258      INTEGER :: jsto, jmem, jarea, jdof, jord, jordm1, jk, jflt 
    258259      INTEGER(KIND=8) :: zseed1, zseed2, zseed3, zseed4 
     
    260261      INTEGER  ::   ios                 ! Local integer output status for namelist read 
    261262 
    262263      ! Read namsto namelist : stochastic parameterization 
    263       REWIND( numnam_ref )              ! Namelist namdyn_adv in reference namelist : Momentum advection scheme 
     264      REWIND( numnam_ref )              ! Namelist namsto in reference namelist : stochastic parameterization 
    264265      READ  ( numnam_ref, namsto, IOSTAT = ios, ERR = 901) 
    265266901   IF( ios /= 0 ) CALL ctl_nam ( ios , 'namsto in reference namelist' ) 
    266267 
    267       REWIND( numnam_cfg )              ! Namelist namdyn_adv in configuration namelist : Momentum advection scheme 
     268      REWIND( numnam_cfg )              ! Namelist namsto in configuration namelist : stochastic parameterization 
    268269      READ  ( numnam_cfg, namsto, IOSTAT = ios, ERR = 902 ) 
    269270902   IF( ios >  0 ) CALL ctl_nam ( ios , 'namsto in configuration namelist' ) 
    270271      IF(lwm) WRITE ( numond, namsto ) 

TOP

The issues found in the TOP code reduce to just two mis-spelt variables and two missing default settings in namelist_top_ref. In fact the two missing character strings don't seem to have defaults set in the code either so the choice made here should be verified:

  • namelist_top_ref

     
    121121   nn_trd_trc    =  5475     !  time step frequency and tracers trends 
    122122   nn_ctls_trc   =   0       !  control surface type in mixed-layer trends (0,1 or n<jpk) 
    123123   rn_ucf_trc    =   1       !  unit conversion factor (=1 -> /seconds ; =86400. -> /day) 
    124    ln_trdmld_trc_restart = .false. !  restart for ML diagnostics 
    125    ln_trdmld_trc_instant = .true.  !  flag to diagnose trends of instantantaneous or mean ML T/S 
     124   ln_trdmxl_trc_restart = .false.   !  restart for ML diagnostics 
     125   ln_trdmxl_trc_instant = .true.    !  flag to diagnose trends of instantantaneous or mean ML T/S 
     126   cn_trdrst_trc_in  = 'restart_trd' !  suffix of pass. tracer trends restart name (input) 
     127   cn_trdrst_trc_out = 'restart_trd' !  suffix of pass. tracer trends restart name (output) 
    126128   ln_trdtrc( 1) = .true. 
    127129   ln_trdtrc( 2) = .true. 
    128130   ln_trdtrc(23) = .true. 

PISCES

The issues found in PISCES are just two mis-spelt variables. Because there are many variables sharing names between the p4z and p5z versions it isn't immediately obvious what the correct choices are. The changes proposed here are a best guess but both the choice of variable and the validity of the default value should be verified:

  • namelist_pisces_ref

     
    196196   wchldm     =  0.02     ! maximum quadratic mortality of diatoms 
    197197   mpratn     =  0.01     ! nanophytoplankton mortality rate 
    198198   mpratp     =  0.01     ! picophytoplankton mortality rate 
    199    mprat2     =  0.01     ! Diatoms mortality rate 
     199   mpratd     =  0.01     ! Diatoms mortality rate 
    200200/ 
    201201!----------------------------------------------------------------------- 
    202202&namp4zmes     !   parameters for mesozooplankton for PISCES std       - ln_p4z 
     
    229229   bmetexc2   =  .true.   ! Metabolic use of excess carbon 
    230230   resrat2    =  0.005    ! exsudation rate of mesozooplankton 
    231231   mzrat2     =  0.02     ! mesozooplankton mortality rate 
    232    xpref2d    =  1.       ! zoo preference for phyto 
    233    xpref2p    =  1.       ! zoo preference for POC 
     232   xpref2d    =  1.       ! zoo preference for Diatoms 
     233   xpref2n    =  1.       ! zoo preference for nanophyto 
    234234   xpref2z    =  1.       ! zoo preference for zoo 
    235    xpref2m    =  0.2      ! meso preference for zoo 
    236    xpref2c    =  0.3      ! zoo preference for poc 
     235   xpref2m    =  0.2      ! zoo preference for mesozoo 
     236   xpref2c    =  0.3      ! zoo preference for POC 
    237237   xthresh2zoo = 1E-8     ! zoo feeding threshold for mesozooplankton 
    238238   xthresh2dia = 1E-8     ! diatoms feeding threshold for mesozooplankton 
    239239   xthresh2phy = 1E-8     ! nanophyto feeding threshold for mesozooplankton 
#2484 fixed Problem in the trend routine for UBS+VVL option systeam smasson
Description

Context

same as #2277 but for the trunk

#2483 fixed Erroneous distribution of radiative fluxes in coupled mode 'oce and ice' systeam smasson
Description

Context

same as #2434 but for the trunk

1 2 3 4 5 6 7 8 9 10 11

Query Language

query: Trac Links and the [[TicketQuery]] macro both use a mini “query language” for specifying query filters. Basically, the filters are separated by ampersands (&). Each filter then consists of the ticket field name, an operator, and one or more values. More than one value are separated by a pipe (|), meaning that the filter matches any of the values. To include a literal & or | in a value, escape the character with a backslash (\).

The available operators are:

= the field content exactly matches one of the values
~= the field content contains one or more of the values
^= the field content starts with one of the values
$= the field content ends with one of the values

All of these operators can also be negated:

!= the field content matches none of the values
!~= the field content does not contain any of the values
!^= the field content does not start with any of the values
!$= the field content does not end with any of the values

The date fields created and modified can be constrained by using the = operator and specifying a value containing two dates separated by two dots (..). Either end of the date range can be left empty, meaning that the corresponding end of the range is open. The date parser understands a few natural date specifications like "3 weeks ago", "last month" and "now", as well as Bugzilla-style date specifications like "1d", "2w", "3m" or "4y" for 1 day, 2 weeks, 3 months and 4 years, respectively. Spaces in date specifications can be left out to avoid having to quote the query string.

created=2007-01-01..2008-01-01 query tickets created in 2007
created=lastmonth..thismonth query tickets created during the previous month
modified=1weekago.. query tickets that have been modified in the last week
modified=..30daysago query tickets that have been inactive for the last 30 days

See also: Trac Tickets, Trac Reports, Trac Guide

Last modified 7 years ago Last modified on 2013-12-24T20:28:30+01:00