# wiki

name: TracWorkflow
author: trac
ipnr: 127.0.0.1
text:
  = The Trac Ticket Workflow System =
  [[TracGuideToc]]

  The Trac issue database provides a configurable workflow.

  == The Default Ticket Workflow ==
  === Environments upgraded from 0.10 ===
  When you run `trac-admin <env> upgrade`, your `trac.ini` will be modified to include a `[ticket-workflow]` section.
  The workflow configured in this case is the original workflow, so that ticket actions will behave like they did in 0.10.

  Graphically, that looks like this:

  {{{#!Workflow width=500 height=240
  leave = * -> *
  leave.operations = leave_status
  leave.default = 1
  accept = new -> assigned
  accept.permissions = TICKET_MODIFY
  accept.operations = set_owner_to_self
  resolve = new,assigned,reopened -> closed
  resolve.permissions = TICKET_MODIFY
  resolve.operations = set_resolution
  reassign = new,assigned,reopened -> new
  reassign.permissions = TICKET_MODIFY
  reassign.operations = set_owner
  reopen = closed -> reopened
  reopen.permissions = TICKET_CREATE
  reopen.operations = del_resolution
  }}}

  There are some significant "warts" in this; such as accepting a ticket sets it to 'assigned' state, and assigning a ticket sets it to 'new' state.  Perfectly obvious, right?
  So you will probably want to migrate to "basic" workflow; [trac:source:trunk/contrib/workflow/migrate_original_to_basic.py contrib/workflow/migrate_original_to_basic.py] may be helpful.

  === Environments created with 0.11 ===
  When a new environment is created, a default workflow is configured in your trac.ini.  This workflow is the basic workflow (described in `basic-workflow.ini`), which is somewhat different from the workflow of the 0.10 releases.

  Graphically, it looks like this:

  {{{#!Workflow width=700 height=300
  leave = * -> *
  leave.operations = leave_status
  leave.default = 1
  accept = new,assigned,accepted,reopened -> accepted
  accept.permissions = TICKET_MODIFY
  accept.operations = set_owner_to_self
  resolve = new,assigned,accepted,reopened -> closed
  resolve.permissions = TICKET_MODIFY
  resolve.operations = set_resolution
  reassign = new,assigned,accepted,reopened -> assigned
  reassign.permissions = TICKET_MODIFY
  reassign.operations = set_owner
  reopen = closed -> reopened
  reopen.permissions = TICKET_CREATE
  reopen.operations = del_resolution
  }}}

  == Additional Ticket Workflows ==

  There are several example workflows provided in the Trac source tree; look in [trac:source:trunk/contrib/workflow contrib/workflow] for `.ini` config sections.  One of those may be a good match for what you want. They can be pasted into the `[ticket-workflow]` section of your `trac.ini` file. However if you have existing tickets then there may be issues if those tickets have states that are not in the new workflow. 

  Here are some [http://trac.edgewall.org/wiki/WorkFlow/Examples diagrams] of the above examples.

  == Basic Ticket Workflow Customization ==

  Note: Ticket "statuses" or "states" are not separately defined. The states a ticket can be in are automatically generated by the transitions defined in a workflow. Therefore, creating a new ticket state simply requires defining a state transition in the workflow that starts or ends with that state.

  Create a `[ticket-workflow]` section in `trac.ini`.
  Within this section, each entry is an action that may be taken on a ticket. 
  For example, consider the `accept` action from `simple-workflow.ini`:
  {{{
  accept = new,accepted -> accepted
  accept.permissions = TICKET_MODIFY
  accept.operations = set_owner_to_self
  }}}
  The first line in this example defines the `accept` action, along with the states the action is valid in (`new` and `accepted`), and the new state of the ticket when the action is taken (`accepted`).
  The `accept.permissions` line specifies what permissions the user must have to use this action.
  The `accept.operations` line specifies changes that will be made to the ticket in addition to the status change when this action is taken.  In this case, when a user clicks on `accept`, the ticket owner field is updated to the logged in user.  Multiple operations may be specified in a comma separated list.

  The available operations are:
   - del_owner -- Clear the owner field.
   - set_owner -- Sets the owner to the selected or entered owner.
     - ''actionname''`.set_owner` may optionally be set to a comma delimited list or a single value.
   - set_owner_to_self -- Sets the owner to the logged in user.
   - del_resolution -- Clears the resolution field
   - set_resolution -- Sets the resolution to the selected value.
     - ''actionname''`.set_resolution` may optionally be set to a comma delimited list or a single value. Example:
       {{{
  resolve_new = new -> closed
  resolve_new.name = resolve
  resolve_new.operations = set_resolution
  resolve_new.permissions = TICKET_MODIFY
  resolve_new.set_resolution = invalid,wontfix
       }}}
   - leave_status -- Displays "leave as <current status>" and makes no change to the ticket.
  '''Note:''' Specifying conflicting operations (such as `set_owner` and `del_owner`) has unspecified results.

  {{{
  resolve_accepted = accepted -> closed
  resolve_accepted.name = resolve
  resolve_accepted.permissions = TICKET_MODIFY
  resolve_accepted.operations = set_resolution
  }}}

  In this example, we see the `.name` attribute used.  The action here is `resolve_accepted`, but it will be presented to the user as `resolve`.

  For actions that should be available in all states, `*` may be used in place of the state.  The obvious example is the `leave` action:
  {{{
  leave = * -> *
  leave.operations = leave_status
  leave.default = 1
  }}}
  This also shows the use of the `.default` attribute.  This value is expected to be an integer, and the order in which the actions are displayed is determined by this value.  The action with the highest `.default` value is listed first, and is selected by default.  The rest of the actions are listed in order of decreasing `.default` values.
  If not specified for an action, `.default` is 0.  The value may be negative.

  There are a couple of hard-coded constraints to the workflow.  In particular, tickets are created with status `new`, and tickets are expected to have a `closed` state.  Further, the default reports/queries treat any state other than `closed` as an open state.

  While creating or modifying a ticket workfow, `contrib/workflow/workflow_parser.py` may be useful.  It can create `.dot` files that [http://www.graphviz.org GraphViz] understands to provide a visual description of the workflow.

  This can be done as follows (your install path may be different).
  {{{
  cd /var/local/trac_devel/contrib/workflow/
  sudo ./showworkflow /srv/trac/PlannerSuite/conf/trac.ini
  }}}
  And then open up the resulting `trac.pdf` file created by the script (it will be in the same directory as the `trac.ini` file).

  An online copy of the workflow parser is available at http://foss.wush.net/cgi-bin/visual-workflow.pl

  After you have changed a workflow, you need to restart apache for the changes to take effect. This is important, because the changes will still show up when you run your script, but all the old workflow steps will still be there until the server is restarted.

  == Example: Adding optional Testing with Workflow ==

  By adding the following to your [ticket-workflow] section of trac.ini you get optional testing.  When the ticket is in new, accepted or needs_work status you can choose to submit it for testing.  When it's in the testing status the user gets the option to reject it and send it back to needs_work, or pass the testing and send it along to closed.  If they accept it then it gets automatically marked as closed and the resolution is set to fixed.  Since all the old work flow remains, a ticket can skip this entire section.

  {{{
  testing = new,accepted,needs_work,assigned,reopened -> testing
  testing.name = Submit to reporter for testing
  testing.permissions = TICKET_MODIFY

  reject = testing -> needs_work
  reject.name = Failed testing, return to developer

  pass = testing -> closed
  pass.name = Passes Testing
  pass.operations = set_resolution
  pass.set_resolution = fixed
  }}}

  === How to combine the `tracopt.ticket.commit_updater` with the testing workflow ===

  The [[trac:source:trunk/tracopt/ticket/commit_updater.py|tracopt.ticket.commit_updater]] is the optional component that [[TracRepositoryAdmin#trac-post-commit-hook|replaces the old trac-post-commit-hook]], in Trac 0.12.

  By default it reacts on some keywords found in changeset message logs like ''close'', ''fix'' etc. and performs the corresponding workflow action.

  If you have a more complex workflow, like the testing stage described above and you want the ''closes'' keyword to move the ticket to the ''testing'' status instead of the ''closed'' status, you need to adapt the code a bit. 

  Have a look at the [[trac:wiki:0.11/TracWorkflow#How-ToCombineSVNtrac-post-commit-hookWithTestWorkflow|Trac 0.11 recipe]] for the `trac-post-commit-hook`, this will give you some ideas about how to modify the component.

  == Example: Add simple optional generic review state ==

  Sometimes Trac is used in situations where "testing" can mean different things to different people so you may want to create an optional workflow state that is between the default workflow's `assigned` and `closed` states, but does not impose implementation-specific details. The only new state you need to add for this is a `reviewing` state. A ticket may then be "submitted for review" from any state that it can be reassigned. If a review passes, you can re-use the `resolve` action to close the ticket, and if it fails you can re-use the `reassign` action to push it back into the normal workflow.

  The new `reviewing` state along with its associated `review` action looks like this:

  {{{
  review = new,assigned,reopened -> reviewing
  review.operations = set_owner
  review.permissions = TICKET_MODIFY
  }}}

  Then, to integrate this with the default Trac 0.11 workflow, you also need to add the `reviewing` state to the `accept` and `resolve` actions, like so:

  {{{
  accept = new,reviewing -> assigned
  […]
  resolve = new,assigned,reopened,reviewing -> closed
  }}}

  Optionally, you can also add a new action that allows you to change the ticket's owner without moving the ticket out of the `reviewing` state. This enables you to reassign review work without pushing the ticket back to the `new` status.

  {{{
  reassign_reviewing = reviewing -> *
  reassign_reviewing.name = reassign review
  reassign_reviewing.operations = set_owner
  reassign_reviewing.permissions = TICKET_MODIFY
  }}}

  The full `[ticket-workflow]` configuration will thus look like this:

  {{{
  [ticket-workflow]
  accept = new,reviewing -> assigned
  accept.operations = set_owner_to_self
  accept.permissions = TICKET_MODIFY
  leave = * -> *
  leave.default = 1
  leave.operations = leave_status
  reassign = new,assigned,accepted,reopened -> assigned
  reassign.operations = set_owner
  reassign.permissions = TICKET_MODIFY
  reopen = closed -> reopened
  reopen.operations = del_resolution
  reopen.permissions = TICKET_CREATE
  resolve = new,assigned,reopened,reviewing -> closed
  resolve.operations = set_resolution
  resolve.permissions = TICKET_MODIFY
  review = new,assigned,reopened -> reviewing
  review.operations = set_owner
  review.permissions = TICKET_MODIFY
  reassign_reviewing = reviewing -> *
  reassign_reviewing.operations = set_owner
  reassign_reviewing.name = reassign review
  reassign_reviewing.permissions = TICKET_MODIFY
  }}}

  == Example: Limit the resolution options for a new ticket ==

  The above resolve_new operation allows you to set the possible resolutions for a new ticket.  By modifying the existing resolve action and removing the new status from before the `->` we then get two resolve actions.  One with limited resolutions for new tickets, and then the regular one once a ticket is accepted.

  {{{
  resolve_new = new -> closed
  resolve_new.name = resolve
  resolve_new.operations = set_resolution
  resolve_new.permissions = TICKET_MODIFY
  resolve_new.set_resolution = invalid,wontfix,duplicate

  resolve = assigned,accepted,reopened -> closed
  resolve.operations = set_resolution
  resolve.permissions = TICKET_MODIFY
  }}}

  == Advanced Ticket Workflow Customization ==

  If the customization above is not extensive enough for your needs, you can extend the workflow using plugins.  These plugins can provide additional operations for the workflow (like code_review), or implement side-effects for an action (such as triggering a build) that may not be merely simple state changes.  Look at [trac:source:trunk/sample-plugins/workflow sample-plugins/workflow] for a few simple examples to get started.

  But if even that is not enough, you can disable the !ConfigurableTicketWorkflow component and create a plugin that completely replaces it.

  == Adding Workflow States to Milestone Progress Bars ==

  If you add additional states to your workflow, you may want to customize your milestone progress bars as well.  See [TracIni#milestone-groups-section TracIni].

  == some ideas for next steps ==

  New enhancement ideas for the workflow system should be filed as enhancement tickets against the `ticket system` component.  If desired, add a single-line link to that ticket here.  Also look at the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] as it provides experimental operations.

  If you have a response to the comments below, create an enhancement ticket, and replace the description below with a link to the ticket.

   * the "operation" could be on the nodes, possible operations are:
     * '''preops''': automatic, before entering the state/activity
     * '''postops''': automatic, when leaving the state/activity
     * '''actions''': can be chosen by the owner in the list at the bottom, and/or drop-down/pop-up together with the default actions of leaving the node on one of the arrows.
  ''This appears to add complexity without adding functionality; please provide a detailed example where these additions allow something currently impossible to implement.''

   * operations could be anything: sum up the time used for the activity, or just write some statistical fields like 
  ''A workflow plugin can add an arbitrary workflow operation, so this is already possible.''

   * set_actor should be an operation allowing to set the owner, e.g. as a "preop":
     * either to a role, a person
     * entered fix at define time, or at run time, e.g. out of a field, or select.
  ''This is either duplicating the existing `set_owner` operation, or needs to be clarified.''

   * Actions should be selectable based on the ticket type (different Workflows for different tickets)
  ''Look into the [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin]'s `triage` operation.''

   * I'd wish to have an option to perform automatic status changes. In my case, I do not want to start with "new", but with "assigned". So tickets in state "new" should automatically go into state "assigned". Or is there already a way to do this and I just missed it?
  ''Have a look at [http://trac-hacks.org/wiki/TicketCreationStatusPlugin TicketCreationStatusPlugin] and [http://trac-hacks.org/wiki/TicketConditionalCreationStatusPlugin TicketConditionalCreationStatusPlugin]''

   * I added a 'testing' state. A tester can close the ticket or reject it. I'd like the transition from testing to rejected to set the owner to the person that put the ticket in 'testing'. The [http://trac-hacks.org/wiki/AdvancedTicketWorkflowPlugin AdvancedTicketWorkflowPlugin] is close with set_owner_to_field, but we need something like set_field_to_owner.

   * I'd like to track the time a ticket is in each state, adding up 'disjoints' intervals in the same state.


name: TracImport
author: trac
ipnr: 127.0.0.1
text:
  = Importing ticket data =
  [[PageOutline]]

  By means of migrating from other issue-tracking systems, perform some external actions over tickets or simply synchronize different data bases, there are some available tools, plug-ins or scripts which lets you import or up-date tickets into Trac.

  Below, follows a collection of some of those.

  == !TicketImportPlugin ==

   [http://trac-hacks.org/wiki/TicketImportPlugin TicketImportPlugin] :: mainly, but not only, this plug-in lets you import or up-date into Trac a series of tickets from a '''CSV file''' or (if the [http://pypi.python.org/pypi/xlrd xlrd library] is installed) from an '''Excel file'''. 

  == !ExportImportXlsPlugin ==

   [http://trac-hacks.org/wiki/ExportImportXlsPlugin ExportImportXlsPlugin] :: this plug-in add an admin panel for export and import tickets via '''XLS file'''.
    * It depends on the python packages xlwt/rxld.

  == Bugzilla ==

   [http://trac-hacks.org/wiki/BugzillaIssueTrackingPlugin BugzillaIssueTrackingPlugin] :: integrates Bugzilla into Trac keeping TracLinks

  Ticket data can be imported from Bugzilla using the [http://trac.edgewall.org/browser/trunk/contrib/bugzilla2trac.py bugzilla2trac.py] script, available in the contrib/ directory of the Trac distribution.

  {{{
  $ bugzilla2trac.py
  bugzilla2trac - Imports a bug database from Bugzilla into Trac.

  Usage: bugzilla2trac.py [options]

  Available Options:
    --db <MySQL dbname>              - Bugzilla's database
    --tracenv /path/to/trac/env      - full path to Trac db environment
    -h | --host <MySQL hostname>     - Bugzilla's DNS host name
    -u | --user <MySQL username>     - effective Bugzilla's database user
    -p | --passwd <MySQL password>   - Bugzilla's user password
    -c | --clean                     - remove current Trac tickets before importing
    --help | help                    - this help info

  Additional configuration options can be defined directly in the script.
  }}}

  Currently, the following data is imported from Bugzilla:

    * bugs
    * bug activity (field changes)
    * bug attachments
    * user names and passwords (put into a htpasswd file)

  The script provides a number of features to ease the conversion, such as:

    * PRODUCT_KEYWORDS:  Trac doesn't have the concept of products, so the script provides the ability to attach a ticket keyword instead.

    * IGNORE_COMMENTS:  Don't import Bugzilla comments that match a certain regexp.

    * STATUS_KEYWORDS:  Attach ticket keywords for the Bugzilla statuses not available in Trac.  By default, the 'VERIFIED' and 'RELEASED' Bugzilla statuses are translated into Trac keywords.

  For more details on the available options, see the configuration section at the top of the script.

  == Jira ==

   [http://trac-hacks.org/wiki/JiraToTracIntegration JiraToTracIntegration] :: provides tools to import Atlassian Jira backup files into Trac. The plug-in consists of a Python 3.1 commandline tool that:
     - Parses the Jira backup XML file
     - Sends the imported Jira data and attachments to Trac using the [http://trac-hacks.org/wiki/XmlRpcPlugin XmlRpcPlugin]
     - Generates a htpasswd file containing the imported Jira users and their SHA-512 base64 encoded passwords

  == Mantis ==

   [http://trac-hacks.org/wiki/MantisImportScript MantisImportScript] :: script to import from Mantis into Trac the following data:
    * bugs
    * bug comments
    * bug activity (field changes)
    * attachments (as long as the files live in the mantis db, not on the filesystem) .

  == !PlanetForge ==

   [http://trac-hacks.org/wiki/PlanetForgeImportExportPlugin PlanetForgeImportExportPlugin] :: this plugin exports Trac data (wiki, tickets, compoments, permissions, repositories, etc.) using the open format designed by the COCLICO project. It extends the webadmin panel and the 'trac admin ...' command. Still has no 'import' feature. 

  == Scarab ==

   [http://trac-hacks.org/wiki/ScarabToTracScript ScarabToTracScript] :: script that migrates Scarab issues to Trac tickets
      * Requires [http://trac-hacks.org/wiki/XmlRpcPlugin XmlRpcPlugin]

  == Sourceforge ==

   [http://trac-hacks.org/wiki/SfnToTracScript SfnToTracScript] :: importer of !SourceForge's new backup file (originated from #Trac3521)

  Also, ticket data can be imported from Sourceforge using the [http://trac.edgewall.org/browser/trunk/contrib/sourceforge2trac.py sourceforge2trac.py] script, available in the contrib/ directory of the Trac distribution.

  == Other ==

  Since trac uses a SQL database to store the data, you can import from other systems by examining the database tables. Just go into [http://www.sqlite.org/sqlite.html sqlite] command line to look at the tables and import into them from your application.

  === Comma delimited file - CSV ===
  See [http://trac.edgewall.org/attachment/wiki/TracSynchronize/csv2trac.2.py csv2trac.2.py] for details.  This approach is particularly useful if one needs to enter a large number of tickets by hand. (note that the ticket type type field, (task etc...) is also needed for this script to work with more recent Trac releases)
  Comments on script: The script has an error on line 168, ('Ticket' needs to be 'ticket').  Also, the listed values for severity and priority are swapped. 

  ----
  See also: 
   * to import/export wiki pages: TracAdmin, 
   * to export tickets: TracTickets, TracQuery


name: TracTickets
author: trac
ipnr: 127.0.0.1
text:
  = The Trac Ticket System =
  [[TracGuideToc]]

  The Trac ticket database provides simple but effective tracking of issues and bugs within a project.

  As the central project management element of Trac, tickets can be used for '''project tasks''', '''feature requests''', '''bug reports''', '''software support issues''' among others. 

  As with the TracWiki, this subsystem has been designed with the goal of making user contribution and participation as simple as possible. It should be as easy as possible to report bugs, ask questions, suggest improvements and discuss resolutions.

  An issue is assigned to a person who must resolve it or reassign the ticket to someone else.
  All tickets can be edited, annotated, assigned, prioritized and discussed at any time.

  [=#edit-permissions]
  However, some Trac installations may put restrictions in place about who can change what. For example, the default installation doesn't permit to non-authenticated users ("anonymous" users) to change anything, even to comment on an issue, for obvious spam prevention reasons. Check the local contributing policy, which you can usually find on the front page WikiStart, or contact your local Trac administrator.

  == Ticket Fields ==

  A  ticket contains the following information attributes:
   
   * '''Reporter''' — The author of the ticket.
   * '''Type''' — The nature of the ticket (for example, defect or enhancement request). See TicketTypes for more details.
   * '''Component''' — The project module or subsystem this ticket concerns.
   * '''Version''' — Version of the project that this ticket pertains to.
   * '''Keywords''' — Keywords that a ticket is marked with. Useful for searching and report generation.
   * '''Priority''' — The importance of this issue, ranging from ''trivial'' to ''blocker''. A pull-down if different priorities where defined.
   * '''Milestone''' — When this issue should be resolved at the latest. A pull-down menu containing a list of milestones.
   * '''Assigned to/Owner''' — Principal person responsible for handling the issue.
   * '''Cc''' — A comma-separated list of other users or E-Mail addresses to notify. ''Note that this does not imply responsiblity or any other policy.''
   * '''Resolution''' — Reason for why a ticket was closed. One of {{{fixed}}}, {{{invalid}}}, {{{wontfix}}}, {{{duplicate}}}, {{{worksforme}}}.
   * '''Status''' — What is the current status? One of {{{new}}}, {{{assigned}}}, {{{closed}}}, {{{reopened}}}.
   * '''Summary''' — A brief description summarizing the problem or issue. Simple text without WikiFormatting.
   * '''Description''' — The body of the ticket. A good description should be specific, descriptive and to the point. Accepts WikiFormatting.

  '''Notes:''' 
   - Versions of Trac prior to 0.9 did not have the ''type'' field, but instead provided a ''severity'' field and different default values for the ''priority'' field. This change was done to simplify the ticket model by removing the somewhat blurry distinction between ''priority'' and ''severity''. However, the old model is still available if you prefer it: just add/modify the default values of the ''priority'' and ''severity'', and optionally hide the ''type'' field by removing all the possible values through [wiki:TracAdmin trac-admin].

   - the [trac:TicketTypes type], [trac:TicketComponent component], version, priority and severity fields can be managed with [wiki:TracAdmin trac-admin] or with the [trac:WebAdmin WebAdmin] plugin.

   - Description of the builtin ''priority'' values is available at [trac:TicketTypes#Whyistheseverityfieldgone TicketTypes]

  == Changing and Commenting Tickets ==

  With appropriate permissions, as already mentioned [#edit-permissions above], a ticket entered into Trac can at any time be modified by '''annotating'''.

  Then, annotations like changes and comments to the ticket are logged as a part of the ticket itself. When viewing a ticket, the history of changes will appear below the main ticket area.

  Comment editing (available since 0.12) is meant to be used to make small corrections to comments, like fixing formatting, forgotten WikiFormatting or spelling errors, not major edits. For longer edits, you should be adding a new comment instead. Editing a comment will not produce a new entry on [/timeline] while entering a new comment or other changes will do.

  All edits (field changes, new comments, comment edits) update the "last changed" time of the ticket.


  '''Notes:''' 
   - An important feature is being able to use TracLinks and WikiFormatting in ticket descriptions and comments. Use TracLinks to refer to other issues, changesets or files to make your ticket more specific and easier to understand.

   - See TracNotification for how to configure email notifications of ticket changes.

   - See TracWorkflow for information about the state transitions (ticket lifecycle), and how this workflow can be customized.

  == Default Values for Drop-Down Fields ==

  The option selected by default for the various drop-down fields can be set in [wiki:TracIni trac.ini], in the `[ticket]` section:

   * `default_component`: Name of the component selected by default
   * `default_milestone`: Name of the default milestone
   * `default_priority`: Default priority value
   * `default_severity`: Default severity value
   * `default_type`: Default ticket type
   * `default_version`: Name of the default version
   * `default_owner`: Name of the default owner. If set to the text "< default >" (the default value), the component owner is used.

  If any of these options are omitted, the default value will either be the first in the list, or an empty value, depending on whether the field in question is required to be set.  Some of these can be chosen through the [trac:WebAdmin WebAdmin] plugin in the "Ticket System" section (others in the [[wiki:TracIni#ticket-section|"[ticket]"]] section in `trac.ini`).


  == Hiding Fields and Adding Custom Fields ==

  Many of the default ticket fields can be hidden from the ticket web interface simply by removing all the possible values through [wiki:TracAdmin trac-admin]. This of course only applies to drop-down fields, such as ''type'', ''priority'', ''severity'', ''component'', ''version'' and ''milestone''.

  Trac also lets you add your own custom ticket fields. See TracTicketsCustomFields for more information.


  == Assign-to as Drop-Down List ==

  If the list of possible ticket owners is finite, you can change the ''assign-to'' ticket field from a text input to a drop-down list. This is done by setting the `restrict_owner` option of the `[ticket]` section in [wiki:TracIni trac.ini] to “true”. In that case, Trac will use the list of all users who have accessed the project to populate the drop-down field.

  To appear in the dropdown list, a user needs be registered with the project, ''i.e.'' a user session should exist in the database. Such an entry is automatically created in the database the first time the user submits a change in the project, for example when editing the user's details in the ''Settings'' page, or simply by authenticating if the user has a login. Also, the user must have `TICKET_MODIFY` [TracPermissions permissions].

  '''Notes:''' 
   - See [http://pacopablo.com/wiki/pacopablo/blog/set-assign-to-drop-down Populating Assign To Drop Down] on how to add user entries at database level

   - If you need serious flexibility and aren't afraid of a little plugin coding of your own, see [http://trac-hacks.org/wiki/FlexibleAssignToPlugin FlexibleAssignTo] (disclosure: I'm the author)

   -  Activating this option may cause some performance degradation, read more about this in the [trac:TracPerformance#Configuration Trac performance] page.

  == Preset Values for New Tickets ==

  To create a link to the new-ticket form filled with preset values, you need to call the `/newticket?` URL with `variable=value` separated by `&`. 

  Possible variables are :

   * '''type''' — The type droplist
   * '''reporter''' — Name or email of the reporter
   * '''summary''' — Summary line for the ticket
   * '''description''' — Long description of the ticket
   * '''component''' — The component droplist
   * '''version''' — The version droplist
   * '''severity''' — The severity droplist
   * '''keywords''' — The keywords 
   * '''priority''' — The priority droplist
   * '''milestone''' — The milestone droplist
   * '''owner''' — The person responsible for the ticket
   * '''cc''' — The list of emails for notifying about the ticket change

  Example: ''`[/newticket?summary=Compile%20Error&version=1.0&component=gui]`''[[BR]]

  ----
  See also:  TracGuide, TracWiki, TracTicketsCustomFields, TracNotification, TracReports, TracQuery


name: TracRepositoryAdmin
author: trac
ipnr: 127.0.0.1
text:
  = Repository Administration =
  [[PageOutline(2-3)]]

  == Quick start == #QuickStart

   * Manage repositories in the "Repository" admin panel, with `trac-admin` or in the `[repositories]` section of [wiki:TracIni#repositories-section trac.ini].
   * Set up a call to `trac-admin $ENV changeset added $REPO $REV` in the post-commit hook of each repository. Additionally, add a call to `trac-admin $ENV changeset modified $REPO $REV` in the post-revprop-change hook of repositories allowing revision property changes.
   * Set the `[trac] repository_sync_per_request` option to an empty value to disable per-request syncing.
   * Make sure the user under which your Subversion hooks are run has write access to the Trac environment, or use a tool like `sudo` to temporarily elevate privileges.

  == Specifying repositories == #Repositories
  Starting with 0.12, Trac can handle more than one repository per environment. The pre-0.12 way of specifying the repository with the `repository_dir` and `repository_type` options in the `[trac]` section of [wiki:TracIni trac.ini] is still supported, but two new mechanisms allow including additional repositories into an environment.

  It is also possible to define aliases of repositories, that act as "pointers" to real repositories. This can be useful when renaming a repository, to avoid breaking all the links to the old name.

  A number of attributes can be associated with each repository, which define the repository's location, type, name and how it is displayed in the source browser. The following attributes are supported:

  ||='''Attribute''' =||='''Description''' =||
  ||`alias` ||\
  ||A repository having an `alias` attribute is an alias to a real repository. All TracLinks referencing the alias resolve to the aliased repository. Note that multiple indirection is not supported, so an alias must always point to a real repository. The `alias` and `dir` attributes are mutually exclusive. ||
  ||`description` ||\
  ||The text specified in the `description` attribute is displayed below the top-level entry for the repository in the source browser. It supports WikiFormatting. ||
  ||`dir` ||\
  ||The `dir` attribute specifies the location of the repository in the filesystem. It corresponds to the value previously specified in the option `[trac] repository_dir`. The `alias` and `dir` attributes are mutually exclusive. ||
  ||`hidden` ||When set to `true`, the repository is hidden from the repository index page in the source browser. Browsing the repository is still possible, and links referencing the repository remain valid. ||
  ||`type` ||The `type` attribute sets the type of version control system used by the repository. Trac supports Subversion out-of-the-box, and plugins add support for many other systems. If `type` is not specified, it defaults to the value of the `[trac] repository_type` option. ||
  ||`url` ||The `url` attribute specifies the root URL to be used for checking out from the repository. When specified, a "Repository URL" link is added to the context navigation links in the source browser, that can be copied into the tool used for creating the working copy. ||

  A repository `name` and one of `alias` or `dir` attributes are mandatory. All others are optional.

  After adding a repository, the cache for that repository must be re-synchronized once with the `trac-admin $ENV repository resync` command.

   `repository resync <repos>`::
     Re-synchronize Trac with a repository.


  === In `trac.ini` === #ReposTracIni
  Repositories and repository attributes can be specified in the `[repositories]` section of [wiki:TracIni#repositories-section trac.ini]. Every attribute consists of a key structured as `{name}.{attribute}` and the corresponding value separated with an equal sign (`=`). The name of the default repository is empty.

  The main advantage of specifying repositories in `trac.ini` is that they can be inherited from a global configuration (see the [wiki:TracIni#GlobalConfiguration global configuration] section of TracIni). One drawback is that, due to limitations in the `ConfigParser` class used to parse `trac.ini`, the repository name is always all-lowercase.

  The following example defines two Subversion repositories named `project` and `lib`, and an alias to `project` as the default repository. This is a typical use case where a Trac environment previously had a single repository (the `project` repository), and was converted to multiple repositories. The alias ensures that links predating the change continue to resolve to the `project` repository.
  {{{
  #!ini
  [repositories]
  project.dir = /var/repos/project
  project.description = This is the ''main'' project repository.
  project.type = svn
  project.url = http://example.com/svn/project
  project.hidden = true

  lib.dir = /var/repos/lib
  lib.description = This is the secondary library code.
  lib.type = svn
  lib.url = http://example.com/svn/lib

  .alias = project
  }}}
  Note that `name.alias = target` makes `name` an alias for the `target` repo, not the other way around.

  === In the database === #ReposDatabase
  Repositories can also be specified in the database, using either the "Repositories" admin panel under "Version Control", or the `trac-admin $ENV repository` commands.

  The admin panel shows the list of all repositories defined in the Trac environment. It allows adding repositories and aliases, editing repository attributes and removing repositories. Note that repositories defined in `trac.ini` are displayed but cannot be edited.

  The following [wiki:TracAdmin trac-admin] commands can be used to perform repository operations from the command line.

   `repository add <repos> <dir> [type]`::
     Add a repository `<repos>` located at `<dir>`, and optionally specify its type.

   `repository alias <name> <target>`::
     Create an alias `<name>` for the repository `<target>`.

   `repository remove <repos>`::
     Remove the repository `<repos>`.

   `repository set <repos> <key> <value>`::
     Set the attribute `<key>` to `<value>` for the repository `<repos>`. 

  Note that the default repository has an empty name, so it will likely need to be quoted when running `trac-admin` from a shell. Alternatively, the name "`(default)`" can be used instead, for example when running `trac-admin` in interactive mode.


  == Repository synchronization == #Synchronization
  Prior to 0.12, Trac synchronized its cache with the repository on every HTTP request. This approach is not very efficient and not practical anymore with multiple repositories. For this reason, explicit synchronization through post-commit hooks was added. 

  There is also new functionality in the form of a repository listener extension point ''(IRepositoryChangeListener)'' that is triggered by the post-commit hook when a changeset is added or modified, and can be used by plugins to perform actions on commit.

  === Mercurial Repositories ===
  Please note that at the time of writing, no initial resynchronization or any hooks are necessary for Mercurial repositories - see [trac:#9485] for more information. 

  === Explicit synchronization === #ExplicitSync
  This is the preferred method of repository synchronization. It requires setting the `[trac]  repository_sync_per_request` option in [wiki:TracIni#trac-section trac.ini] to an empty value, and adding a call to `trac-admin` in the post-commit hook of each repository. Additionally, if a repository allows changing revision metadata, a call to `trac-admin` must be added to the post-revprop-change hook as well.

   `changeset added <repos> <rev> [...]`::
     Notify Trac that one or more changesets have been added to a repository.

   `changeset modified <repos> <rev> [...]`::
     Notify Trac that metadata on one or more changesets in a repository has been modified.

  The `<repos>` argument can be either a repository name (use "`(default)`" for the default repository) or the path to the repository.

  Note that you may have to set the environment variable PYTHON_EGG_CACHE to the same value as was used for the web server configuration before calling trac-admin, if you changed it from its default location. See [wiki:TracPlugins Trac Plugins] for more information.

  The following examples are complete post-commit and post-revprop-change scripts for Subversion. They should be edited for the specific environment, marked executable (where applicable) and placed in the `hooks` directory of each repository. On Unix (`post-commit`):
  {{{#!sh
  #!/bin/sh
  export PYTHON_EGG_CACHE="/path/to/dir"
  /usr/bin/trac-admin /path/to/env changeset added "$1" "$2"
  }}}
  Note: Ubuntu doesn't seem to like /usr/bin/trac-admin, so just use:
  {{{#!sh
  #!/bin/sh
  export PYTHON_EGG_CACHE="/path/to/dir"
  trac-admin /path/to/env/ changeset added "$1" "$2"
  }}}
  On Windows (`post-commit.cmd`):
  {{{#!application/x-dos-batch
  @C:\Python26\Scripts\trac-admin.exe C:\path\to\env changeset added "%1" "%2"
  }}}

  The post-revprop-change hook for Subversion is very similar. On Unix (`post-revprop-change`):
  {{{#!sh
  #!/bin/sh
  export PYTHON_EGG_CACHE="/path/to/dir"
  /usr/bin/trac-admin /path/to/env changeset modified "$1" "$2"
  }}}
  On Windows (`post-revprop-change.cmd`):
  {{{#!application/x-dos-batch
  @C:\Python26\Scripts\trac-admin.exe C:\path\to\env changeset modified "%1" "%2"
  }}}

  The Unix variants above assume that the user running the Subversion commit has write access to the Trac environment, which is the case in the standard configuration where both the repository and Trac are served by the web server. If you access the repository through another means, for example `svn+ssh://`, you may have to run `trac-admin` with different privileges, for example by using `sudo`.

  Note that calling `trac-admin` in your Subversion hooks can slow down the commit and log editing operations on the client side. You might want to use the [trac:source:trunk/contrib/trac-svn-hook contrib/trac-svn-hook] script which starts `trac-admin` in an asynchronous way. The script also comes with a number of safety checks and usage advices which should make it easier to set up and test your hooks. There's no equivalent `trac-svn-hook.bat` for Windows yet, but the script can be run by Cygwin's bash.

  See the [http://svnbook.red-bean.com/en/1.5/svn.reposadmin.create.html#svn.reposadmin.create.hooks section about hooks] in the Subversion book for more information. Other repository types will require different hook setups.

  Git hooks can be used in the same way for explicit syncing of git repositories. Add the following to `.git/hooks/post-commit`:
  {{{#!sh
  REV=$(git rev-parse HEAD)
  trac-admin /path/to/env changeset added <my-repository> $REV
  }}}

  For Mercurial, add the following entries to the `.hgrc` file of each repository accessed by Trac (if [trac:TracMercurial] is installed in a Trac `plugins` directory, download [trac:source:mercurial-plugin/tracext/hg/hooks.py hooks.py] and place it somewhere accessible):
  {{{#!ini
  [hooks]
  ; If mercurial-plugin is installed globally
  commit = python:tracext.hg.hooks.add_changesets
  changegroup = python:tracext.hg.hooks.add_changesets

  ; If mercurial-plugin is installed in a Trac plugins directory
  commit = python:/path/to/hooks.py:add_changesets
  changegroup = python:/path/to/hooks.py:add_changesets

  [trac]
  env = /path/to/env
  trac-admin = /path/to/trac-admin
  }}}

  === Per-request synchronization === #PerRequestSync
  If the post-commit hooks are not available, the environment can be set up for per-request synchronization. In that case, the `[trac] repository_sync_per_request` option in [wiki:TracIni#trac-section trac.ini] must be set to a comma-separated list of repository names to be synchronized.

  Note that in this case, the changeset listener extension point is not called, and therefore plugins using it will not work correctly.


  == Migration from a single-repository setup (Subversion) == #Migration
  The following procedure illustrates a typical migration from a Subversion single-repository setup to multiple repositories.

   1. Remove the default repository specification from the `[trac] repository_dir` option.
   1. Add the main repository as a named repository.
   1. Re-synchronize the main repository.
   1. Set up post-commit and post-revprop-change hooks on the "main" repository, and set `[trac] repository_sync_per_request` to an empty value.
   1. Add an alias to the main repository as the default repository (by leaving out the the `name`, e.g. `.alias = main`). This ensures that all links predating the migration still resolve to the main repository.
   1. Repeat steps 2, 3 and 4 to add other "named" repositories as needed.

  == Migration from a single-repository setup (Mercurial) == #MigrationMercurial
  The following procedure illustrates a typical migration from a Mercurial single-repository setup to multiple repositories. Please note that at the time of writing, no initial resynchronization or any hooks are necessary for Mercurial repositories - see [trac:ticket:9485 #9485] for more information.

   1. Upgrade to the latest version of the TracMercurial plugin.
   1. Remove the default repository specification from the `[trac] repository_dir` option.
   1. Add the main repository as a named repository.
   1. Add an alias to the main repository as the default repository (by leaving out the the `name`, e.g. `.alias = main`). This ensures that all links predating the migration still resolve to the main repository.
   1. Repeat step 3 to add other "named" repositories as needed.

  == Troubleshooting ==

  === My trac-post-commit-hook doesn't work anymore === #trac-post-commit-hook

  You must now use the optional components from `tracopt.ticket.commit_updater.*`, which you can activate through the Plugins panel in the Administrative part of the web interface, or by directly modifying the [TracIni#components-section "[components]"] section in the trac.ini. Be sure to use [#ExplicitSync explicit synchronization] as explained above.


name: TracWiki
author: trac
ipnr: 127.0.0.1
text:
  = The Trac Wiki System =
  [[TracGuideToc]]

  Trac has a built-in wiki system which you can use for organizing knowledge and information in a very flexible way by [WikiNewPage creating pages] containing an intuitive and easy to learn textual markup. This text markup is also used in all other parts of the system, not only in [wiki:TitleIndex wiki pages], but also in [wiki:TracTickets ticket] description and comments, [wiki:TracChangeset check-in log messages], [wiki:TracRoadmap milestone] descriptions and [wiki:TracReports report] descriptions, even in third-party extensions.
  It allows for formatted text and hyperlinks in and between all Trac modules.

  Editing wiki text is easy, using any web browser and a simple [WikiFormatting formatting system], rather than more complex markup languages like HTML.  The reasoning behind its design is that HTML, with its large collection of nestable tags, is too complicated to allow fast-paced editing, and distracts from the actual content of the pages. Note though that Trac also supports [WikiHtml HTML], [WikiRestructuredText reStructuredText] and [http://www.textism.com/tools/textile/ Textile] as alternative markup formats, which can eventually be used in parts of a page (so called wiki “blocks”).

  The main goal of the wiki is to make editing text easier and ''encourage'' people to contribute and annotate text content for a project. Trac also provides a simple toolbar to make formatting text even easier, and supports the [http://universaleditbutton.org/Universal_Edit_Button universal edit button] of your browser.

  The wiki itself does not enforce any structure, but rather resembles a stack of empty sheets of paper, where you can organize information and documentation as you see fit, and later reorganize if necessary. 
  As contributing to a wiki is essentially building hypertext, 
  general advice regarding HTML authoring apply here as well.
  For example, the ''[http://www.w3.org/Provider/Style Style Guide for online hypertext]'' explains how to think about the
  [http://www.w3.org/Provider/Style/Structure.html overall structure of a work] 
  and how to organize information [http://www.w3.org/Provider/Style/WithinDocument.html within each document]. One of the most important tip is “make your HTML page such that you can read it even if you don't follow any links.”

  Learn more about:
   * WikiFormatting rules, including advanced topics like WikiMacros and WikiProcessors
   * How to use WikiPageNames and other forms of TracLinks which are used to refer in a precise way to any resource within Trac

  If you want to practice editing, please use the SandBox. Note that not all Trac wikis are editable by anyone, this depends on the local policy; check with your Trac administrators.

  Before saving your changes, you can ''Preview'' the page or ''Review the Changes'' you've made.
  You can get an automatic preview of the formatting as you type when you activate the ''Edit Side-by-side'' mode (you have to Preview the page for the setting to take effect). '' There is a [wiki:/TracIni#trac-section configurable delay] between when you make your edit and when the automatic preview will update.''

  Some more information about wikis on the web:
   * A definition of [http://wikipedia.org/wiki/Wiki Wiki], in a famous wiki encyclopedia
   * The [http://c2.com/cgi/wiki?WikiHistory History] of the original wiki
   * A wiki page explaining [http://www.usemod.com/cgi-bin/mb.pl?WhyWikiWorks why wiki works]

  ----
  See also: TracGuide


name: WikiHtml
author: trac
ipnr: 127.0.0.1
text:
  = Using HTML in Wiki Text =

  Trac supports inserting HTML into any wiki context, accomplished using the `#!html` [wiki:WikiProcessors WikiProcessor]. 

  However a constraint is that this HTML has to be well-formed.
  In particular you can't insert a start tag in an `#!html` block,
  resume normal wiki text and insert the corresponding end tag in a 
  second `#!html` block. 

  Fortunately, for creating styled <div>s, <span>s  or even complex tables
  containing arbitrary Wiki text, there's a powerful alternative: use of
  dedicated `#!div`, `#!span` and `#!table`, `#!tr`, `#!td` and `#!th` blocks.

  Those Wiki processors are built-in, and does not require installing any additional packages.

  == How to use `#!html` == #HowtoUseHTML
  To inform the wiki engine that a block of text should be treated as HTML, use the ''html'' processor. 

  ||= Wiki Markup =||= Display =||
  {{{#!td
    {{{
    {{{
    #!html
    <h1 style="text-align: right; color: blue">HTML Test</h1>
    }}}
    }}}
  }}}
  {{{#!td style="padding-left: 2em"
    {{{
    #!html
    <h1 style="text-align: right; color: blue">HTML Test</h1>
    }}}
  }}}

  Note that Trac sanitizes your HTML code before displaying it. That means that if you try to use potentially dangerous constructs such as Javascript event handlers, those will be removed from the output. 

  Since 0.11, the filtering is done by Genshi, and as such, the produced output will be a well-formed fragment of HTML. As noted above in the introduction, this mean that you can no longer use two HTML blocks, one for opening a <div>, the second for closing it, in order to wrap arbitrary wiki text.
  The new way to wrap any wiki content inside a <div> is to use the `#!div` Wiki  processor.

  == How to use `#!div` and `#!span` == #HowtoUseDivSpan

  ||= Wiki Markup =||= Display =||
  {{{#!td
    {{{
    {{{
    #!div class="important" 
    **important** is a predefined class.
    }}}
    }}}
    {{{
    {{{
    #!div style="border: 1pt dotted; margin: 1em"
    **wikipage** is another predefined class that will 
    be used when no class is specified.
    }}}
    }}}
    {{{
    {{{
    #!div class="compact" style="border: 1pt dotted; margin: 1em"
    **compact** is another predefined class reducing
    the padding within the `<div>` to a minimum.
    }}}
    }}}
    {{{
    {{{
    #!div class="wikipage compact" style="border: 1pt dotted"
    Classes can be combined (here **wikipage** and **compact**)
    which results in this case in reduced //vertical// 
    padding but there's still some horizontal space for coping
    with headings.
    }}}
    }}}
    {{{
    {{{
    #!div class="" style="border: 1pt dotted; margin: 1em"
    Explicitly specifying no classes is //not// the same
    as specifying no class attribute, as this will remove
    the //wikipage// default class.
    }}}
    }}}
  }}}
  {{{#!td style="padding-left: 2em"

    {{{
    #!div class="important" 
    **important** is a predefined class.
    }}}

    {{{
    #!div style="border: 1pt dotted; margin: 1em"
    **wikipage** is another predefined class that will 
    be used when no class is specified.
    }}}

    {{{
    #!div class="compact" style="border: 1pt dotted; margin: 1em"
    **compact** is another predefined class reducing
    the padding within the `<div>` to a minimum.
    }}}

    {{{
    #!div class="wikipage compact" style="border: 1pt dotted"
    Classes can be combined (here **wikipage** and **compact**)
    which results in this case in reduced //vertical// 
    padding but there's still some horizontal space for coping
    with headings.
    }}}

    {{{
    #!div class="" style="border: 1pt dotted; margin: 1em"
    Explicitly specifying no classes is //not// the same
    as specifying no class attribute, as this will remove
    the //wikipage// default class.
    }}}

  }}}

  Note that the contents of a `#!div` block are contained in one or more paragraphs, which have a non-zero top and bottom margin. This leads to the top and bottom padding in the example above. To remove the top and bottom margin of the contents, add the `compact` class to the `#!div`. Another predefined class besides `wikipage` and `compact` is `important`, which can be used to make a paragraph stand out. Extra CSS classes can be defined via the `site/style.css` file for example, see TracInterfaceCustomization#SiteAppearance.

  For spans, you should rather use the Macro call syntax:
  ||= Wiki Markup =||
  {{{#!td
    {{{
    Hello 
    [[span(''WORLD'' (click [#anchor here]), style=color: green; font-size: 120%, id=anchor)]]!
    }}}
  }}}
  |---------------------------------------------------------------------------------
  ||= Display =||
  {{{#!td style="padding-left: 2em"
    Hello
    [[span(''WORLD'' (click [#anchor here]), style=color: green; font-size: 120%, id=anchor)]]!
  }}}

  == How to use `#!td` and other table related processors == #Tables

  `#!td` or `#!th` processors are actually the main ones, for creating table data and header cells, respectively. The other processors `#!table` and `#!tr` are not required for introducing a table structure, as `#!td` and `#!th` will do this automatically. The `|-` row separator can be used to start a new row when needed, but some may prefer to use a `#!tr` block for that, as this introduces a more formal grouping and offers the possibility to use an extra level of indentation. The main purpose of the `#!table` and `#!tr` is to give the possibility to specify HTML attributes, like ''style'' or ''valign'' to these elements.

  ||= Wiki Markup =||= Display =||
  {{{#!td
   {{{
   Simple 2x2 table with rich content:
   {{{#!th align=left
    - Left
    - Header
   }}}
   {{{#!th align=left
    - Right
    - Header
   }}}
   |----------------------------------
   {{{#!td style="background: #ffd"
    - Left
    - Content
   }}}
   {{{#!td style="vertical-align: top"
   !RightContent
   }}}
   |----------------------------------
   || ... and this can be mixed||\
   ||with pipe-based cells ||
   {{{#!td colspan=2
   Pick the style the more appropriate
   to your content
   
   See WikiFormatting#Tables for details
   on the pipe-based table syntax.
   }}}
   
   If one needs to add some 
   attributes to the table itself...
   
   {{{
   #!table style="border:none;text-align:center;margin:auto"
     {{{#!tr ====================================
       {{{#!th style="border: none"
       Left header
       }}}
       {{{#!th style="border: none"
       Right header
       }}}
     }}}
     {{{#!tr ==== style="border: 1px dotted grey"
       {{{#!td style="border: none"
       1.1
       }}}
       {{{#!td style="border: none"
       1.2
       }}}
     }}}
     {{{#!tr ====================================
       {{{#!td style="border: none"
       2.1
       }}}
       {{{#!td
       2.2
       }}}
     }}}
   }}}


   }}}
  }}}
  {{{#!td valign=top
  Simple 2x2 table with rich content:
  {{{#!th align=left
   - Left
   - Header
  }}}
  {{{#!th align=left
   - Right
   - Header
  }}}
  |----------------------------------
  {{{#!td style="background: #ffd"
   - Left
   - Content
  }}}
  {{{#!td style="vertical-align: top"
  !RightContent
  }}}
  |----------------------------------
  || ... and this can be mixed||\
  ||with pipe-based cells ||
  {{{#!td colspan=2
  Pick the style the more appropriate
  to your content

  See WikiFormatting#Tables for details
  on the pipe-based table syntax.
  }}}

  If one needs to add some 
  attributes to the table itself...

  {{{
  #!table style="border:none;text-align:center;margin:auto"
    {{{#!tr ====================================
      {{{#!th style="border: none"
      Left header
      }}}
      {{{#!th style="border: none"
      Right header
      }}}
    }}}
    {{{#!tr ==== style="border: 1px dotted grey"
      {{{#!td style="border: none"
      1.1
      }}}
      {{{#!td style="border: none"
      1.2
      }}}
    }}}
    {{{#!tr ====================================
      {{{#!td style="border: none"
      2.1
      }}}
      {{{#!td
      2.2
      }}}
    }}}
  }}}
  }}}

  Note that by default tables are assigned the "wiki" CSS class, which gives a distinctive look to the header cells and a default border to the table and cells (as can be seen for the tables on this page). By removing this class (`#!table class=""`), one regains complete control on the table presentation. In particular, neither the table, the rows nor the cells will have a border, so this is a more effective way to get such an effect than having to specify a `style="border: no"` parameter everywhere. 

  {{{#!table class=""
  ||= Wiki Markup =||= Display =||
   {{{#!td
    {{{
    {{{#!table class=""
    ||  0||  1||  2||
    || 10|| 20|| 30||
    || 11|| 22|| 33||
    ||||||=  numbers  =||
    }}}
    }}}
   }}}
   {{{#!td
    {{{#!table class=""
    ||  0||  1||  2||
    || 10|| 20|| 30||
    || 11|| 22|| 33||
    ||||||=  numbers  =||
    }}}
   }}}
  }}}

  Other classes can be specified as alternatives (remember that you can define your own in [TracInterfaceCustomization#SiteAppearance site/style.css]).

  ||= Wiki Markup =||= Display =||
  {{{#!td
    {{{
    {{{#!table class="listing"
    ||  0||  1||  2||
    || 10|| 20|| 30||
    || 11|| 22|| 33||
    ||||||=  numbers  =||
    }}}
    }}}
  }}}
  {{{#!td
    {{{#!table class="listing"
    ||  0||  1||  2||
    || 10|| 20|| 30||
    || 11|| 22|| 33||
    ||||||=  numbers  =||
    }}}
  }}}


  == HTML comments ==
  HTML comments are stripped from the output of the `html` processor. To add an HTML comment to a wiki page, use the `htmlcomment` processor (available since 0.12). For example, the following code block:
  ||= Wiki Markup =||
  {{{#!td
    {{{
    {{{
    #!htmlcomment
    This block is translated to an HTML comment.
    It can contain <tags> and &entities; that will not be escaped in the output.
    }}}
    }}}
  }}}
  |---------------------------------------------------------------------------------
  ||= Display =||
  {{{#!td
    {{{
    <!--
    This block is translated to an HTML comment.
    It can contain <tags> and &entities; that will not be escaped in the output.
    -->
    }}}
  }}}

  Please note that the character sequence "`--`" is not allowed in HTML comments, and will generate a rendering error.


  == More Information ==

   * http://www.w3.org/ -- World Wide Web Consortium
   * http://www.w3.org/MarkUp/ -- HTML Markup Home Page

  ----
  See also:  WikiProcessors, WikiFormatting, WikiRestructuredText


name: SandBox
author: trac
ipnr: 127.0.0.1
text:
  = The Sandbox =

  This is just a page to practice and learn WikiFormatting. 

  Go ahead, edit it freely.


name: WikiProcessors
author: trac
ipnr: 127.0.0.1
text:
  = Wiki Processors =

  Processors are WikiMacros designed to provide alternative markup formats for the [TracWiki Wiki engine]. Processors can be thought of as ''macro functions to process user-edited text''. 

  Wiki processors can be used in any Wiki text throughout Trac,
  for various different purposes, like:
   - [#CodeHighlightingSupport syntax highlighting] or for rendering text verbatim,
   - rendering [#HTMLrelated Wiki markup inside a context], 
     like inside <div> blocks or <span> or within <td> or <th> table cells,
   - using an alternative markup syntax, like [wiki:WikiHtml raw HTML] and
     [wiki:WikiRestructuredText Restructured Text],
     or [http://www.textism.com/tools/textile/ textile]


  == Using Processors ==

  To use a processor on a block of text, first delimit the lines using
  a Wiki ''code block'':
  {{{
  {{{
  The lines
  that should be processed...
  }}}
  }}}

  Immediately after the `{{{` or on the line just below, 
  add `#!` followed by the ''processor name''.

  {{{
  {{{
  #!processorname
  The lines
  that should be processed...
  }}}
  }}}

  This is the "shebang" notation, familiar to most UNIX users.

  Besides their content, some Wiki processors can also accept ''parameters'',
  which are then given as `key=value` pairs after the processor name, 
  on the same line. If `value` has to contain space, as it's often the case for
  the style parameter, a quoted string can be used (`key="value with space"`).

  As some processors are meant to process Wiki markup, it's quite possible to
  ''nest'' processor blocks.
  You may want to indent the content of nested blocks for increased clarity,
  this extra indentation will be ignored when processing the content.


  == Examples ==

  ||= Wiki Markup =||= Display =||
  {{{#!td colspan=2 align=center style="border: none"

                  __Example 1__: Inserting raw HTML
  }}}
  |-----------------------------------------------------------------
  {{{#!td style="border: none"
  {{{
  {{{
  #!html
  <h1 style="color: grey">This is raw HTML</h1>
  }}}
  }}}
  }}}
  {{{#!td valign=top style="border: none; padding-left: 2em"
  {{{
  #!html
  <h1 style="color: grey">This is raw HTML</h1>
  }}}
  }}}
  |-----------------------------------------------------------------
  {{{#!td colspan=2 align=center style="border: none"

       __Example 2__: Highlighted Python code in a <div> block with custom style
  }}}
  |-----------------------------------------------------------------
  {{{#!td style="border: none"
    {{{
    {{{#!div style="background: #ffd; border: 3px ridge"

    This is an example of embedded "code" block:

      {{{
      #!python
      def hello():
          return "world"
      }}}

    }}}
    }}}
  }}}
  {{{#!td valign=top style="border: none; padding: 1em"
    {{{#!div style="background: #ffd; border: 3px ridge"

    This is an example of embedded "code" block:

      {{{
      #!python
      def hello():
          return "world"
      }}}

    }}}
  }}}
  |-----------------------------------------------------------------
  {{{#!td colspan=2 align=center style="border: none"

       __Example 3__: Searching tickets from a wiki page, by keywords.
  }}}
  |-----------------------------------------------------------------
  {{{#!td style="border: none"
    {{{
    {{{
    #!html
    <form action="/query" method="get"><div>
    <input type="text" name="keywords" value="~" size="30"/>
    <input type="submit" value="Search by Keywords"/>
    <!-- To control what fields show up use hidden fields
    <input type="hidden" name="col" value="id"/>
    <input type="hidden" name="col" value="summary"/>
    <input type="hidden" name="col" value="status"/>
    <input type="hidden" name="col" value="milestone"/>
    <input type="hidden" name="col" value="version"/>
    <input type="hidden" name="col" value="owner"/>
    <input type="hidden" name="col" value="priority"/>
    <input type="hidden" name="col" value="component"/>
    -->
    </div></form>
    }}}
    }}}
  }}}
  {{{#!td valign=top style="border: none; padding: 1em"
    {{{
    #!html
    <form action="/query" method="get"><div>
    <input type="text" name="keywords" value="~" size="30"/>
    <input type="submit" value="Search by Keywords"/>
    <!-- To control what fields show up use hidden fields
    <input type="hidden" name="col" value="id"/>
    <input type="hidden" name="col" value="summary"/>
    <input type="hidden" name="col" value="status"/>
    <input type="hidden" name="col" value="milestone"/>
    <input type="hidden" name="col" value="version"/>
    <input type="hidden" name="col" value="owner"/>
    <input type="hidden" name="col" value="priority"/>
    <input type="hidden" name="col" value="component"/>
    -->
    </div></form>
    }}}
  }}}
  == Available Processors ==

  The following processors are included in the Trac distribution:

  || '''`#!default`''' || Present the text verbatim in a preformatted text block. This is the same as specifying ''no'' processor name (and no `#!`) ||
  || '''`#!comment`''' || Do not process the text in this section (i.e. contents exist only in the plain text - not in the rendered page). ||
  |||| ||
  ||||= '''HTML related''' =||
  || '''`#!html`''' || Insert custom HTML in a wiki page. ||
  || '''`#!htmlcomment`''' || Insert an HTML comment in a wiki page (''since 0.12''). ||
  || || Note that `#!html` blocks have to be ''self-contained'', i.e. you can't start an HTML element in one block and close it later in a second block. Use the following processors for achieving a similar effect.  ||
  || '''`#!div`''' || Wrap an arbitrary Wiki content inside a <div> element (''since 0.11''). ||
  || '''`#!span`''' || Wrap an arbitrary Wiki content inside a <span> element (''since 0.11''). ||
  || '''`#!td`''' || Wrap an arbitrary Wiki content inside a <td> element (''since 0.12'') ||
  || '''`#!th`''' || Wrap an arbitrary Wiki content inside a <th> element (''since 0.12'') ||
  || '''`#!tr`''' || Can optionally be used for wrapping `#!td` and `#!th` blocks, either for specifying row attributes of better visual grouping (''since 0.12'') ||
  || || See WikiHtml for example usage and more details about these processors. ||
  |||| ||
  ||||= '''Other Markups''' =||
  || '''`#!rst`''' || Trac support for Restructured Text. See WikiRestructuredText. ||
  || '''`#!textile`''' || Supported if [http://cheeseshop.python.org/pypi/textile Textile] is installed. See [http://www.textism.com/tools/textile/ a Textile reference]. ||
  |||| ||
  ||||= '''Code Highlighting Support''' =||
  || '''`#!c`''' [[BR]] '''`#!cpp`''' (C++) [[BR]] '''`#!python`''' [[BR]] '''`#!perl`''' [[BR]] '''`#!ruby`''' [[BR]] '''`#!php`''' [[BR]] '''`#!asp`''' [[BR]] '''`#!java`''' [[BR]] '''`#!js`''' (Javascript) [[BR]] '''`#!sql`''' [[BR]] '''`#!xml`''' (XML or HTML) [[BR]] '''`#!sh`''' (!Bourne/Bash shell) [[BR]] '''etc.''' [[BR]] || Trac includes processors to provide inline syntax highlighting for source code in various languages. [[BR]] [[BR]] Trac relies on external software packages for syntax coloring, like [http://pygments.org Pygments]. [[BR]] [[BR]] See TracSyntaxColoring for information about which languages are supported and how to enable support for more languages. ||
  |||| ||
  ||||= '''MIME Type Processors''' =||
  |||| Using the MIME type as processor, it is possible to syntax-highlight the same languages that are supported when browsing source code. ||
  {{{#!tr
  {{{#!td
  Some examples:
   {{{
  {{{
  #!text/html
  <h1>text</h1>
  }}}
   }}}
  }}}
  {{{#!td
  The result will be syntax highlighted HTML code:
   {{{
  #!text/html
  <h1>text</h1>
   }}}

  The same is valid for all other [TracSyntaxColoring#SyntaxColoringSupport mime types supported].
  }}}
  }}}
  {{{#!td
   {{{
  {{{
  #!diff
  --- Version 55
  +++ Version 56
  @@ -115,8 +115,9 @@
       name='TracHelloWorld', version='1.0',
       packages=find_packages(exclude=['*.tests*']),
  -    entry_points = """
  -        [trac.plugins]
  -        helloworld = myplugs.helloworld
  -    """,
  +    entry_points = {
  +        'trac.plugins': [
  +            'helloworld = myplugs.helloworld',
  +        ],
  +    },
   )
  }}}
   }}}
  }}}
  {{{#!td
  '''`#!diff`''' has a particularly nice renderer:
   {{{
  #!diff
  --- Version 55
  +++ Version 56
  @@ -115,8 +115,9 @@
       name='TracHelloWorld', version='1.0',
       packages=find_packages(exclude=['*.tests*']),
  -    entry_points = """
  -        [trac.plugins]
  -        helloworld = myplugs.helloworld
  -    """,
  +    entry_points = {
  +        'trac.plugins': [
  +            'helloworld = myplugs.helloworld',
  +        ],
  +    },
   )
   }}}
  }}}

  For more processor macros developed and/or contributed by users, visit: 
   * [trac:ProcessorBazaar]
   * [trac:MacroBazaar]
   * [http://trac-hacks.org Trac Hacks] community site

  Developing processors is no different from Wiki macros. 
  In fact they work the same way, only the usage syntax differs. 
  See WikiMacros#DevelopingCustomMacros for more information.


  ----
  See also: WikiMacros, WikiHtml, WikiRestructuredText, TracSyntaxColoring, WikiFormatting, TracGuide


name: WikiDeletePage
author: trac
ipnr: 127.0.0.1
text:
  = Deleting a Wiki Page =

  Existing wiki pages can be completely deleted using the ''Delete Page'' or the ''Delete this Version'' buttons at the bottom of the wiki page. These buttons are only visible for users with `WIKI_DELETE` permissions.

  '''Note:''' Deleting a wiki page is an irreversible operation.

  If you want to delete a page because you actually re-created a new page with the same content but a different name, it is recommended to keep the page and use it as a redirection page instead of completely deleting it, as to not frustrate the visitor with broken links when coming to the site from a search engine. 

  In this situation, chances are that you actually wanted to [[WikiNewPage#renaming|rename]] the page instead of doing a copy + delete. 
  The ''Rename'' operation also offers you the possibility to create a redirection page.
  A redirection page is a short page that  contains a link such as  “See !SomeOtherPage”. 

  However, deleting specific versions or even complete pages can make sense to remove spam or other abusive submissions.

  ----
  See also: TracWiki, TracPermissions


name: TracChangeset
author: trac
ipnr: 127.0.0.1
text:
  = Trac Changeset Module =
  [[TracGuideToc]]

  Trac has a built-in functionality for visualizing “diffs” - changes to files.

  There are different kinds of ''change sets''. 
  Some can correspond to revisions made in the repositories,
  others can aggregate changes made in several revisions, 
  but in the end, any kind of differences can be shown.

  The changeset view consists of two parts, the ''header'' 
  and the ''diff views''.

  == Changeset Header ==

  The header shows an overview of the whole changeset.
  Here you will find information such as:

   * Timestamp — When the changeset was commited
   * Author — Who commited the changeset
   * Message — A brief description from the author (the commit log message)
   * Location — Parent directory of all files affected by this changeset
   * Files — A list of files affected by this changeset

  If more than one revision is involved in the set of changes being
  displayed, the ''Timestamp'', ''Author'' and ''Message'' fields 
  won't be shown.

  In front of each listed file, you'll find  a colored rectangle. The color
  indicates how the file is affected by the changeset.
   
   [[span(style=background:#bfb;border:1px solid #999;font-size:80%;margin-right:.5em,''  '')]] Green: Added \\
   [[span(style=background:#f88;border:1px solid #999;font-size:80%;margin-right:.5em,''  '')]] Red: Removed \\
   [[span(style=background:#fd8;border:1px solid #999;font-size:80%;margin-right:.5em,''  '')]] Yellow: Modified \\
   [[span(style=background:#88f;border:1px solid #999;font-size:80%;margin-right:.5em,''  '')]] Blue: Copied \\
   [[span(style=background:#ccc;border:1px solid #999;font-size:80%;margin-right:.5em,''  '')]] Gray: Moved \\
  The color legend is located below the header as a reminder.

  == Diff Views ==

  Below the header is the main part of the changeset, the diff view. Each file is shown in a separate section, each of which will contain only the regions of the file that are affected by the changeset. There are two different styles of displaying the diffs: ''inline'' or ''side-by-side'' (you can switch between those styles using the preferences form):

   * The ''inline'' style shows the changed regions of a file underneath each other. A region removed from the file will be colored red, an added region will be colored green. If a region was modified, the old version is displayed above the new version. Line numbers on the left side indicate the exact position of the change in both the old and the new version of the file.
   * The ''side-by-side'' style shows the old version on the left and the new version on the right (this will typically require more screen width than the inline style.) Added and removed regions will be colored in the same way as with the inline style (green and red, respectively), but modified regions will have a yellow background.

  In addition, various advanced options are available in the preferences form for adjusting the display of the diffs:
   * You can set how many lines are displayed before and after every change
     (if the value ''all'' is used, then the full file will be shown)
   * You can toggle whether blank lines, case changes and white space changes are ignored, thereby letting you find the functional changes more quickly


  == The Different Ways to Get a Diff ==

  === Examining a Changeset ===

  When viewing a repository check-in, such as when following a
  changeset [wiki:TracLinks link] or a changeset event in the 
  [wiki:TracTimeline timeline], Trac will display the exact changes
  made by the check-in.

  There will be also navigation links to the ''Previous Changeset''
  to and ''Next Changeset''.

  === Examining Differences Between Revisions ===

  Often you'll want to look at changes made on a file 
  or on a directory spanning multiple revisions. The easiest way
  to get there is from the TracRevisionLog, where you can select
  the ''old'' and the ''new'' revisions of the file or directory, and
  then click the ''View changes'' button.

  === Examining Differences Between Branches ===

  One of the core features of version control systems is the possibility
  to work simultaneously on different ''Lines of Developments'', commonly
  called “branches”. Trac enables you to examine the exact differences
  between such branches.

  Using the '''View changes ...''' button in the TracBrowser allows you to enter
  ''From:'' and ''To:'' path/revision pairs. The resulting set of differences consist
  of the changes that should be applied to the ''From:'' content in order
  to get to the ''To:'' content.

  For convenience, it is possible to invert the roles of the ''old'' and the ''new''
  path/revision pairs by clicking the ''Reverse Diff'' link on the changeset page.

  === Checking the Last Change ===

  The last possibility for examining changes is to use the ''Last Change''
  link provided by the TracBrowser.

  This link will take you to the last change that was made on that path.
  From there, you can use the ''Previous Change'' and ''Next Change'' links
  to traverse the change history of the file or directory.

  ----
  See also: TracGuide, TracBrowser


name: InterWiki
author: trac
ipnr: 127.0.0.1
text:
  = Support for InterWiki links =

  ''(since [trac:milestone:0.10 0.10])''

  == Definition ==

  An InterWiki link can be used for referring to a Wiki page
  located in another Wiki system, and by extension, to any object
  located in any other Web application, provided a simple URL 
  mapping can be done.

  At the extreme, InterWiki prefixes can even be used to simply introduce
  links to new protocols, such as `tsvn:` used by [trac:TortoiseSvn TortoiseSvn].

  == Link Syntax ==

  {{{
  <target_wiki>(:<identifier>)+
  }}}

  The link is composed by the targeted Wiki (or system) name,
  followed by a colon (e.g. `MeatBall:`),
  followed by a page specification in the target.
  Note that, as for InterTrac prefixes, '''InterWiki prefixes are case insensitive'''.

  The target Wiki URL is looked up in the `[interwiki]` section of TracIni or in the InterMapTxt wiki page, modeled after MeatBall:InterMapTxt. If a prefix is defined in both the `[interwiki]` section and InterMapTxt, the `[interwiki]` section takes precedence.

  In addition to traditional InterWiki links, where the target
  is simply ''appended'' to the URL, 
  Trac supports parametric InterWiki URLs:
  identifiers `$1`, `$2`, ... in the URL
  will be replaced by corresponding arguments.
  The argument list is formed by splitting the page identifier
  using the ":" separator.

  === [interwiki] ===
  Every option in the `[interwiki]` section in TracIni defines one InterWiki prefix. The option name defines the prefix. The option value defines the URL, optionally followed by a description separated from the URL by whitespace. Parametric URLs are supported as well.

  '''Example:'''
  {{{
  [interwiki]
  MeatBall = http://www.usemod.com/cgi-bin/mb.pl?
  PEP = http://www.python.org/peps/pep-$1.html Python Enhancement Proposal $1
  tsvn = tsvn: Interact with TortoiseSvn
  }}}

  == Examples ==

  If the following is an excerpt of the InterMapTxt page:

  {{{
  = InterMapTxt =
  == This is the place for defining InterWiki prefixes ==

  Currently active prefixes: [[InterWiki]]

  This page is modelled after the MeatBall:InterMapTxt page.
  In addition, an optional comment is allowed after the mapping.
  ----
  {{{
  PEP      http://www.python.org/peps/pep-$1.html           # Python Enhancement Proposal $1 
  Trac-ML  http://thread.gmane.org/gmane.comp.version-control.subversion.trac.general/$1  # Message $1 in Trac Mailing List

  tsvn     tsvn:                                            # Interact with TortoiseSvn
  ...
  MeatBall http://www.usemod.com/cgi-bin/mb.pl?
  MetaWiki http://sunir.org/apps/meta.pl?
  MetaWikiPedia http://meta.wikipedia.org/wiki/
  MoinMoin http://moinmoin.wikiwikiweb.de/
  ...
  }}}
  }}}

  Then, 
   * `MoinMoin:InterWikiMap` should be rendered as MoinMoin:InterWikiMap
     and the ''title'' for that link would be "!InterWikiMap in !MoinMoin"
   * `Trac-ML:4346` should be rendered as Trac-ML:4346
     and the ''title'' for that link would be "Message 4346 in Trac Mailing List"

  ----
  See also: InterTrac, InterMapTxt


name: TracReports
author: trac
ipnr: 127.0.0.1
text:
  ** Note: this page documents the version 1.0 of Trac, see [[0.12/TracReports]] if you need the previous version **
  = Trac Reports =
  [[TracGuideToc]]

  The Trac reports module provides a simple, yet powerful reporting facility
  to present information about tickets in the Trac database.

  Rather than have its own report definition format, TracReports relies on standard SQL
  `SELECT` statements for custom report definition. 

    '''Note:''' ''The report module is being phased out in its current form because it seriously limits the ability of the Trac team to make adjustments to the underlying database schema. We believe that the [wiki:TracQuery query module] is a good replacement that provides more flexibility and better usability. While there are certain reports that cannot yet be handled by the query module, we intend to further enhance it so that at some point the reports module can be completely removed. This also means that there will be no major enhancements to the report module anymore.''

    ''You can already completely replace the reports module by the query module simply by disabling the former in [wiki:TracIni trac.ini]:''
    {{{
    [components]
    trac.ticket.report.* = disabled
    }}}
    ''This will make the query module the default handler for the “View Tickets” navigation item. We encourage you to try this configuration and report back what kind of features of reports you are missing, if any.''

  A report consists of these basic parts:
   * '''ID''' — Unique (sequential) identifier 
   * '''Title''' — Descriptive title
   * '''Description''' — A brief description of the report, in WikiFormatting text.
   * '''Report Body''' — List of results from report query, formatted according to the methods described below.
   * '''Footer''' — Links to alternative download formats for this report.

  == Changing Sort Order ==
  Simple reports - ungrouped reports to be specific - can be changed to be sorted by any column simply by clicking the column header. 

  If a column header is a hyperlink (red), click the column you would like to sort by. Clicking the same header again reverses the order.

  == Changing Report Numbering ==
  There may be instances where you need to change the ID of the report, perhaps to organize the reports better. At present this requires changes to the trac database. The ''report'' table has the following schema ''(since 0.10)'':
   * id integer PRIMARY KEY
   * author text
   * title text
   * query text
   * description text
  Changing the ID changes the shown order and number in the ''Available Reports'' list and the report's perma-link. This is done by running something like:
  {{{
  update report set id=5 where id=3;
  }}}
  Keep in mind that the integrity has to be maintained (i.e., ID has to be unique, and you don't want to exceed the max, since that's managed by SQLite someplace).

  You may also need to update or remove the report number stored in the report or query.

  == Navigating Tickets ==
  Clicking on one of the report 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 Report'' link to return to the report page.

  You can safely edit any of the tickets and continue to navigate through the results using the ''!Next/Previous/Back to Report'' links after saving your results, but when you return to the report, there will be no hint about what has changed, as would happen if you were navigating a list of tickets obtained from a query (see TracQuery#NavigatingTickets). ''(since 0.11)''

  == Alternative Download Formats ==
  Aside from the default HTML view, reports can also be exported in a number of alternative formats.
  At the bottom of the report page, you will find a list of available data formats. Click the desired link to 
  download the alternative report format.

  === Comma-delimited - CSV (Comma Separated Values) ===
  Export the report as plain text, each row on its own line, columns separated by a single comma (',').
  '''Note:''' The output is fully escaped so carriage returns, line feeds, and commas will be preserved in the output.

  === Tab-delimited ===
  Like above, but uses tabs (\t) instead of comma.

  === RSS - XML Content Syndication ===
  All reports support syndication using XML/RSS 2.0. To subscribe to an RSS feed, click the orange 'XML' icon at the bottom of the page. See TracRss for general information on RSS support in Trac.

  ----

  == Creating Custom Reports ==

  ''Creating a custom report requires a comfortable knowledge of SQL.''

  '''Note that you need to set up [TracPermissions#Reports permissions] in order to see the buttons for adding or editing reports.'''

  A report is basically a single named SQL query, executed and presented by
  Trac.  Reports can be viewed and created from a custom SQL expression directly
  in the web interface.

  Typically, a report consists of a SELECT-expression from the 'ticket' table,
  using the available columns and sorting the way you want it.

  == Ticket columns ==
  The ''ticket'' table has the following columns:
   * id
   * type
   * time
   * changetime
   * component
   * severity  
   * priority 
   * owner
   * reporter
   * cc
   * version
   * milestone
   * status
   * resolution
   * summary
   * description
   * keywords

  See TracTickets for a detailed description of the column fields.

  Example: '''All active tickets, sorted by priority and time'''
  {{{
  SELECT id AS ticket, status, severity, priority, owner, 
         time AS created, summary FROM ticket 
    WHERE status IN ('new', 'assigned', 'reopened')
    ORDER BY priority, time
  }}}


  == Advanced Reports: Dynamic Variables ==
  For more flexible reports, Trac supports the use of ''dynamic variables'' in report SQL statements. 
  In short, dynamic variables are ''special'' strings that are replaced by custom data before query execution.

  === Using Variables in a Query ===
  The syntax for dynamic variables is simple, any upper case word beginning with '$' is considered a variable.

  Example:
  {{{
  SELECT id AS ticket,summary FROM ticket WHERE priority=$PRIORITY
  }}}

  To assign a value to $PRIORITY when viewing the report, you must define it as an argument in the report URL, leaving out the leading '$'.

  Example:
  {{{
   http://trac.edgewall.org/reports/14?PRIORITY=high
  }}}

  To use multiple variables, separate them with an '&'.

  Example:
  {{{
   http://trac.edgewall.org/reports/14?PRIORITY=high&SEVERITY=critical
  }}}


  === !Special/Constant Variables ===
  There is one dynamic variable whose value is set automatically (the URL does not have to be changed) to allow practical reports. 

   * $USER — Username of logged in user.

  Example (''List all tickets assigned to me''):
  {{{
  SELECT id AS ticket,summary FROM ticket WHERE owner=$USER
  }}}



  == Advanced Reports: Custom Formatting ==
  Trac is also capable of more advanced reports, including custom layouts,
  result grouping and user-defined CSS styles. To create such reports, we'll use
  specialized SQL statements to control the output of the Trac report engine.

  === Special Columns ===
  To format reports, TracReports looks for 'magic' column names in the query
  result. These 'magic' names are processed and affect the layout and style of the 
  final report.

  === Automatically formatted columns ===
   * '''ticket''' — Ticket ID number. Becomes a hyperlink to that ticket. 
   * '''id''' — same as '''ticket''' above when '''realm''' is not set
   * '''realm''' — together with '''id''', can be used to create links to other resources than tickets (e.g. a realm of ''wiki'' and an ''id'' to a page name will create a link to that wiki page)
   * '''created, modified, date, time''' — Format cell as a date and/or time.
   * '''description''' — Ticket description field, parsed through the wiki engine.

  '''Example:'''
  {{{
  SELECT id AS ticket, created, status, summary FROM ticket 
  }}}

  Those columns can also be defined but marked as hidden, see [#column-syntax below].

  See trac:wiki/CookBook/Configuration/Reports for some example of creating reports for realms other than ''ticket''.

  === Custom formatting columns ===
  Columns whose names begin and end with 2 underscores (Example: '''`__color__`''') are
  assumed to be ''formatting hints'', affecting the appearance of the row.
   
   * '''`__group__`''' — Group results based on values in this column. Each group will have its own header and table.
   * '''`__grouplink__`''' — Make the header of each group a link to the specified URL. The URL is taken from the first row of each group.
   * '''`__color__`''' — Should be a numeric value ranging from 1 to 5 to select a pre-defined row color. Typically used to color rows by issue priority.
  {{{
  #!html
  <div style="margin-left:7.5em">Defaults: 
  <span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #fdc; border-color: #e88; color: #a22">Color 1</span>
  <span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #ffb; border-color: #eea; color: #880">Color 2</span>
  <span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #fbfbfb; border-color: #ddd; color: #444">Color 3</span>
  <span style="border: none; color: #333; background: transparent; font-size: 85%; background: #e7ffff; border-color: #cee; color: #099">Color 4</span>
  <span style="border: none; color: #333; background: transparent;  font-size: 85%; background: #e7eeff; border-color: #cde; color: #469">Color 5</span>
  </div>
  }}}
   * '''`__style__`''' — A custom CSS style expression to use on the `<tr>` element of the current row.
   * '''`__class__`''' — Zero or more space-separated CSS class names to be set on the `<tr>` element of the current row. These classes are added to the class name derived from `__color__` and the odd / even indicator.

  '''Example:''' ''List active tickets, grouped by milestone, group header linked to milestone page, colored by priority''
  {{{
  SELECT p.value AS __color__,
       t.milestone AS __group__,
       '../milestone/' || t.milestone AS __grouplink__,
       (CASE owner WHEN 'daniel' THEN 'font-weight: bold; background: red;' ELSE '' END) AS __style__,
         t.id AS ticket, summary
    FROM ticket t,enum p
    WHERE t.status IN ('new', 'assigned', 'reopened') 
      AND p.name=t.priority AND p.type='priority'
    ORDER BY t.milestone, p.value, t.severity, t.time
  }}}

  '''Note:''' A table join is used to match ''ticket'' priorities with their
  numeric representation from the ''enum'' table.

  === Changing layout of report rows === #column-syntax
  By default, all columns on each row are display on a single row in the HTML
  report, possibly formatted according to the descriptions above. However, it's
  also possible to create multi-line report entries.

   * '''`column_`''' — ''Break row after this''. By appending an underscore ('_') to the column name, the remaining columns will be continued on a second line.

   * '''`_column_`''' — ''Full row''. By adding an underscore ('_') both at the beginning and the end of a column name, the data will be shown on a separate row.

   * '''`_column`''' — ''Hide data''. Prepending an underscore ('_') to a column name instructs Trac to hide the contents from the HTML output. This is useful for information to be visible only if downloaded in other formats (like CSV or RSS/XML).
     This can be used to hide any kind of column, even important ones required for identifying the resource, e.g. `id as _id` will hide the '''Id''' column but the link to the ticket will be present.

  '''Example:''' ''List active tickets, grouped by milestone, colored by priority, with  description and multi-line layout''

  {{{
  SELECT p.value AS __color__,
         t.milestone AS __group__,
         (CASE owner 
            WHEN 'daniel' THEN 'font-weight: bold; background: red;' 
            ELSE '' END) AS __style__,
         t.id AS ticket, summary AS summary_,             -- ## Break line here
         component,version, severity, milestone, status, owner,
         time AS created, changetime AS modified,         -- ## Dates are formatted
         description AS _description_,                    -- ## Uses a full row
         changetime AS _changetime, reporter AS _reporter -- ## Hidden from HTML output
    FROM ticket t,enum p
    WHERE t.status IN ('new', 'assigned', 'reopened') 
      AND p.name=t.priority AND p.type='priority'
    ORDER BY t.milestone, p.value, t.severity, t.time
  }}}

  === Reporting on custom fields ===

  If you have added custom fields to your tickets (a feature since v0.8, see TracTicketsCustomFields), you can write a SQL query to cover them. You'll need to make a join on the ticket_custom table, but this isn't especially easy.

  If you have tickets in the database ''before'' you declare the extra fields in trac.ini, there will be no associated data in the ticket_custom table. To get around this, use SQL's "LEFT OUTER JOIN" clauses. See [trac:TracIniReportCustomFieldSample TracIniReportCustomFieldSample] for some examples.

  === A note about SQL rewriting #rewriting

  Beyond the relatively trivial replacement of dynamic variables, the SQL query is also altered in order to support two features of the reports:
   1. [#sort-order changing the sort order]
   2. pagination support (limitation of the number of result rows displayed on each page)
  In order to support the first feature, the sort column is inserted in the `ORDER BY` clause in the first position or in the second position if a `__group__` column is specified (an `ORDER BY` clause is created if needed). In order to support pagination, a `LIMIT ... OFFSET ...` clause is appended.
  The query might be too complex for the automatic rewrite to work correctly, resulting in an erroneous query. In this case you still have the possibility to control exactly how the rewrite is done by manually inserting the following tokens:
   - `@SORT_COLUMN@`, the place where the name of the selected sort column will be inserted,
   - `@LIMIT_OFFSET@`, the place where the pagination support clause will be added
  Note that if you write them after an SQL comment, `--`, you'll effectively disable rewriting if this is what you want!

  Let's take an example, consider the following SQL query:
  {{{
  -- ## 4: Assigned, Active Tickets by Owner ## --

  -- 
  -- List assigned tickets, group by ticket owner, sorted by priority.
  -- 

  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t,enum p
    WHERE status = 'assigned'
  AND p.name=t.priority AND p.type='priority'
    ORDER BY __group__, p.value, severity, time
  }}}

  The automatic rewrite will be the following (4 rows per page, page 2, sorted by `component`):
  {{{
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t,enum p
    WHERE status = 'assigned'
  AND p.name=t.priority AND p.type='priority'
    ORDER BY __group__ ASC, `component` ASC,  __group__, p.value, severity, time
   LIMIT 4 OFFSET 4
  }}}

  The equivalent SQL query with the rewrite tokens would have been:
  {{{
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, severity, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t,enum p
    WHERE status = 'assigned'
  AND p.name=t.priority AND p.type='priority'
    ORDER BY __group__, @SORT_COLUMN@, p.value, severity, time
  @LIMIT_OFFSET@
  }}}

  If you want to always sort first by priority and only then by the user selected sort column, simply use the following `ORDER BY` clause:
  {{{
    ORDER BY __group__, p.value, @SORT_COLUMN@, severity, time
  }}}

  ----
  See also: TracTickets, TracQuery, TracGuide, [http://www.sqlite.org/lang_expr.html Query Language Understood by SQLite]


name: TracAdmin
author: trac
ipnr: 127.0.0.1
text:
  = TracAdmin =
  [[TracGuideToc]]

  Trac is distributed with a powerful command-line configuration tool. This tool can be used  to configure and customize your Trac-installation to better fit your needs.

  Some of those operations can also be performed via the ''Admin'' web interface, an updated version of the [trac:WebAdmin] plugin now integrated within Trac (since version 0.11).

  == Usage ==

  For nearly every `trac-admin` command, you'll need to specify the path to the TracEnvironment that you want to administer as the first argument, for example:
  {{{
  trac-admin /path/to/projenv wiki list
  }}}

  The only exception is for the `help` command, but even in this case if you omit the environment, you'll only get a very succinct list of commands (`help` and `initenv`), the same list you'd get when invoking `trac-admin` alone.
  Also, `trac-admin --version` will tell you about the Trac version (e.g. 0.12) corresponding to the program.

  If you want to get a comprehensive list of the available commands and sub-commands, you need to specify an existing environment:
  {{{
  trac-admin /path/to/projenv help
  }}}

  Some commands have a more detailed help, which you can access by specifying the command's name as a subcommand for `help`:

  {{{
  trac-admin /path/to/projenv help <command>
  }}}

  === `trac-admin <targetdir> initenv` === #initenv

  This subcommand is very important as it's the one used to create a TracEnvironment in the specified `<targetdir>`. That directory must not exist prior to the call.

  [[TracAdminHelp(initenv)]]

  It supports an extra `--inherit` option, which can be used to specify a global configuration file which can be used share settings between several environments. You can also inherit from a shared configuration afterwards, by setting the `[inherit] file` option in the `conf/trac.ini` file in your newly created environment, but the advantage of specifying the inherited configuration file at environment creation time is that only the options ''not'' already specified in the global configuration file will be written in the created environment's `conf/trac.ini` file.
  See TracIni#GlobalConfiguration.

  Note that in version 0.11 of Trac, `initenv` lost an extra last argument `<templatepath>`, which was used in previous versions to point to the `templates` folder. If you are using the one-liner '`trac-admin /path/to/trac/ initenv <projectname> <db> <repostype> <repospath>`' in the above and getting an error that reads ''''`Wrong number of arguments to initenv: 4`'''', then this is because you're using a `trac-admin` script from an '''older''' version of Trac.

  == Interactive Mode ==

  When passing the environment path as the only argument, `trac-admin` starts in interactive mode.
  Commands can then be executed on the selected environment using the prompt, which offers tab-completion
  (on non-Windows environments, and when the Python `readline` module is available) and automatic repetition of the last command issued.

  Once you're in interactive mode, you can also get help on specific commands or subsets of commands:

  For example, to get an explanation of the `resync` command, run:
  {{{
  > help resync
  }}}

  To get help on all the Wiki-related commands, run:
  {{{
  > help wiki
  }}}

  == Full Command Reference ==

  You'll find below the detailed help for all the commands available by default in `trac-admin`. Note that this may not match the list given by `trac-admin <yourenv> help`, as the commands  pertaining to components disabled in that environment won't be available and conversely some plugins activated in the environment can add their own commands.

  [[TracAdminHelp()]]

  ----
  See also: TracGuide, TracBackup, TracPermissions, TracEnvironment, TracIni, [trac:TracMigrate TracMigrate]


name: TracGuide
author: trac
ipnr: 127.0.0.1
text:
  = The Trac User and Administration Guide =
  [[TracGuideToc]]
  {{{#!span style="font-size:90%"
  //The TracGuide is meant to serve as a starting point for all documentation regarding Trac usage and development. The guide is a free document, a collaborative effort, and a part of the [http://trac.edgewall.org Trac Project] itself.//
  }}}

  == Introduction

  Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management. It strives to help developers write great software while staying out of the way. Trac should impose as little as possible on a team's established development process and policies.

  It provides an interface to Subversion (and other version control systems), an integrated Wiki and convenient reporting facilities.

  Trac allows wiki markup in issue descriptions and commit messages, creating links and seamless references between bugs, tasks, changesets, files and wiki pages. A timeline shows all current and past project events in order, making the acquisition of an overview of the project and tracking progress very easy. The roadmap shows the road ahead, listing the upcoming milestones.
  == User Guide
     * Using the Wiki subsystem
       * TracWiki — How to use the built-in Wiki.
       * WikiFormatting — Reference to the wiki syntax used throughout.
     * Using the Version Control subsystem
       * TracBrowser — Browsing source code with Trac.
       * TracChangeset — Viewing changes to source code.
       * TracRevisionLog — Viewing change history.
     * Using the Ticket subsystem
       * TracTickets — Using the issue tracker.
       * TracRoadmap — The roadmap helps tracking project progress.
       * TracReports — Writing and using reports.
       * TracQuery — Executing custom ticket queries.
       * TracBatchModify - Modifying a batch of tickets in one request.
     * Other modules and general topics
       * TracSearch — Full text search in all content.
       * TracTimeline — The timeline provides a historic perspective on a project.
       * TracRss — RSS content syndication in Trac.
       * TracAccessibility — Accessibility keys support


  == Administrator Guide
     * Installation and upgrade
       * TracInstall — How to install and run Trac.
       * TracUpgrade — How to upgrade existing installations.
       * TracImport — Importing tickets from other bug databases.
       * TracPlugins — Installing and managing Trac extensions.
     * Configuration and customization
       * TracIni — Trac configuration file reference. 
       * TracPermissions — Access control and permissions.
       * TracNavigation — Customize main navigation menus.
       * TracInterfaceCustomization — Customizing the Trac interface.
       * TracLogging — The Trac logging facility.
     * Administering the Version Control subsystem
       * TracRepositoryAdmin — Management of Source Code Repositories.
     * Administering the Ticket subsystem
       * TracTicketsCustomFields — Expanding tickets with customized fields.
       * TracNotification — Email notification.
       * TracWorkflow — Configurable Ticket Workflow.
     * Reference
       * TracEnvironment — All you need to know about Trac environments
       * TracAdmin — Administering a Trac project via the command-line.

  == Support and Other Sources of Information ==

   * [trac:TracFaq Trac FAQ] — A collection of Frequently Asked Questions (on the project website).
   * [trac:TracDev] and [trac:TracDev/ApiDocs API docs] — Trac Developer documentation
   * TracSupport — How to get more information

  If you are looking for a good place to ask a question about Trac, look no further than the [http://trac.edgewall.org/wiki/MailingList MailingList]. It provides a friendly environment to discuss openly among Trac users and developers.


name: TracRss
author: trac
ipnr: 127.0.0.1
text:
  = Using RSS with Trac =
  [[TracGuideToc]]

  Several of the Trac modules support content syndication using the RSS (Really Simple Syndication) XML format.
  Using the RSS subscription feature in Trac, you can easily monitor progress of the project, a set of issues or even changes to a single file.

  Trac supports RSS feeds in:

   * TracTimeline —  Use the RSS feed to '''subscribe to project events'''.[[br]]Monitor overall project progress in your favorite RSS reader.
   * TracTickets, TracReports, and TracQuery — Allows syndication of report and ticket query results.[[br]]Be notified about important and relevant issue tickets.
   * TracBrowser and TracRevisionLog — Syndication of file changes.[[br]]Stay up to date with changes to a specific file or directory.

  == How to access RSS data ==
  Anywhere in Trac where RSS is available, you should find a small orange '''XML''' icon, typically placed at the bottom of the page. Clicking the icon will access the RSS feed for that specific resource.

  '''Note:''' Different modules provide different data in their RSS feeds. Usually, the syndicated information corresponds to the current view. For example, if you click the RSS link on a report page, the feed will be based on that report. It might be explained by thinking of the RSS feeds as an ''alternate view of the data currently displayed''.

  == Links ==
   * ''Specifications:''
     * http://blogs.law.harvard.edu/tech/rss — RSS 2.0 Specification

   * ''Multi-platform RSS readers:''
     * http://www.rssowl.org/ — Open source, Eclipse-based, RSS reader for Linux, Mac and Windows systems that supports https and authenticated feeds.

   * ''Linux/BSD/*n*x systems:''
     * http://liferea.sourceforge.net/ — Open source GTK2 RSS Reader for Linux
     * [http://akregator.sourceforge.net/ Akregator] — Open source KDE RSS Reader (part of KDE-PIM)

   * ''Mac OS X systems:''
     * http://ranchero.com/netnewswire/ — An excellent RSS reader for Mac OS X (has both free and pay versions)
     * http://www.utsire.com/shrook/ — An RSS reader for Max OS X that supports https (even with self signed certificates) and authenticated feeds.
     * http://vienna-rss.sourceforge.net/ — Open source Feed Reader for Mac OS X with smart folders support
     * http://www.mesadynamics.com/Tickershock.html — Non-intrusive "news ticker" style RSS reader for Mac OS X

   * ''Windows systems:''
     * http://www.rssreader.com/ — Free and powerful RSS Reader for Windows
     * http://www.sharpreader.net/ — A free RSS Reader written in .NET for Windows

   * ''Firefox:''
     * http://www.mozilla.org/products/firefox/ — Mozilla Firefox features plenty [https://addons.mozilla.org/en-US/firefox/search/?q=rss&appver=&platform= add-ons] for supporting RSS

  ----
  See also: TracGuide, TracTimeline, TracReports, TracBrowser


name: InterTrac
author: trac
ipnr: 127.0.0.1
text:
  = InterTrac Links  =

  Trac supports a convenient way to refer to resources of other Trac servers, from within the Wiki markup, since version 0.10.

  == Definitions ==

  An InterTrac link can be seen as a scoped TracLinks.
  It is used for referring to a Trac resource 
  (Wiki page, changeset, ticket, ...) located in another
  Trac environment.

  == List of Active InterTrac Prefixes ==

  [[InterTrac]]

  == Link Syntax ==

  Simply use the name of the other Trac environment as a prefix, 
  followed by a colon, ending with the resource located in the other environment.

  {{{
  <target_environment>:<TracLinks>
  }}}

  The other resource is specified using a regular TracLinks, of any flavor.

  That target environment name is either the real name of the 
  environment, or an alias for it. 
  The aliases are defined in `trac.ini` (see below).
  The prefix is case insensitive.

  If the InterTrac link is enclosed in square brackets (like `[th:WikiExtrasPlugin]`), the InterTrac prefix is removed in the displayed link, like a normal link resolver would be (i.e. the above would be displayed as `WikiExtrasPlugin`).

  For convenience, there's also some alternative short-hand form, 
  where one can use an alias as an immediate prefix 
  for the identifier of a ticket, changeset or report:
  (e.g. `#T234`, `[T1508]`, `[trac 1508]`, ...)

  == Examples ==

  It is necessary to setup a configuration for the InterTrac facility.
  This configuration has to be done in the TracIni file, `[intertrac]` section.

  Example configuration:
  {{{
  ...
  [intertrac]
  # -- Example of setting up an alias:
  t = trac

  # -- Link to an external Trac:
  trac.title = Edgewall's Trac for Trac
  trac.url = http://trac.edgewall.org
  }}}

  The `.url` is mandatory and is used for locating the other Trac.
  This can be a relative URL in case that Trac environment is located 
  on the same server.

  The `.title` information will be used for providing an useful tooltip
  when moving the cursor over an InterTrac links.

  Finally, the `.compat` option can be used to activate or disable
  a ''compatibility'' mode:
   * If the targeted Trac is running a version below [trac:milestone:0.10 0.10] 
     ([trac:r3526 r3526] to be precise), then it doesn't know how to dispatch an InterTrac 
     link, and it's up to the local Trac to prepare the correct link. 
     Not all links will work that way, but the most common do. 
     This is called the compatibility mode, and is `true` by default. 
   * If you know that the remote Trac knows how to dispatch InterTrac links, 
     you can explicitly disable this compatibility mode and then ''any'' 
     TracLinks can become an InterTrac link.

  Now, given the above configuration, one could create the following links:
   * to this InterTrac page:
     * `trac:wiki:InterTrac` trac:wiki:InterTrac
     * `t:wiki:InterTrac` t:wiki:InterTrac
     * Keys are case insensitive: `T:wiki:InterTrac` T:wiki:InterTrac
   * to the ticket #234:
     * `trac:ticket:234` trac:ticket:234
     * `trac:#234` trac:#234 
     * `#T234` #T234
   * to the changeset [1912]:
     * `trac:changeset:1912` trac:changeset:1912
     * `[T1912]` [T1912]
   * to the log range [3300:3330]: '''(Note: the following ones need `trac.compat=false`)'''
     * `trac:log:@3300:3330` trac:log:@3300:3330  
     * `[trac 3300:3330]` [trac 3300:3330] 
   * finally, to link to the start page of a remote trac, simply use its prefix followed by ':', inside an explicit link. Example: `[th: Trac Hacks]` (''since 0.11; note that the ''remote'' Trac has to run 0.11 for this to work'')

  The generic form `intertrac_prefix:module:id` is translated
  to the corresponding URL `<remote>/module/id`, shorthand links
  are specific to some modules (e.g. !#T234 is processed by the
  ticket module) and for the rest (`intertrac_prefix:something`),
  we rely on the TracSearch#quickjump facility of the remote Trac.

  ----
  See also: TracLinks, InterWiki


name: TracUnicode
author: trac
ipnr: 127.0.0.1
text:
  = Unicode Support in Trac =
  [[TracGuideToc]]

  Trac stores all text using UTF-8 encoding, including text in tickets and wiki pages. Internal processing of text uses true Unicode representations.

  As such, it supports most (all?) commonly used character encodings.

  If the default encoding in your source code repository is not UTF-8, you can specify it in the [TracIni#trac-section trac.ini], for example:
  {{{
  default_charset = gbk
  }}}

  You also must make sure that your [trac:DatabaseBackend database backend] stores its data in UTF-8; otherwise strange things will happen.

  To convert your database to UTF-8, the easiest way is to dump the database, convert the dump into UTF-8 and then import the converted dump back into the database.[[BR]]
  You can use [http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.1.html iconv] to convert the dump.


  == Examples ==

  === Arabic ===
  تراك يقوم بحفظ كل الكلمات باستخدام صيغة UTF-8، بما في ذلك الكلمات المستخدمة في صفحات  التيكت والويكي.

  === Bulgarian ===
  Българският език работи ли?

  === Česky ===
  Čeština v kódování UTF-8, žádný problém.

  === Chinese ===
  Traditional: 繁體中文, 漢字測試; Simplified: 简体中文，汉字测试

  === Croatian ===
  Ako podržava srpski i slovenski mora podržavati i Hrvatski - čćžšđ ČĆŽŠĐ 

  === English ===
  Yes indeed, Trac supports English. Fully.

  === Français ===
  Il est possible d'écrire en Français : à, ç, û, ...

  === German ===
  Trac-Wiki muß auch deutsche Umlaute richtig anzeigen: ö, ä, ü, Ä, Ö, Ü; und das scharfe ß

  === Greek ===
  Τα Ελληνικά υποστηρίζονται επαρκώς επίσης.

  === Hebrew ===
  אני יכול לאכול זכוכית וזה לא מזיק לי

  === Hindi ===
  अब हिन्दी में।

  === Hungarian ===
  Árvíztűrő tükörfúrógép

  === Icelandic ===
  Ævar sagði við ömmu sína: Sjáðu hvað ég er stór!

  === Japanese ===
  漢字 ひらがな カタカナ ﾊﾝｶｸｶﾅ 日本語試験

  === Korean ===
  이번에는 한글로 써보겠습니다. 잘 보이나요? 한글

  === Latvian ===

  Latviešu valoda arī strādā!

  === Lithuanian ===
  Sudalyvaukime ir mes. Ar veikia lietuviškos raidės? ąčęėįšųūž ĄČĘĖĮŠŲŪŽ Žinoma, kad veikia :)
  Kas tie mes?

  === Persian (Farsi) ===
  این یک متن فارسی است ولی امکان نوشتن مستقیم فارسی نیست چون حالت متن از راست به چپ و جود ندارد برای فارسی نوشتن باید از HTML استفاده کنید.
  {{{
  #!html
  <div dir="rtl">
  }}}
  این نمونه یک متن از راست به چپ فارسی است که در HTML نوشته شده تا اعداد 12345 و حروف لاتین ABCDEF در محل خودشان نمایش داده شوند.
  {{{
  #!html
  </div>
  }}}

  === Polish ===
  Pchnąć w tę łódź jeża lub osiem skrzyń fig; Nocna gżegżółka zawsze dzienną przekuka.

  === Portuguese ===
  É possível guardar caracteres especias da língua portuguesa, incluindo o símbolo da moeda européia '€', trema 'ü', crase 'à', agudos 'áéíóú', circunflexos 'âêô', til 'ãõ', cedilha 'ç', ordinais 'ªº', grau '°¹²³'.

  === Russian ===
  Проверка русского языка: кажется работает... И буква "ё" есть...

  === Serbian ===
  Podržan, uprkos činjenici da se za njegovo pisanje koriste чак два алфабета.

  === Slovenian ===
  Ta suhi škafec pušča vodo že od nekdaj!

  === Spanish ===
  Esto es un pequeño texto en Español, donde el veloz murciélago hindú comía cardlllo y kiwi

  === Swedish ===
  Räven raskar över isen med luva på.

  === Thai ===
  Trac แสดงภาษาไทยได้อย่างถูกต้อง!

  === Ukrainian ===
  Перевірка української мови...

  === Urdu ===
  ٹریک اردو بھی سپورٹ کرتا ہے۔

  === Vietnamese ===
  Viết tiếng Việt cũng được.


name: CamelCase
author: trac
ipnr: 127.0.0.1
text:
  = !CamelCase =
  New words created by smashing together capitalized words.

  CamelCase is the original wiki convention for creating hyperlinks, with the additional requirement that the capitals are followed by a lower-case letter; hence “AlabamA” and “ABc” will not be links.

  == Customizing the Wiki behavior ==

  Some people dislike linking by CamelCase.  While Trac remains faithful to the original Wiki style, it provides a number of ways to accomodate users with different preferences:
   * There's an option (`ignore_missing_pages` in the [wiki:TracIni#wiki-section "[wiki]"] section of TracIni) to simply ignore links to missing pages when the link is written using the CamelCase style, instead of that word being replaced by a gray link followed by a question mark.[[BR]]
     That can be useful when CamelCase style is used to name code artifacts like class names and there's no corresponding page for them.
   * There's an option (`split_page_names` in the  [wiki:TracIni#wiki-section "[wiki]"] section of TracIni) to automatically insert space characters between the words of a CamelCase link when rendering the link.
   * Creation of explicit Wiki links is also easy, see WikiPageNames for details.
   * In addition, Wiki formatting can be disabled completely in some places (e.g. when rendering commit log messages). See `wiki_format_messages` in the [wiki:TracIni#changeset-section "[changeset]"] section of TracIni.

  See TracIni for more information on the available options.

  == More information on !CamelCase ==

   * http://c2.com/cgi/wiki?WikiCase
   * http://en.wikipedia.org/wiki/CamelCase

  ----
  See also: WikiPageNames, WikiNewPage, WikiFormatting, TracWiki


# ticket

type: defect
component: component1
priority: major
owner: sasa
reporter: Sasa Ostrouska <sasa@redos.si>
cc: Roma
version: 1.0
milestone: milestone1
status: new
summary: Testing ticket
keywords: MESSAGE
description:
  Ok this is my first testing ticket. This should describe a defect as I see in the type :)

  == LET ME SEE ==


# session_attribute

sid: 352ac32ae11b7625918fa933
name: query_constraints
value:
  {'status': [u'new', u'assigned', u'reopened'], 'priority': [u'critical'], 'milestone': [u'milestone1']}


sid: 352ac32ae11b7625918fa933
name: query_href
value:
  /trac/query?status=new&status=assigned&status=reopened&priority=critical&milestone=milestone1&order=version&desc=1


sid: 8d7debdf421b05197aa8780c
name: query_constraints
value:
  {'status': [u'new', u'assigned', u'reopened'], 'component': [u'component2'], 'milestone': [u'milestone1']}


sid: 8d7debdf421b05197aa8780c
name: query_href
value:
  /trac/query?status=new&status=assigned&status=reopened&component=component2&milestone=milestone1&order=priority


sid: 2c1526ebb964257898a4a6c2
name: query_constraints
value:
  {'status': [u'new', u'assigned', u'reopened'], 'component': [u'component1'], 'milestone': [u'milestone1']}


sid: 2c1526ebb964257898a4a6c2
name: query_href
value:
  /trac/query?status=new&status=assigned&status=reopened&component=component1&milestone=milestone1&order=priority


sid: 1ef20a0810dcb567c20ec7d4
name: query_href
value:
  /trac/query?status=new&status=assigned&status=reopened&component=component1&order=type&milestone=milestone1


sid: f4518047ff1b6490598d0f76
name: query_href
value:
  /trac/query?status=new&status=assigned&status=reopened&component=component1&order=status&milestone=milestone1


sid: f6d3f4295c06573f0021901b
name: query_href
value:
  /trac/query?status=closed&max=3&col=id&col=resolution&col=summary&col=owner&col=reporter&order=owner


sid: a006a7ed98d24795079df21b
name: query_href
value:
  /trac/query?status=closed&max=3&col=id&col=resolution&col=summary&col=owner&col=reporter&order=resolution


sid: 4e849d7156e4ab968110085e
name: query_href
value:
  /trac/query?status=closed&max=3&col=id&col=resolution&col=summary&col=owner&col=reporter&order=summary


sid: e9447696afe1e91f6279054f
name: query_href
value:
  /trac/query?status=closed&max=3&col=id&col=resolution&col=summary&col=owner&col=reporter&order=reporter


sid: d89fcdd48a81eff1b2660015
name: query_href
value:
  /trac/query?status=assigned&status=new&status=reopened&group=status&order=priority&milestone=milestone1


# ticket_change

author: JonsgA
field: comment
newvalue:
  <A href=" http://jemurl.com/bg2 ">Buy cialis online</A>
  <A href=" http://jemurl.com/72c ">Cheap cialis</A>
  <A href=" http://jemurl.com/mdf ">Cialis discount</A>
  <A href=" http://jemurl.com/7zkbz ">Cialis generic</A>
  <A href=" http://jemurl.com/v74 ">Cialis order</A>
  <A href=" http://jemurl.com/li1zt ">Cialis pack sample</A>
  <A href=" http://jemurl.com/pw ">Cialis pill</A>
  <A href=" http://jemurl.com/25 ">Cialis prescription</A>
  <A href=" http://jemurl.com/74u0c ">Cialis sample</A>
  <A href=" http://jemurl.com/9sf ">Cialis soft tab</A>
  <A href=" http://jemurl.com/l4 ">Buy levitra</A>
  <A href=" http://jemurl.com/fp ">Generic levitra</A>
  <A href=" http://jemurl.com/qusc ">Levitra side effects</A>
  <A href=" http://jemurl.com/6t ">Cheap levitra</A>
  <A href=" http://jemurl.com/qvkgp ">Buy levitra online</A>
  <A href=" http://jemurl.com/91ha1 ">Levitra dosage</A>
  <A href=" http://jemurl.com/qwfs ">Levitra canada</A>
  <A href=" http://jemurl.com/wgko ">Levitra woman</A>
  <A href=" http://jemurl.com/uj7v ">Levitra prescription</A>
  <A href=" http://jemurl.com/t01qx ">Order levitra</A>
  <A href=" http://jemurl.com/cv ">Levitra pill</A>
  <A href=" http://jemurl.com/lz47w ">buy tramadol</A>
  <A href=" http://jemurl.com/zhnxu ">cheap tramadol</A>
  <A href=" http://jemurl.com/jb4i3 ">order tramadol</A>
  <A href=" http://jemurl.com/pzd ">tramadol ultram</A>
  <A href=" http://jemurl.com/1j7 ">hcl tramadol</A>
  <A href=" http://jemurl.com/lq0s ">prescription tramadol</A>
  <A href=" http://jemurl.com/cws ">hydrochloride tramadol</A>
  <A href=" http://jemurl.com/ji8s ">cod tramadol</A>
  <A href=" http://jemurl.com/xrn ">50 mg tramadol</A>
  <A href=" http://jemurl.com/n3 ">drug tramadol</A>
  <A href=" http://jemurl.com/43 ">discount tramadol</A>
  <A href=" http://jemurl.com/9wck ">Buy viagra</A>
  <A href=" http://jemurl.com/1m09 ">Cheap viagra</A>
  <A href=" http://jemurl.com/3qyvf ">Generic viagra</A>
  <A href=" http://jemurl.com/el7 ">Buy viagra online</A>
  <A href=" http://jemurl.com/5tu5y ">Female viagra</A>
  <A href=" http://jemurl.com/81 ">Order viagra</A>
  <A href=" http://jemurl.com/92w ">Viagra alternative</A>
  <A href=" http://jemurl.com/o4 ">Viagra sample</A>
  <A href=" http://jemurl.com/smz ">Viagra cialis levitra</A>
  <A href=" http://jemurl.com/uw3 ">Viagra side effects</A>
  <A href=" http://jemurl.com/e0 ">Viagra pill</A>


author: superza
field: comment
oldvalue: 2
newvalue:
  Struttura molecolare e denominazione chimica del <b>Viagra</b>. Storia della scoperta del <b>Viagra</b>  Sildenafil (<b>Viagra</b>) ed eventi avversi di tipo cardiovascolare 
  <a href=http://viagracialisit.eamped.com/>comprare levitra online</a> 
  <b>Viagra</b>: Leggi su Ciao 19 opinioni su <b>Viagra</b>. Compara i prezzi per Medicinali dalla A  alla Ze approfitta delle incredibili offerte. 
  <a href=http://cialisviagra.forka.eu/index.php>acquisto viagra online</a> i916z


# report

title: Active Tickets
description:
  * List all active tickets by priority.
  * Color each row based on priority.

query:
  SELECT p.value AS __color__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY p.value, milestone, t.type, time


title: Active Tickets by Version
query:
  SELECT p.value AS __color__,
     version AS __group__,
     id AS ticket, summary, component, version, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (version IS NULL),version, p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by version.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: All Tickets by Milestone
query:
  SELECT p.value AS __color__,
     milestone||' Release' AS __group__,
     id AS ticket, summary, component, version, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (milestone IS NULL),milestone, p.value, t.type, time

description:
  This report shows how to color results by priority,
  while grouping results by milestone.

  Last modification time, description and reporter are included as hidden fields
  for useful RSS export.


title: Assigned, Active Tickets by Owner
description: List assigned tickets, group by ticket owner, sorted by priority.
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t,enum p
    WHERE status = 'assigned'
  AND p.name=t.priority AND p.type='priority'
    ORDER BY owner, p.value, t.type, time


title: Assigned, Active Tickets by Owner (Full Description)
query:
  SELECT p.value AS __color__,
     owner AS __group__,
     id AS ticket, summary, component, milestone, t.type AS type, time AS created,
     description AS _description_,
     changetime AS _changetime, reporter AS _reporter
    FROM ticket t, enum p
    WHERE status = 'assigned'
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY owner, p.value, t.type, time

description:
  List tickets assigned, group by ticket owner.
  This report demonstrates the use of full-row display.


title: All Tickets By Milestone (Including closed)
description: A more complex example to show how to make advanced reports.
query:
  SELECT p.value AS __color__,
     t.milestone AS __group__,
     (CASE status 
        WHEN 'closed' THEN 'color: #777; background: #ddd; border-color: #ccc;'
        ELSE 
          (CASE owner WHEN '$USER' THEN 'font-weight: bold' END)
      END) AS __style__,
     id AS ticket, summary, component, status, 
     resolution,version, t.type AS type, priority, owner,
     changetime AS modified,
     time AS _time,reporter AS _reporter
    FROM ticket t,enum p
    WHERE p.name=t.priority AND p.type='priority'
    ORDER BY (milestone IS NULL), milestone DESC, (status = 'closed'), 
          (CASE status WHEN 'closed' THEN modified ELSE (-1)*p.value END) DESC


title: My Tickets
query:
  SELECT p.value AS __color__,
     (CASE status WHEN 'assigned' THEN 'Assigned' ELSE 'Owned' END) AS __group__,
     id AS ticket, summary, component, version, milestone,
     t.type AS type, priority, time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE t.status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority' AND owner = '$USER'
    ORDER BY (status = 'assigned') DESC, p.value, milestone, t.type, time

description:
  This report demonstrates the use of the automatically set 
  $USER dynamic variable, replaced with the username of the
  logged in user when executed.


title: Active Tickets, Mine first
query:
  SELECT p.value AS __color__,
     (CASE owner 
       WHEN '$USER' THEN 'My Tickets' 
       ELSE 'Active Tickets' 
      END) AS __group__,
     id AS ticket, summary, component, version, milestone, t.type AS type, 
     owner, status,
     time AS created,
     changetime AS _changetime, description AS _description,
     reporter AS _reporter
    FROM ticket t, enum p
    WHERE status <> 'closed' 
  AND p.name = t.priority AND p.type = 'priority'
    ORDER BY (owner = '$USER') DESC, p.value, milestone, t.type, time

description:
   * List all active tickets by priority.
   * Show all tickets owned by the logged in user in a group first.


# revision

rev: 0000000010
author: sasa
message:
  Added the build engine configs and other files from the 1.97.15.1 dbs also added the funcions files in SCRIPT's dir


rev: 0000000043
author: sasa
message:
  Added the evolution-exchange-2.6.2-bug344651.diff and evolution-exchange-2.6.2-bug374604.diff to the tree


rev: 0000000079
author: sasa
message:
  Committed new scripts for sabayon, gnome-menus, pessulus, gtksourceview, sound-juicer and modified DLG_PKGER in main config


