dflock/trac-report_2.csv

## trac-report_2.csv

          
            ticket
            summary
            component
            version
            milestone
            type
            severity
            owner
            status
            created
            _changetime
            _description
            _reporter

            
              886
              Add support for Master tickets
              ticket system
              devel
              next-major-releases
              enhancement
              major
              nkantrowitz
              reopened
              2004-11-05T12:44:10+01:00
              2012-11-05T09:34:19+01:00
              It would be cool if you could create master tickets that other tickets refer to. Work could then be broken down into chunks (and assigned to different people), but the master ticket could only be closed when all referring tickets had been resolved.
You could also have it so that referring tickets are excluded from the Roadmap ticket counts.
              dmurphy25@…

            
              10755
              CommitTicketUpdater does not allow user to define what state to jump to
              ticket system
              0.12.3
              unscheduled
              enhancement
              major
              
              new
              2012-07-02T22:27:07+02:00
              2013-04-30T20:15:56+02:00
              The CommitTicketUpdater will only ever close a ticket. In general, the closed state is for when no more work is to be done, aka ''after'' QA has verified the fix. Trac should allow configuration of what state name the ticket will get updated to.
              patrick.little@…

            
              9648
              [PATCH] Improve ticket fields with tooltips
              ticket system
              0.12
              next-dev-1.1.x
              enhancement
              normal
              rblank
              new
              2010-09-27T11:29:42+02:00
              2011-03-20T13:15:31+01:00
              I've created a patch that allows a Trac admin to specify tooltips for arbitrary ticket fields in Trac:
[[Image(tooltip.png)]]
This way the admin can explain a certain field in more detail (for example the difference between priority and severity) or provide information about the syntax used in that field.
The tooltips appear in the following places:
 * the ticket box on the top of an existing ticket page (only on labels, not on values)
 * in the ticket history for changes values
 * the ticket input fields (on labels and input fields)
All labels get a help cursor if a tooltip is available.
Tooltips are specified in the `trac.ini` under the new section `[ticket-hints]`. Just assign the tooltip value to the name of the field. The user may also provide the same tooltip in multiple languages by appending the language code to the field name. Works for built-in fields as well as for custom fields (this patch is a generalization of #899). Example:
{{{
[ticket-hints]
reporter = The reporter of this ticket
owner = The owner of this ticket
blockedby = Tickets preventing this one from closing. Accepts comma delimited ticket number (without #)
complexity = The estimated complexity involved in fixing this ticked.
complexity_de = Die geschätzte Komplexität zur Lösung des Tickets
}}}
I've decided to use the `trac.ini` for localization as it would be too much overhead to create translation files for just some tooltips.

              Sebastian Krysmanski <sebastian@…>

            
              10735
              create a new ticket starting from an existing ticket comment
              ticket system
              0.13dev
              next-dev-1.1.x
              enhancement
              normal
              cboos
              new
              2012-06-23T20:29:01+02:00
              2012-07-14T21:13:06+02:00
              The idea is much the same as the one for TicketClone, but instead of "cloning" the whole ticket in intent (as materialized by copying the ticket's description over), we would refine a specific ticket comment (by taking the ticket's comment as the new ticket description).
This can be handy to avoid derailing a ticket into handling too many things at once, so when something is identified and that clearly needs a dedicated treatment, making a new ticket out of it is just a click away, and you'll have the new ticket starting off with the same fields as the "parent" ticket (yes, the same UI could lead to the creation of subtickets once we have that).
Interestingly, the current source:trunk/tracopt/ticket/clone.py@11079 feature is implemented as an extension using Genshi (`ITemplateStreamFilter`). The present extension achieves a similar result but relies on JavaScript only. For now, only the "create from comment" is done via JavaScript (well, CoffeeScript actually, as this is better suited for embedding little HTML snippets), but the "clone ticket" action itself could be ported to js as well.
This could even be generalized and provide a sound basis for #3255.
=== Related branches
 - repos:cboos.git:clone-from-comment

              cboos

            
              1962
              Due dates on tickets & email notification on overdue dates
              ticket system
              0.8.4
              next-major-releases
              enhancement
              minor
              jonas
              new
              2005-08-25T04:25:51+02:00
              2010-10-02T14:07:29+02:00
              It maye be there already but i cannot find it. One things as a software project manager that drives me crazy about track is the inability to add a due date to tickets. Prioritization is all well and good, and most certainly handy, but as part of the timeline / roadmap and the ticket inspector you REALLY need to have a due date on a ticket. It'd also be fantastic for Trac to notify the allocated user that the ticket is now overdue and bug them on a daily / configurable timeframe. As i said, correct me if this is already in trac (please tell me where!!) but if it's not, this is a really string feature request & i think a definite must have. 
Thanks - trac is awesome & we;'re really starting to use it now :)
Regards
Owen
              owen@…

            
              31
              Bug dependencies/relations feature
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              cboos
              new
              2004-01-29T05:53:39+01:00
              2013-05-07T17:23:09+02:00
              A simple list of related bugs without logical/implicit constraints might be useful. It'd be nice to be able to relate bugs and issues in a useful manner. 
It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat. 
This would also require checking for circular dependencies/relations.

              daniel

            
              918
              [patch] Custom Ticket Fields should support the multiple selection type
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              ecarter
              new
              2004-11-12T19:42:28+01:00
              2012-07-12T10:56:20+02:00
              I propose an addition to the TracTicketsCustomFields.
Currently, there is support for the
simple selection field:
{{{
<field>.type = select
}}}
I would like to have the {{{multi}}} type as well, for multiple selection fields.
The usage in {{{trac.ini}}} for {{{multi}}}
would be the same as it is for {{{select}}}.
I implemented it in a crude way (see the accompanying patch).
I'm not entirely pleased with the patch: 
 * the support for query is partial (i.e. it won't work)
 * the display of the fields is not as neat as I would like
A better solution would involve a change in the database:
drop the unicity constraint on the {{{(id,name)}}} pair for 
the {{{ticket_custom}}} table. 
With that, the query support would be easier to add.

              cboos@…

            
              1084
              Percentage complete
              ticket system
              0.8
              next-major-releases
              enhancement
              normal
              cboos
              new
              2004-12-26T16:53:05+01:00
              2013-05-03T12:19:57+02:00
              Im using Trac in my projet to track bugs, but also to maintaint a list of tasks to do. One thing that would be great is the possibility to have a "percentage complete" field. This way the task can be updated to reflect the percentage complete. Right now the task can only be "0% complete" or "100% complete". I mean a task is either finished or unfinished, which is not always the case.
              cerel

            
              2463
              Mandatory fields in tickets
              ticket system
              0.9.2
              next-major-releases
              enhancement
              normal
              
              new
              2005-12-09T11:18:09+01:00
              2012-02-10T23:02:16+01:00
              It would be great with ability to set some ticket fields as mandatory. These fields should be verified before allowing submit when creating a new ticket.
              johan.regnell@…

            
              3370
              Custom query RSS feed differes from CSV, Tab files
              ticket system
              0.9.4
              unscheduled
              enhancement
              normal
              jonas
              reopened
              2006-07-10T03:41:48+02:00
              2010-12-13T16:37:48+01:00
              The RSS feed for a custom ticket query does not contain same fields as what the CSV and Tab Separated files do. The following important fields appear to be missing from the RSS feed: owner, type, priority, mileston and resolution.

              tomek.piatek@…

            
              11145
              wrap author information for ticket change comments in a span to make them stylable
              ticket system
              
              
              enhancement
              minor
              
              new
              2013-04-05T17:46:46+02:00
              2013-04-05T17:46:46+02:00
              It would be nice to be able to to adjust the style of the author of a ticket change independently of the rest of the change header.  Trac can make this easy to do by wrapping the author's identity in a `<span class="author">` tag.
I think the following change does this without producing any bad side effects:
{{{
diff --git a/trac/web/chrome.py b/trac/web/chrome.py
index 3aed33d..4ec9f7d 100644
--- a/trac/web/chrome.py
+++ b/trac/web/chrome.py
@@ -1058,9 +1058,9 @@ class Chrome(Component):
         return sep.join(all_cc)
 
     def authorinfo(self, req, author, email_map=None):
-        return self.format_author(req,
+        return tag.span(self.format_author(req,
                                   email_map and '@' not in author and
-                                  email_map.get(author) or author)
+                                  email_map.get(author) or author), class="author")
 
     def get_email_map(self):
         """Get the email addresses of all known users."""
}}}
this allows someone who wants the author names to show up (for example) in bold to add the following to their local css file:
{{{
h3.change span.author { font-weight: bold; }
}}}
              dkg@…

            
              10948
              [PATCH] Clone functionality should also be available for users with TICKET_CREATE permission
              ticket system
              1.0
              1.0.2
              enhancement
              normal
              cboos
              assigned
              2012-11-12T09:20:15+01:00
              2013-04-18T08:03:57+02:00
              As described in ticket [ticket:4686#comment:14], it would be nice to enable clone functionality also for "normal" users, which have `TICKET_CREATE` permission. As you could copy / clone a ticket manually with `TICKET_CREATE` permission (by copy-paste) it should be sufficient to check `TICKET_CREATE` permission in `clone.py`.
As described in [ticket:10856#comment:6] it would also make more sense to put the clone-button on top of the properties table, since when you clone a ticket you clone '''all''' properties and not only the description.
              franz.mayer@…

            
              10984
              Hide the milestone select from the ticket form if the user doesn't have MILESTONE_VIEW
              ticket system
              1.0
              1.0.2
              enhancement
              normal
              
              new
              2012-12-15T03:58:28+01:00
              2013-04-12T10:45:54+02:00
              If the user doesn't have `MILESTONE_VIEW` the milestone select is shown with no options. It might as well be hidden and not clutter up the ticket form.
Hiding it also exposes less information because the user without `MILESTONE_VIEW` doesn't know whether there are any milestones defined. After the patch, the behavior is the same whether there are milestones defined but the user doesn't have `MILESTONE_VIEW` or there are no milestones defined. In both cases there are no mentions of milestone on the ticket form.
              Ryan J Ollos <ryan.j.ollos@…>

            
              11100
              tracopt.ticket.deleter Genshi stream transformer may not work with themes
              ticket system
              1.0-stable
              1.0.2
              enhancement
              normal
              
              new
              2013-03-04T06:17:23+01:00
              2013-03-04T09:03:24+01:00
              The XPath expression relies on an `h3` being present, but a theme may want to change this to, for example, an `h5`. Would there be any harm in the following change, since the `id` elements must be unique anyway:
{{{
#!diff
diff --git a/tracopt/ticket/deleter.py b/tracopt/ticket/deleter.py
index 75b93fa..75b1724 100644
--- a/tracopt/ticket/deleter.py
+++ b/tracopt/ticket/deleter.py
@@ -95,7 +95,7 @@ class TicketDeleter(Component):
 
         buffer = StreamBuffer()
         return stream | Transformer('//div[@class="description"]'
-                                    '/h3[@id="comment:description"]') \
+                                    '/*[@id="comment:description"]') \
             .after(delete_ticket).end() \
             .select('//div[starts-with(@class,"change")]/@id') \
             .copy(buffer).end() \
}}}
This would also seem to be more robust against future changes to the Trac ticket template.
              Ryan J Ollos <ryan.j.ollos@…>

            
              1329
              Ticket Search should (optionally) search only non-closed tickets
              ticket system
              0.8.1
              next-dev-1.1.x
              enhancement
              major
              rblank
              new
              2005-03-21T09:19:37+01:00
              2013-02-24T22:40:43+01:00
              One of the popular uses for searching (I believe) is to search the ticket database if an issue has already been filed. It would help if the search would only search tickets that have not been closed. 
This request is similar to Ticket #584 but I would like a way to filter the results so that only open tickets are displayed in the search result. It does not help much if you need to browse loads of resolved tickets to find the one open ticket you are looking for.
''fixed typos''
              Norbert Unterberg <nepo@…>

            
              7979
              New tickets should be able to default owner to the current user
              ticket system
              0.11.2.1
              next-dev-1.1.x
              enhancement
              normal
              cboos
              assigned
              2009-01-17T05:41:12+01:00
              2013-04-25T11:06:06+02:00
              We use Trac very actively to manage our Dev tasks and not just as bug tracking system. We have much more tasks than defects or enhancements and in most of the cases Devs are filing tasks for themselves.
It would be very useful if "default_owner" ticket setting could support value like "$USER" meaning that currently logged-in user is  pre-selected in the owner field on the new ticket form.
              lashchev@…

            
              9510
              Action block stays visible when no actions available
              ticket system
              0.11-stable
              next-dev-1.1.x
              defect
              normal
              
              new
              2010-07-20T12:20:58+02:00
              2012-02-10T23:04:10+01:00
              The action block on the ticket page is visible (empty) even if there are no actions available.
I've implemented a custom workflow for our trac site, removing the "leave" action for users that were having just that option (senseless). In that case though, the action block is still there, empty (senseless and ugly now :)).
              fredck@…

            
              10040
              Support for integer/float custom fields
              ticket system
              
              next-dev-1.1.x
              enhancement
              normal
              
              new
              2011-02-22T12:38:30+01:00
              2011-03-08T17:33:30+01:00
              See http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/6561 for some discussion.
We'd like to be able to mark some custom fields as "contains integer" or "contains floating number". This would then let us sort numerically, validate user input, add an aggregation/summing feature, and so on.
We're not thinking of changing the ''storage'' type, nor, currently, the Python type that exists in the ticket.fields list. Instead, we just validate the user input and then later we can also attempt to convert the field value to the numeric type if we want to do sorting or summing.
This can fix #3080, but walks in the wrong way for FieldRefactoring.

              pipern

            
              10983
              PATCH (and RFC) for IQueryPreprocessor extension point
              ticket system
              0.11.6
              next-dev-1.1.x
              enhancement
              normal
              
              new
              2012-12-13T18:27:55+01:00
              2013-04-17T18:58:54+02:00
              I'm working in 0.11.6 and I don't expect this to be adopted there but I'd like to get feedback on structure, naming, etc. so I can make this patch more acceptable before porting to an active version.
In my PM work, I find it desirable to query tickets based in special ways like asking for all the tickets required by a ticket (and their predecessors, etc.) or all the descendants of a ticket.  My plugin supports this with `goal=id|id|...` and `root=id|id|...` but every place I want this support, I have to modify plugin source to use my preprocessor or query wrapper.  For example, I did this locally for Estimation Tools so I could do a workload chart of all the work in a ticket's predecessors.
By adding an extension point to the core query system, all ticket queries can benefit from the PM logic.  For example, you could do `[[TicketQuery(goal=self)]]` in a ticket to list all the ticket's predecessors.
This patch defines and uses IQueryPreprocessor to accomplish this extensible query system.  Then I implement this interface in my PM plugin:
{{{
#!py
class PMQueryHelper(Component):
    implements(IQueryPreprocessor)
    def __init__(self):
        self.pm = TracPM(self.env)
    # IQueryPreprocessor methods
    # Return the list of constraints handled by process_constraints()
    def custom_constraints(self):
        return ['root', 'goal', 'scheduled']
    # Turn custom constraints (e.g., root) into standard contraints (e.g., id)
    #
    # @param req the Trac web request object, may be None
    # @param constraints hash indexed by contraint name (e.g., 'root',
    #   'id').  Each entry is a list of values.
    #
    # @return updated constraints.
    def process_constraints(self, req, constraints):
        # constraint values are lists, TracPM.preQuery() expects
        # pipe-delimited strings.
        options = {}
        for constraint in self.custom_constraints():
            if constraint in constraints:
                options[constraint] = "|".join(constraints[constraint])
                del constraints[constraint]
        ids = list(self.pm.preQuery(options, req))
        if len(ids):
            if 'id' not in constraints:
                constraints['id'] = []
            for tid in ids:
                if tid not in constraints['id']:
                    constraints['id'].append(tid)
        
        return constraints
}}}
and the above `TicketQuery()` works.
              Chris.Nelson@…

            
              221
              Creating TR for multiple components
              ticket system
              
              next-major-releases
              enhancement
              critical
              cboos
              new
              2004-04-02T02:41:40+02:00
              2013-03-01T11:03:46+01:00
              Its sometimes necessary to fix a bug in both a branch release and the mainline trunk. It would be very useful to have a method by which a ticket can be assigned to multiple releases 
----
Note: see rather #4298 for the association to multiple versions (or milestones). This ticket is focused on the association to multiple '''components''' (cf. comment:10)
              banerjed@…

            
              4298
              tickets linked to multiple versions
              ticket system
              0.10.2
              next-major-releases
              enhancement
              critical
              jonas
              new
              2006-11-30T09:00:23+01:00
              2013-03-01T11:05:00+01:00
              As far as I understand, bug 2945 dealt only with description changes for requirement issues.
I have a different scenario. Say I have a project with versions 1.0, 1.0.1, 1.0.2 and 1.1. a bug is found in 1.0. it is fixed in some way in 1.0.2 and in another way in 1.1
What I'd like to have is the ability to see all open bugs in 1.0 or 1.0.1 (the above bug included), in 1.0.2 (the above bug is fixed, and the comment describing the fix affects 1.0.2) and 1.1 (the bug is fixed in another way)
I think it means only the ability to associate status changes with a version. maybe also priority and severity (in the above scenario, the fix in 1.0.2 may have been partial, not exactly closing the bug for the 1.0.x stream, but lowering the priority)
              ittayd@…

            
              1233
              Descriptions of Components
              ticket system
              0.8
              next-major-releases
              enhancement
              major
              rblank
              new
              2005-02-28T15:52:00+01:00
              2013-05-09T07:39:01+02:00
              One annoying problem we have with our existing bug-tracking system is that users often
don't know what component to select for a ticket. They often end up choosing an inappropriate one.
One could argue that better component names would minimise this, but I've often found users to be
endlessly creative in their quest to misunderstand the (seemingly) obvious ;-)
A nice feature of bugzilla is that the component selector label is a link to a page listing the components for the project, along with owner and description. (If you prefer the link could be a separate item, like a '?' icon.)
(Currently I'm conducting a trial of trac, and I quite like it!)
              Matthew Harrison

            
              2464
              Conditional fields in tickets
              ticket system
              0.9.2
              next-major-releases
              enhancement
              major
              cboos
              new
              2005-12-09T11:34:48+01:00
              2012-11-14T21:31:19+01:00
              Not necessarily all possible fields should be presented to the user. There could be preconditions attached to fields, for checking if they're applicable at all and for checking if the current user can actually set/modify them.
Then, as an advanced case, instead of being an all or nothing situation, the possible content of one field could be dependent on the ticket state: see #1299, #2752 and [#comment:13].
=== Use cases ===
==== Ability to have different ticket fields for different ticket types ====
''(original one)''
When using quite different types of tickets (bug-report, requirement, etc), there is a need for different fields depending on the ticket type. 
This might add just the flexibility required for complying with existing development processes. 
Great feature in particular when support for master and child tickets is planned, trac could be more of a requirements management system beyond the issue database approach.
See also duplicates: #4028, #4643
==== Hide the ''Keywords:'' field ====
See #3281
==== Hide some fields for new tickets ====
See #1580.
This could be achieved quite simply by putting the ticket `id` in the condition.

              johan.regnell@…

            
              3580
              AssignTo Ideas
              ticket system
              devel
              next-major-releases
              enhancement
              major
              
              new
              2006-08-18T16:09:45+02:00
              2011-03-17T00:16:39+01:00
              This is what I was thinking about the ''Assign To'' list.  Please note that this will only work if you have a finite number of users you want to show in the ''Assign To'' list.
 1. The `trac.ini` file will have a new option added.  Maybe something like "`restrict_grouplist`".  This group list will determine what users will be added to the ''Assign To'' list.
 1. In the PERMISSION table, someone has to add the usernames associated to the group(s) that will be used to populate the ''Assign To'' list.
 1. Modify the code accordingly.
Just a thought...
Feel free to comment.
              shawn

            
              8637
              "Add to CC" for anonymous with TICKET_APPEND permissions
              ticket system
              0.11.5
              next-major-releases
              enhancement
              major
              
              new
              2009-09-04T16:25:46+02:00
              2010-12-04T02:33:03+01:00
              Currently when `always_notify_updater` is set to `false` an commenter/updater has to put himself/herself to the CC list of a ticket to be notified about future changes. However, to do so the user is required to have `TICKET_MODIFY` permissions. If an administrator only want the users to be able to comment on tickets (i.e. only grants `TICKET_APPEND` permissions) the user has no way of being notified about future changes.
So it would be nice to activate this checkbox even when the user only has `TICKET_APPEND` permissions.
              Sebastian Krysmanski <sebastian@…>

            
              2045
              shortcut to "accept" a ticket when creating it, and enable the "accept" option for other statuses
              ticket system
              devel
              next-major-releases
              enhancement
              minor
              cboos
              new
              2005-09-11T19:29:32+02:00
              2010-07-20T14:48:23+02:00
              Long time ago, on the mailing list, I proposed a patch 
to immediately set the status of a newly created ticket 
to "assigned" if the reporter and the assignee are the 
same person.
This saves one step, as the next logical step would be 
to "accept" the ticket that the reporter has just created
for himself.
Therefore I propose the patch once again, for discussion:
{{{
#!diff
Index: model.py
===================================================================
--- model.py	(revision 2202)
+++ model.py	(working copy)
@@ -142,6 +142,11 @@
                 # Assume that no such component exists
                 pass
 
+        # If the owner creates the ticket, status is directly 'assigned'
+        owner = self.values.get('owner')
+        if owner and owner == self.values.get('reporter'):
+            self['status'] = 'assigned'
+
         # Insert ticket record
         std_fields = [f['name'] for f in self.fields if not f.get('custom')
                       and f['name'] in self.values.keys()]
}}}
              cboos

            
              3320
              Custom fields can't be hidden
              ticket system
              devel
              next-major-releases
              enhancement
              minor
              athomas
              new
              2006-06-26T16:16:35+02:00
              2008-07-04T17:27:18+02:00
              Though this is already fixed in the new workflow branch, it would be nice to fix this for 0.10. 
All that needs to be done is add to following [source:trunk/trac/ticket/api.py@3444#L161 here]:
{{{
#!python
'skip': config.getbool(name + '.skip', False)
}}}
              coderanger@…

            
              5211
              Ticket - Wiki Integration enhancement/suggestion
              ticket system
              
              next-major-releases
              enhancement
              minor
              cboos
              new
              2007-04-24T17:36:50+02:00
              2010-09-07T17:44:35+02:00
              Supposing that one used CamelCase to name their components, and that one then created wiki pages for their components; how about having the 'Component' column of reports created by the ticket system contain clickable links for each component that has a wiki page created for it.  Also perhaps, in the case that components do not have a page already created; those components might have a link to create the wiki page.
Thanks,
Cullen
              Cullen Newsom <cullennewsom@…>

            
              6249
              Customized field labels for standard fields
              ticket system
              
              next-major-releases
              enhancement
              minor
              jonas
              new
              2007-10-26T14:56:12+02:00
              2007-10-26T15:21:39+02:00
              I'd like to be able to easily modify the labels on standard fields.
              anonymous

            
              9149
              Conf option for showing previous query instead of default query
              ticket system
              0.12dev
              next-major-releases
              enhancement
              minor
              
              new
              2010-03-19T12:38:50+01:00
              2010-06-23T17:53:27+02:00
              Trac stores query_href into session. It would be nice to have option for using that value as a default value.
{{{
[query]
default_query = ${session_query_href}
}}}
              anonymous

            
              9478
              Concurrent ticket modifications is still possible
              ticket system
              0.12
              next-major-releases
              defect
              minor
              
              new
              2010-07-02T14:02:03+02:00
              2010-07-02T17:52:25+02:00
              Before saving a ticket modification, we try to detect if the page was not already modified by another user (r5449). However this check is not done within a single transaction, and therefore it can be ineffective if two changes happen concurrently.
See ticket:9235#comment:10 for an example (or `comments:10` actually ;-) ).
              cboos

            
              10027
              TicketQuery groups without translation
              ticket system
              0.12.2
              next-major-releases
              defect
              minor
              
              new
              2011-02-14T15:49:28+01:00
              2011-02-25T11:11:46+01:00
              I'm using Trac 0.12.2 with German language.
On my WikiStart page I have a TicketQuery with "order=milestone". The group title results in "test milestone Tickets:". Due to my language settings I would expect something like "test Meilenstein Tickets:" as the German word "Meilenstein" is associated with the English "Milestone".
Without having it tested, I assume it's the same e.g. for component ("Komponente") and all these normally translated default fields. (see [source:/tags/trac-0.12.2/trac/ticket/query.py#L1338 here])
              the3illings@…

            
              10207
              Clicking 'Submit' or 'Modify Ticket' from comment edit is blocked by comment preview function
              ticket system
              0.12-stable
              next-major-releases
              defect
              minor
              rblank
              new
              2011-06-03T18:32:54+02:00
              2012-06-17T13:35:46+02:00
              Here is the scenario:
 * I am adding a comment to a ticket by typing in the textarea (Firefox 4.0)
 * I finish typing my comment and am ready to submit, so use the mouse to click the '''Submit changes''' button
 * the wiki-preview of the comment is updated but the ticket is not updated - i.e. I am still in edit mode.
 * I have to click '''Submit changes''' again to update the ticket
It took a few times of this happening before I realized that probably the "lost focus" handler that updates the preview was firing just before the button click, and was therefore preventing the submit from happening.
The other note is that this is not 100% reproducible - sometimes the submit goes through, other times it does not. It seems like only the first time the wiki preview is updated the problem exhibits - after that it works as expected.
{{{
Trac 	0.12
CustomFieldAdmin 	0.2.2
Docutils 	0.6
Genshi 	0.6
mod_python 	3.3.1
pysqlite 	2.3.2
Python 	2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
RPC 	1.1.2-r0
setuptools 	0.6c9
SQLite 	3.3.4
Subversion 	1.6.6 (r40053)
jQuery:	1.4.2
}}}
              txcraig@…

            
              710
              Add basic time tracking
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              
              new
              2004-08-23T12:28:38+02:00
              2012-09-12T08:15:26+02:00
              I would like trac to have basic time reporting as a module.
The (logged in) user should be able to add that he/she worked for X hrs with something and add a short description of what. This time report could refer to a ticket and/or a changeset.
I am not familiar with the internals of trac, but I think that this could just be a new table in the DB and some basic templates/function to add and view data.
              joel@…

            
              2662
              assign tickets to multiple users
              ticket system
              0.9.3
              next-major-releases
              enhancement
              normal
              jonas
              reopened
              2006-01-25T13:36:02+01:00
              2012-10-24T22:52:39+02:00
              It would be very nice, if I could assign a ticket to more than one user. I set the restrict owner-parameter to false and typed in two users. I tried with different syntax, but the trac system did not notice the ticket to belong to the them. Would be fine...
              mala

            
              2961
              custom comment fields
              ticket system
              0.9.4
              next-major-releases
              enhancement
              normal
              jonas
              new
              2006-03-30T21:41:12+02:00
              2012-07-25T22:19:45+02:00
              I'd like a function similar to TracTicketsCustom, but for comments.  
I'm looking to integrate time tracking into Trac to eliminate some double entry, but unlike all the folks at #710, I'd like my "hours spent" field to be on the comment, so we can track who is putting in the time when, and not just have one field on the ticket everyone keeps updating.
              Ryan@…

            
              3281
              make Keywords field optional
              ticket system
              0.9.5
              next-major-releases
              enhancement
              normal
              
              new
              2006-06-17T23:38:46+02:00
              2011-12-27T08:46:16+01:00
              It is very annoying that the Keywords field takes up screen space even if it's not needed. I know that it has been requested by many people, but I'm sure that there are even more people who don't use it, at all. Please make it optional.
Why is it not possible to make the Keywords field one of those [TracTicketsCustomFields]?
              wkornew

            
              3749
              recent ticket-comments macro
              ticket system
              0.9.6
              next-major-releases
              enhancement
              normal
              cboos
              new
              2006-09-18T23:14:26+02:00
              2011-04-22T07:50:05+02:00
              I think it would be nice to have a page that lists recent ticket comments to see what tickets are being actively discussed.
              Gary Wilson <gary.wilson@…>

            
              4130
              Ticket Component Interface Fails to Properly Check for Existing Component
              ticket system
              0.10
              next-major-releases
              defect
              normal
              jonas
              new
              2006-11-11T00:33:08+01:00
              2008-02-11T14:42:35+01:00
              When using the ticket.model.Component class, it will raise a `TracError` if passed the name of a non-existent component on instantiation.
If the component is instantiated with an existing component name, it will assert an error if one tries to call insert().  However, if one instantiates the object with out a name, and then sets the name and owner after the fact, and then calls insert(), no checking of duplicate rows is done.
Possible borkage:
{{{
#!python
c = Component(env)
c.name = 'component1'
c.owner = 'sombody'
c.insert()
}}}
The API should be modified to either raise a TracError in the case in question, and/or provide a method for discovering whether or not a Component exist.
Personally, I think that the following would be desired behavior:
{{{
#!python
c = Component(env, 'new component')
c.insert()
}}}
Where the insert() is a noop if the component already exists.  The `exists` property could also reflect whether or not the Component instance references an existing component or not.
{{{
#!python
c = Component(env, 'new component')
if not c.exists:
  c.insert()
}}}
I find this preferable to:
{{{
#!python
try:
  c = Component(env, 'new component')
except TracError:
  c = Component(env)
  c.name = 'new component'
  c.insert()
}}}

              pacopablo

            
              4266
              Provide a list of users a ticket can be assigned to
              ticket system
              0.10.2
              next-major-releases
              enhancement
              normal
              jonas
              new
              2006-11-27T13:02:19+01:00
              2013-02-07T01:05:00+01:00
              It would be nice if trac could provide the user with a list of people a ticket can be assigned to. What I would like to see is drop-down list with all users (or a list of all peoples tickets have been assigned to in the past) in the Assign to: field when I enter a new ticket.
              dallmeier@…

            
              4549
              [PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals,  ...
              ticket system
              0.10
              next-major-releases
              enhancement
              normal
              jonas
              new
              2007-01-16T14:05:36+01:00
              2010-09-10T11:44:17+02:00
              Hi,
First to say, I find Trac very useful and programmed nicely (appologies for my English). 
Revision 5 is trac 0.10. 
Ticket fields std/custom improvements:
 * field values (combo) filled with sql
 * customized order of fields
 * std fields - customized label/default values
 * values - evaluation of variables
 
TRAC.INI with samples: 
{{{
      std fields
      default_* - default values
      order_*   - order by (not applicable for some fields - e.g. ticket title)
      label_*   - labels
      
      custom fields
      req_who.options   - sql filling the fields
      req_when.value = $(today) - variable evaluation 
      *.order
}}}
I plan to implement following - but the question is when :(  
   * obligatory/optional/hidden field definition in ini
   * init ticket callback - can change field definition (value, type, order ...)
   * save ticket callback - can check/reject/change field values
   * ticket initialization 
   * add to ticket/ticket_change "status by user" (like unread ticket, ticket, ...)
     can be used also as internal mail ... instead of sending the mail mark ticket/ticket_change
     to be read by some users
   * customized home page for the user - will show number of unread tickets 
     newly 
   * ticket "factory" for periodical tickets - e.g. one ticket generated for every month
It would be nice to have customized statuses, so in the future trac could be some kind of workflow 
system (add allowed state-transitions/persons).  
Each status could have extra fields, e.g. if status is "fixed" then field could be revision number.
Hope this will be useful.
Best regards from Croatia,
Robert
              trebor74hr@…

            
              5031
              Queries ought to support less/great than for ordered values (i.e. priorities and severities)
              ticket system
              0.10.2
              next-major-releases
              enhancement
              normal
              
              new
              2007-03-27T10:48:40+02:00
              2009-10-26T11:16:08+01:00
              I.e. expand the [is|is not] operator set a bit.
              macke@…

            
              5425
              Make the state transition dependant on group membership in addition to the boiled down group permissions in workflows
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              jonas
              new
              2007-06-05T10:17:17+02:00
              2010-06-10T21:07:31+02:00
              That would make it possible to only allow users that are members of the 
group user_group to perform the workflow action.
{{{
disapprove = solved -> reopened 
disapprove.name = Disapprove Solution 
disapprove.permissions = user_group  # instead of TICKET_APPEND 
disapprove.operations = del_owner 
}}}

              jim@…

            
              5979
              Add more option to filters with drop-downs in custom query
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              jonas
              new
              2007-09-05T17:08:14+02:00
              2010-01-25T19:45:16+01:00
              Adding a "contains" option to filters with drop-downs in custom query would be really helpful.  The hard part is that it would have to ignore the drop-down and use a text input field.  It is really necessary for people overloading the Component field, due to the fact we don't have component/subcomponent capability.
ie. How do you search for all of component "blob" when your choices are "blob: bit","blob: bot","blob: bat","thingie: subdodad"?

              asloan12@…

            
              5999
              From ticket to wiki : add links to ticket/comment metadata when appropriate
              ticket system
              
              next-major-releases
              enhancement
              normal
              cboos
              new
              2007-09-10T11:24:56+02:00
              2010-06-24T17:54:01+02:00
              In a ticket, we have several metadata that relates to something existing in the Trac system: milestone, component, etc.
It would be helpful to have these fields link to their actual wiki page (or to a template-based url, defined in the configuration file):
 * the milestone field would redirect to the milestone page,
 * the component would redirect to the component view in the milestone page,
Plus, in case these would exist as well in the near future:
 * each keyword could redirect to a search page looking for every item with this keyword,
 * each person (reporter, owner, on cc list, anyone who adds to the ticket) could redirect to a user page summarizing done and pending work in the whole Trac.
While not adding direct context to a ticket, it would make it easier to access data related to it, without a need for a manually typed search or several clicks.
              romain.dalverny@…

            
              6154
              better formatted rss feed
              ticket system
              0.10.4
              next-major-releases
              enhancement
              normal
              jonas
              new
              2007-10-09T01:18:19+02:00
              2010-10-03T22:39:07+02:00
              would be nice to have more contents and details in the rss feed.
The Bucktracker Bugdar has a nice layout for RSS Feeds
see e.g. (with a rss reader)
http://www.bluestatic.org/bugs/syndicate.php
              markus.staab@…

            
              6330
              'Back to query' when no query has been used
              ticket system
              devel
              next-major-releases
              defect
              normal
              jonas
              new
              2007-11-12T12:59:29+01:00
              2010-09-10T17:28:30+02:00
              I'm not sure whether its a feature or a bug:
When a ticket is entered in the search box with the quickjump syntax, the ticket page contains the usual "previous ticket","back to query" and "next ticket" links.
The "back to query" link is quite unexpected, as no query has been used to reach the ticket page, and the default report ({6}) seems to come a bit out of the blue to me.
I would have expected that in this case (no query, direct access to the ticket) the 'Back to query' link not to be shown, and that 'previous ticket' and 'next ticket' links lead to the immediate existing tickets, ''i.e.'' for ticket #''N'', 'previous ticket' jumps to ticket #''N,,-1,,'' and 'next ticket' jumps to ticket #''N,,+1,,'', whatever their status (closed or not)

              eblot

            
              6634
              ITicketManipulator.validate_ticket() return values should be able to include markup
              ticket system
              0.11b1
              next-major-releases
              enhancement
              normal
              
              new
              2008-01-11T08:16:10+01:00
              2012-02-10T22:56:52+01:00
              Since the error messages returned from validate_ticket() by implementations of ITicketManipulator are displayed to the user, it would be good if plugins providing that interface could return some form of markup in the error message.
For example, the error message:
  You can't make that change because you are not part of the security team.
Might be better rendered as:
  You can't make that change because you are not part of [wiki:SecurityTeam the security team]
But i can't find a way to do that in 0.11b1.
asked about this on IRC, coderanger suggested:
   ''"it should probably be fixed to allow Markup() and genshi.builder elements"''
              Daniel Kahn Gillmor <dkg-debian.org@…>

            
              7176
              Workflow actions indistinguishable from user changes
              ticket system
              devel
              next-major-releases
              defect
              normal
              ecarter
              new
              2008-04-30T03:17:34+02:00
              2011-02-01T10:06:47+01:00
               - someone writes a workflow action that modifies a user-modifiable ticket field
 - user selects that action, and previews the change
 - user selects a different action
 - user previews or submits changes
The changes made by the workflow action will still be present; they will not be reverted.
Internally, the code does not differentiate between user changes and workflow changes across a preview.
The correct behavior here, particularly in cases where the user modifies the same fields as the workflow, is open for debate.

              ecarter

            
              7196
              restrict ticket properties to add/edit only/...
              ticket system
              
              next-major-releases
              enhancement
              normal
              cboos
              reopened
              2008-05-05T10:16:39+02:00
              2009-02-24T15:23:23+01:00
              would be nice to have the ability to define if a property should be readonly/disabled/not mentioned at all, if in ticket add-mode/edit-mode...
so e.g. the milestone field could be set to edit-mode, so the creator is not able to choose the value for it... this is the intended behavior  on t.e.o.
also the priorty field should be set by a developer, so maybe also a restriction to some usertypes would be great..
such restriction would also make sense for other fields and also in other scenarios.
this would improve the user-experience and help also the developer team, because of less misfilled tickets
              Markus.Staab

            
              7419
              Custom ticket status: customised ordering of statuses
              ticket system
              0.11-stable
              next-major-releases
              enhancement
              normal
              
              new
              2008-07-09T17:52:49+02:00
              2012-11-23T16:07:44+01:00
              We have a large number of custom ticket statuses now, thanks to 0.11 - it would be nice if I could define a sort order in the config file (similar to how you can do so in a [TracIni#milestone-groups-section "[milestone-groups]"] section) so that when ordering tickets by status, they appear in my defined order.
              trac+jon@…

            
              7438
              Restrict edit permission for ticket description to ticket owner
              ticket system
              0.11-stable
              next-major-releases
              enhancement
              normal
              
              new
              2008-07-16T21:04:08+02:00
              2011-03-30T10:07:09+02:00
              THis is similar to #1316.
It would be very helpful if permissions to edit a ticket's description could be restricted to the owner. This allows the administrator(ahem) to be freed up from changing ticket descriptions all the time, while not giving all users in my developer group the TICKET_EDIT_DESCRIPTION permission.

              john.williams@…

            
              7660
              Be able to search for commenters by name
              ticket system
              0.11.1
              next-major-releases
              enhancement
              normal
              
              new
              2008-09-23T00:57:03+02:00
              2009-10-26T15:35:12+01:00
              Somewhat related/started by http://trac.edgewall.org/ticket/7581
On the Pidgin instance of Trac I would like to be able to search  (via the query module) for tickets that have been commented by myself...so search for text such as:
    "...ago by bernmeister..." 
Or really, just search for "bernmeister".
At the moment there are a lot of Pidgin tickets I've touched and I want to search across all tickets to tell me which ones I've touched that are still NEW (or PENDING or CLOSED or ...).
BTW, Pidgin's Trac instance does NOT have ticket reports enabled. 
What say you (please)?
              anonymous

            
              7850
              [patch] Update default_<enum> options in trac.ini when enum value is updated/deleted
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              
              new
              2008-12-01T18:49:08+01:00
              2009-03-26T21:25:03+01:00
              I had a user complained that he deleted a component, but that the component was still showing up as the default when creating new tickets.
I explained that this is the expected behavior, since the default_component is still set to that component, causing it to be displayed.  But he pointed it that it's somewhat user-hostile to keep a default_component setting for a component that no longer exists, and I'm inclined to agree.
Likewise the default_ setting should be updated when an enum value is updated.
              ebray

            
              7884
              Ticket should contain a field for the expected time to complete/fix it
              ticket system
              none
              next-major-releases
              enhancement
              normal
              
              reopened
              2008-12-12T18:26:14+01:00
              2010-09-10T17:48:30+02:00
              This would give a number of benefits, and among them:
 * a (super)user that has the rights to change the priority of the tickets can rearrange them based on the time to handle them
 * a milestone could show an expected time to be completed as the sum of the time of each ticket
              dusty@…

            
              8403
              Encourage users to select meaningful values for 'required' fields
              ticket system
              none
              next-major-releases
              enhancement
              normal
              
              new
              2009-06-19T23:14:06+02:00
              2009-06-26T15:57:26+02:00
              When an enum field, in particular, is marked as 'required', the blank option is removed from the select element, and the first option is selected by default, if no other default value is set.
The problem with this is that it often leads to users submitting tickets with those fields left in their default values.  It doesn't force them to select a meaningful value.
A decent workaround is to have a catchall (like 'general' for the Component field) as the default value for the field.  But I've had use cases where we want to make sure the user has paid some attention to the field.  The desired behavior here would be to have something like 'Select a Component...' as the first option.  If this option is selected when the form is submitted, a warning would be displayed, and the ticket would not be saved.
              ebray

            
              8670
              Ticket owner list should not depend on TICKET_MODIFY permission
              ticket system
              none
              next-major-releases
              enhancement
              normal
              
              new
              2009-09-15T00:11:24+02:00
              2012-02-10T22:50:27+01:00
              It's nice to be able to use `restrict_owner` in the `[ticket]` section of trac.ini to yield a select box (dropdown) for the "Assign to" field.
But the list contains everyone who has a profile and has TICKET_MODIFY privileges. It would be very, very nice to have a restrict_group option after it, which would allow me to define a group with a given privilege constellation (e.g. developers), and then only have their names appear as candidates.
              fewayne@…

            
              8672
              Filter ticket queries by user groups
              ticket system
              none
              next-major-releases
              enhancement
              normal
              
              new
              2009-09-15T15:20:27+02:00
              2013-04-01T22:53:13+02:00
              We had a need to filter the results of a TicketQuery by user groups (from the permission system) to keep query results from becoming overwhelming. The attached patch does this by expanding a 'username' like '@software' in the owner field of a query to all the users with that role. This is a very rough implementation for now (the group functionality should be provided by the permissions system and there should be a way to list groups on the Custom Query page) but I'm putting it up anyway in the hope that the idea is useful.
We use this like
{{{
[[TicketQuery(status=blocked,order=owner,owner=@software)]]
}}}

              joshua.hoke@…

            
              8778
              Permission that uniquely controls assignment of tickets to milestones
              ticket system
              0.11.5
              next-major-releases
              enhancement
              normal
              
              new
              2009-10-26T19:38:45+01:00
              2012-07-05T23:02:52+02:00
              I have found that the `MILESTONE_VIEW` permission allows a user to change the milestone with which a ticket is associated.  That is, it causes the milestone drop-down list to be populated with the milestones and allows the user to change which milestone a ticket is associated with.
It seems incorrect for a `*VIEW` permission to grant a '''change''' action. Also, it seems desirable to allow a user to view milestones, but not change the milestone assignment for a particular ticket. In my situation, the configuration control board (lead software developers) are in charge of assigning tickets to milestones, and it would be better if all users with `MILESTONE_VIEW` permissions did not have this level of control.
Therefore, it would be nice to have a separate permissions to control the assignment of tickets to milestones.  This permission should be named either `TICKET_ASSIGN_MILESTONE` or `MILESTONE_ASSIGN_TICKET`.  I suspect the former is a better fit for the permissions naming schema (See: TracDev/Proposals/EvenFinerGrainedPermissions).
Note, this permission should be different than the `MILESTONE_MODIFY`, which controls modifying the description, due date, and other milestone data.

              ryano@…

            
              8966
              reporter_restrict option
              ticket system
              
              next-major-releases
              enhancement
              normal
              
              new
              2010-01-13T18:37:06+01:00
              2010-06-26T13:37:42+02:00
              As for the owner (when owner_restrict = true), it would be nice to be able to select the value of the 'reporter' field from a dropdown list.
This option should come along with a permission setting allowing only a given set of users to report tickets on 'behalf' of other users.
Along the dropdown list, the free input field should remain (useful for anonymous/unregistered users).
Multiple reporters might be allowed, however this would be redundant with Cc.
 
Literature:
Existing dropdown list for 'Owner': TracTickets#Assign-toasDrop-DownList
Proposed fullname list (in addition to usernames): #3807
Proposed multiple owner feature: #918

              vincentb1981@…

            
              9550
              Ticket should be divisible
              ticket system
              
              next-major-releases
              enhancement
              normal
              cboos
              new
              2010-08-06T04:51:22+02:00
              2013-01-13T15:27:39+01:00
              Sometimes tickets are entered into the ticket system that contain more than one issue. These tickets should be diversible. When something like this happens I create new tickets with the parts and assign them to their owners. The all new ticket ids are put into the 'parent'.
It would be nice if trac could help with this task and manage a parent/child relationship between tickets. When childs of a ticket are created the parent ticket should be set on hold until all children are resolved. The parent could show a progress bar or something. Notifications for children should be send to their subscribers and the subscribers of the parent ticket.
              stephan@…

            
              9735
              TicketQuery adds reporter by default
              ticket system
              0.12dev
              next-major-releases
              defect
              normal
              
              new
              2010-10-31T02:01:36+01:00
              2011-10-29T18:28:35+02:00
              `TicketQuery` macro adds reporter row by default if using `rows` option. It seems this is [source:trunk/trac/ticket/query.py#L430 hard-coded]. It would be great to be able to disable this feature for those who wants more concise output.
              Mitar

            
              9738
              Add "attach file" button at the end of the ticket
              ticket system
              0.12dev
              next-major-releases
              enhancement
              normal
              
              new
              2010-10-31T21:39:09+01:00
              2012-03-29T10:37:11+02:00
              Add "attach file" button at the end of the ticket as some (novice) users have problems finding a way to attach a file. They are used from wiki that button is at the bottom and in ticket also a change ticket form is at the bottom. So it is not really reasonable to imagine that there is one button up there (if you missed it). Even the anchor link to attachments does not help much. So I believe it would be useful to simply add "attach file" at the bottom, too.
              Mitar

            
              9799
              Hardcoded special status values "new" and "closed" cannot be localized in Workflow
              ticket system
              0.12.1
              next-major-releases
              enhancement
              normal
              
              new
              2010-11-09T14:26:17+01:00
              2010-12-29T00:04:11+01:00
              Custom workflows are problematic for localization. It's possible to be creative with section [ticket-workflow] in trac.ini. For example, (in Finnish)
{{{
[ticket-workflow]
accept = new,uusi,aloitettu,suljettu -> aloitettu
accept.name = Ota lippu vastaan ja ota toteuttaminen vastuullesi
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
confirm = new -> uusi
confirm.default = 2
confirm.name = Vahvista lippu (merkitään uudeksi)
confirm.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.name = Ei muutosta
leave.operations = leave_status
reassign = uusi,aloitettu -> aloitettu
reassign.name = Vaihda tekijä
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = suljettu -> uusi
reopen.name = Avaa uudelleen (ei olekaan vielä valmis)
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,uusi,aloitettu -> suljettu
resolve.name = Merkitse suljetuksi
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY
close = suljettu -> closed
close.name = Vahvista suljetuksi
close.permissions = TICKET_MODIFY
}}}
In the above configuration "uusi" means "new","aloitettu" means "work started","suljettu" means "closed" in Finnish. The .name labels have been set to make sense in Actions form. Logically "uusi" is interpreted as "accepted new","suljettu" is interpreted as "closed" (but not to trac) and "closed" is interpreted as "verified closed" (and closed to trac). This is far from optimal, but the best I've come up with when using Trac 0.12.1.
However, this does not allow changing displayed labels for status "new" or "closed". These values are leaked to end user through various locations. If I've understood correctly, these are hardcoded in the source and as such, cannot be specified in the configuration.
As I see it, there're two possible solutions:
1. Add special code to correctly localize "new" and "closed" status in every place a status is displayed, or
2. Add two configuration parameters to define custom status values to replace "new" and "closed" status values.
I personally would prefer 1 if #9472 is ever fixed to allow translating the workflow in whole (so that a single environment can display possible actions in any language the current user happens to use as opposed to using the single language coded in the trac.ini as in the example above).
However, if the official method for translating the workflow (in the future) is to use custom status values with custom .name strings (as in the example above), then I prefer option 2 above because in that case all localization string related to custom workflow would be in a single file.
If solution 2 above is used, I'd suggest two additional parameters to [ticket] section (notice that these cannot be added to [ticket-workflow] because any name in that section can be taken by custom workflow action):
{{{default_status}}} (defaults to currently hardcoded "new"):
Value of this parameter is used as status for all newly created tickets.
{{{override_status_closed}}} (defaults to currently hardcoded "closed"):
If the status of any ticket is set to this value, that ticket should be considered
as closed for any code where the distinction between open and closed tickets do matter.
I'm marking this as component "ticket system" in case option 2 above is implemented (which I believe is easier to implement). In case option 1 above is considered better, the correct component should be i18n.
See also: #9472.

              Mikko Rantalainen <mikko.rantalainen@…>

            
              9807
              Wrong sections are collapsed by default!
              ticket system
              
              next-major-releases
              enhancement
              normal
              
              new
              2010-11-10T01:38:35+01:00
              2012-09-29T12:41:07+02:00
              Collapsing the sections in a ticke is great - the trouble is that the section that is used 99% of the time is the "modify" section which is pre-collapsed.
An ideal solution would be to make this system configurable (or even user configurable).
It is going to pee-off my users to now have to press that extra button... petty I know.... but its the truth.
              morgand

            
              10125
              CommitTicketUpdater should call manipulators and listeners
              ticket system
              0.12-stable
              next-major-releases
              enhancement
              normal
              rblank
              new
              2011-04-10T21:35:04+02:00
              2012-06-17T13:28:54+02:00
              I don't use this hook myself, but I frequently get questions about it on IRC and try to help out. One very frequent request is some or handling for additional fields or related plugins that need to act on what gets updated on the ticket.
Example can be also adjusting estimates or time spent on fixing bugs, or updating some other related fields and structures.
Anyway, I quickly scanned the source and see that we don't call ticket system manipulators or listeners? That would provide the hooks to either change fields directly together with commit-update, or be handle updating of related information after-the-fact via listener.
Any reason not to call manipulators and listeners?
              osimons

            
              10209
              Allow to deprecate components
              ticket system
              0.13dev
              next-major-releases
              enhancement
              normal
              
              new
              2011-06-05T14:47:24+02:00
              2011-06-17T23:57:23+02:00
              For JOSM we manage the core and also plugins in the same trac instance. Sometimes plugins are integrated into core and thus the components for these are no longer relevant. But there is no possibility to deprecate components.
Deleting the components totally results in problems with searching.
What I would like to see is a method to mark a component as deprecated:
 * It is no longer contained in the choice boxes of tickets
 * When the component is already assigned, it remains until changed.
              dstoecker

            
              10325
              Way to delete ticket comments versions
              ticket system
              0.12.2
              next-major-releases
              enhancement
              normal
              
              new
              2011-08-20T23:03:11+02:00
              2011-08-20T23:58:49+02:00
              In a similar way that it is possible to delete just wiki page versions, it would be great to be able to delete also ticket comments versions. Currently it is possible only to delete the comment as a whole, with all versions.
Similar maybe also for summary versions?
              Mitar

            
              10381
              Use full width for custom textarea fields, and make them collapsible
              ticket system
              0.12.2
              next-major-releases
              enhancement
              normal
              
              new
              2011-09-29T11:14:09+02:00
              2012-09-10T15:23:16+02:00
              The content of custom textareas might get very big, so it would be better to place these fields in full width after description field.
Furthermore it would be nice, if these fields are collapsable, so you could close them, if you do not need them at the moment.
              anonymous

            
              10396
              [PATCH] New extension point interface to reformat the "replying to" block in a comment
              ticket system
              0.12-stable
              next-major-releases
              enhancement
              normal
              
              new
              2011-10-05T12:13:27+02:00
              2012-07-11T07:56:03+02:00
              Sometimes you don't want the original text in a response on a ticket in the "Replying to" line. Instead some sort of
custom formatting (e.g. abbreviation, reference no.) could be used preferably.
Solution:
A new extension point ITicketCommentFormatter defined in ticket/api.py.
The function quote_original() in ticket/web_ui.py calls the plugins, that implement the new extension point.
So it is possible to reformat the "replying to" block in a comment, to leave it unchanged or to drop it at all.

              juliak <kavalerchik@…>

            
              9549
              TicketQueryMacro and TracQueryLanguage documentation seems outdated
              ticket system
              0.12dev
              next-minor-0.12.x
              defect
              normal
              
              new
              2010-08-05T21:48:04+02:00
              2010-09-23T15:44:19+02:00
              
Available documentation on the TicketQueryMacro is missing the '''col''' parameter which takes a "'''|'''" separated list of columns that will be diplayed.
In addition, the documentation on the TracQueryLanguage states that in order to match multiple values one will have to separated them using a semicolon. This is not true for the TicketQueryMacro, here you have to separate individual values using "'''|'''".

              Carsten Klein <carsten.klein@…>

            
              10232
              Validating Ticket accounts for new or removed fields?
              ticket system
              0.11.5
              next-minor-0.12.x
              defect
              normal
              
              new
              2011-06-23T16:33:44+02:00
              2011-06-23T20:34:04+02:00
              On IRC today there appeared an issue that brought back memories of #4447 and #9663.
A user has permission to reopen a ticket, and when doing so the preview looks like this:
{{{
#!div style="background:#EEE"
 * '''status''' changed from ''closed'' to ''reopened''
 * '''resolution''' ''answered'' deleted
}}}
Just like it should. And `trac.ticket.web_ui.TicketModule._validate_ticket()` accounts for the fact that workflow may change these two fields. Problem is that the user sees an error:
{{{
#!div style="background:#FFFFBB"
'''Warning:''' No permission to change ticket fields.
}}}
The user claims that this happens all the time, and the real question is why `changes` isn't empty after this in initial validation method:
{{{
#!python
changed = set(ticket._old) - set(['status', 'resolution'])
}}}
I suspect this is due to fields being added or removed in the system in the time since the ticket was previously edited. They are changes that will need to be recorded, but when they don't arise from user input it seems wrong to let it be a user problem.
The problem is real, but my hypothesis is not completely researched yet... But, it feels like it makes sense... :-)

              osimons

            
              10465
              Counting of Ticket-Comments defect
              ticket system
              0.12.1
              next-minor-0.12.x
              defect
              normal
              rblank
              new
              2011-11-15T16:50:37+01:00
              2011-11-16T01:08:43+01:00
              Hello,
in our trac installation I see the error that the ticket comment after comment 79 gets again the number 3. All comments after that comment are increased from 3.
OS is CentOS 6.
Regards,
Erwin Schliske
              schliske@…

            
              10838
              TicketQuery progress display link ignores order= keys in milestone_groups query_args causing query error
              ticket system
              1.0
              next-stable-1.0.x
              defect
              minor
              psuter
              assigned
              2012-09-09T11:36:07+02:00
              2013-02-15T21:45:54+01:00
              Using the macro invocation
{{{
[[TicketQuery(owner=ian, format=progress)]]
}}}
in a wiki page creates a progress bar with links for various classes of ticket. 
The resulting progress bar creates query URLs that work for all classes of ticket except for closed tickets. For closed tickets it produces a link that looks like:
{{{
/trac/msl/query?owner=ian&status=closed&group=resolution&order=time&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=severity&col=time&col=changetime&max=0&order=id
}}}
This URL includes two order= keys: order=time near the begining and order=id at the end. 
This confuses Trac and results in a runtime error.
All other classes of ticket, such as accepted tickets produce a link that looks like:
{{{
/trac/msl/query?owner=ian&status=accepted&max=0&order=id
}}}
with a single order=id statement.
The source of this error is that our milestone groups includes an order=time key. 
We got this by direct copying from the sample at [http://trac.edgewall.org/wiki/TracIni#milestone-groups-section TracIni] without much thought about what it meant.
{{{
[milestone-groups]
...
# optional extra param for the query (two additional columns: created and modified and sort on created)
closed.query_args = group=resolution,order=time,col=id,col=summary,col=owner,col=type,col=priority,col=component,col=severity,col=time,col=changetime
...
}}}
=== Error message ===
{{{
Trac detected an internal error:
TypeError: unhashable type: 'list'
}}}
=== Python traceback ===
{{{
Most recent call last: 
File "build/bdist.win32/egg/trac/web/main.py", line 497, in _dispatch_request
  dispatcher.dispatch(req)
File "build/bdist.win32/egg/trac/web/main.py", line 214, in dispatch
  resp = chosen_handler.process_request(req)
File "build/bdist.win32/egg/trac/ticket/query.py", line 939, in process_request
  max)
File "build/bdist.win32/egg/trac/ticket/query.py", line 77, in __init__
  self.order = synonyms.get(order, order)     # 0.11 compatibility
}}}
=== System information ===
User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
|| Trac || 1.0 ||
|| Docutils || 0.8.1 ||
|| Genshi || 0.6 (without speedups) ||
|| mod_python || 3.3.1 ||
|| Pygments || 1.4 ||
|| pysqlite || 2.4.1 ||
|| Python || 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] ||
|| setuptools || 0.6c11 ||
|| SQLite || 3.5.9 ||
|| Subversion || 1.7.1 (r1186859) ||
|| jQuery || 1.7.2 ||

              ilewismsl

            
              10772
              Set default component to empty string
              ticket system
              0.11.5
              next-stable-1.0.x
              task
              normal
              
              new
              2012-07-18T12:24:31+02:00
              2012-07-18T12:34:11+02:00
              I am trying to set the default component to an empty string. but when ever I set the default value = to an empty value it will be set to the first on the list of components.
              asaf.levy@…

            
              10962
              Show due date of milestone in ticket
              ticket system
              1.0
              next-stable-1.0.x
              enhancement
              normal
              
              new
              2012-11-22T11:23:03+01:00
              2013-01-23T15:13:42+01:00
              In ticket view is a link to the assigned milestone. When you want to know what due date has that milestone, you have to click on the milestone link.
It would be nice to have that information already in the ticket view. There might be two ways to achieve this:
a. by tooltip
a. by adding it after milestone name
              franz.mayer@…

            
              11125
              Truncate very long text in the ticket properties dialog
              ticket system
              
              next-stable-1.0.x
              enhancement
              normal
              
              new
              2013-03-19T23:17:09+01:00
              2013-03-20T18:27:38+01:00
              Use a bit of CSS to prevent this from happening. It's a bit of a corner case because the text would have to be quite long, but will be easy to fix.
[[Image(Overspill.png,100%)]]
              Ryan J Ollos <ryan.j.ollos@…>

            
              6723
              Trac tickets send out on email as task on Mail Clients
              ticket system
              devel
              not applicable
              enhancement
              normal
              jonas
              new
              2008-01-28T15:21:07+01:00
              2010-12-07T20:18:21+01:00
              Most of the email clients (Outlook, GroupWise, Notes, Kontact) can handle task lists. Tasks can also be emailed to another person. It would be very usefull if Trac could email tasks out as a task that can be accepted in the normal email client with a lin to the Trac task.
              bill.meyer@…

            
              11085
              Submitting ticket changes breaks window.history on Chrome
              ticket system
              
              not applicable
              defect
              normal
              
              new
              2013-02-27T17:24:52+01:00
              2013-03-11T10:44:58+01:00
              To reproduce, using Chrome Version 25.0.1364.99 (Mac)
 1. Go to `/newticket` and file a new ticket 
 1. The page will reload at `/ticket/N#ticket`
 1. Click "Modify Ticket"
 1. The page does not reload.  The URL bar now reads `/ticket/N#no4`
 1. Click "Resolve as fixed" and click "Submit changes"
 1. The page reloads.  The URL bar now reads `/ticket/N#comment:1`
 1. Click the browser's Back button
 1. The page does not reload.  The URL bar now reads `/ticket/N#no4`
 1. Click the browser's Back button again.
 1. (This is the point at which it becomes a bug.)  The page does not reload.  The URL bar now reads `/ticket/N#comment:1`
You are now stuck in a loop -- no matter how many times you click the browser's Back button, the page will never reload, and the URL bar will just cycle its fragment between `#no4` and `#comment:1`.  To escape the loop you need to use the browser's History menu, or something like `javascript:window.history.go(-2)`, or (the option that's become my habit) actually follow another link from the Trac UI or just type in a different URL in the browser.
This bug does '''not''' occur with Firefox 18.0.2 for Mac.  I haven't tested on other browsers/OSes/devices.
              ethan.jucovy@…

            
              9624
              Project-specific ticket prefixes and numbering
              ticket system
              0.12
              topic-multiproject
              enhancement
              normal
              
              new
              2010-09-16T21:12:36+02:00
              2011-02-10T00:45:59+01:00
              With the addition of multiple projects in one Trac instance, it could be helpful to assign ticket identifiers with project-specific prefixes and independent numbering.  The prefix would be configured wherever the project is configured. (trac.ini?)  This would help differentiate tickets when referring to them by identifier.  This is how JIRA assigns ticket identifiers.
For example, in a Trac with two project named Database (DATA) and Web Service (WS), the ticket references would look like:
* DATA-102
* WS-93
With the next Database ticket being assigned DATA-103 and the next Web Service ticket being assigned WS-94.  Since changing the way tickets are identified would probably be a huge change, maybe assigned ticket aliases would be a simpler workaround to provide the same functionality?  I'm not sure what the best way to use these identifiers as wiki links would be, but the idea is that something like the following could be used to create wiki links:
* WS-93
* !ticket:WS-93
* #WS-93
* WS:93   (this might be easiest since you can treat each project prefix as a TracLinks namespace?)
Of course, if the identifier is implemented as an alias then it could get confusing with the underlying numeric identifiers.  WS:93 and !#342 could point to the same ticket.  This also raises the question of what happens if a ticket is moved between projects.  I don't have an understanding of the amount of work involved for this type of change, so this is just a suggestion for consideration.  I do think it would be very useful for scenarios with 10+ projects sharing a ticket database.

              nslowes@…

            
              10271
              set_owner not considering extra permissions
              ticket system
              0.12dev
              undecided
              defect
              major
              
              new
              2011-07-17T13:56:06+02:00
              2013-03-11T10:03:11+01:00
              We created a custom Workflow according to [http://trac.edgewall.org/wiki/TracWorkflow Workflow documentation] and assigned dedicated permissions using the optional [http://trac.edgewall.org/wiki/ExtraPermissionsProvider tracopt.perm.config_perm_provider.ExtraPermissionsProvider] which works fine in principle. The issue reported here is the fact that using .set_owner operation does not consider those users having assigned permissions via [http://trac.edgewall.org/wiki/ExtraPermissionsProvider tracopt.perm.config_perm_provider.ExtraPermissionsProvider] but only those having MODIFY_TICKET.
OS: CentOS 5.5
Python: 2.4

              Ruedi <ruedi.silvestri@…>

            
              10681
              commit_updater.py create wrong comment number
              ticket system
              0.12.2
              undecided
              defect
              normal
              
              new
              2012-04-27T12:47:43+02:00
              2013-03-11T10:03:11+01:00
              
 How to reproduce[[BR]]
 1. create new ticket A,B
 2. add a comment in ticket B
 3. commit message like below TWICE in hg
{{{
refs #B
refs #A
test commit updater
}}}
 Expect result[[BR]]
 Ticket A will have comment 1,2[[BR]]
 Ticket B will have comment 1,2,3
 In fact we get[[BR]]
 Ticket A has comment 1,2[[BR]]
 Ticket B has comment number 1,2,2

              haterw@…

            
              10833
              ConfigurableTicketWorkflow's "Reassign To" ignores fine-grained permissions with restrict_owner=True
              ticket system
              
              undecided
              defect
              normal
              
              new
              2012-09-07T16:16:28+02:00
              2013-03-11T10:03:11+01:00
              When `[ticket] restrict_owner = True`, the default ticket workflow implementation renders a dropdown box for actions that perform a `set_owner` operation.
If the set of possible owners is not specified in the workflow configuration, it is populated with a call to `PermissionSystem(env).get_users_with_permission('TICKET_MODIFY')`, just like the similar dropdowns that are rendered by `TicketSystem.eventually_restrict_owner` on the new ticket form and query builder.
However, after fetching the list of all known users with TICKET_MODIFY, the workflow does not check whether those users have the TICKET_MODIFY permission for the current ticket.  If the system is configured to use a fine-grained permission policy like browser:trunk/sample-plugins/permissions/vulnerability_tickets.py, where the global TICKET_MODIFY permission does not guarantee TICKET_MODIFY for any given ticket, this could result in strange states where the ticket's owner does not have permission to close, modify or reassign the ticket.
I'm not sure whether this actually is a bug that should be fixed.  For one thing, as long as the users who have permission to reassign a ticket are trusted to know what they're doing, it's not really a problem.  It's also not necessarily Trac's job to ensure that the owner field is restricted to "sensible" choices, and anyway there are plenty of other ways that the system could end up in a similar state with certain combinations of configuration.
              Ethan Jucovy <ethan.jucovy@…>

            
              10843
              Make all textarea fields foldable
              ticket system
              1.0
              undecided
              enhancement
              normal
              
              new
              2012-09-10T12:16:34+02:00
              2013-03-11T10:03:11+01:00
              Make all textarea fields, such as `Description` and custom textarea fields foldable / expandable.
              framay <franz.mayer@…>

            
              2908
              No 'register' link (only Login), 'New Ticket' -> 'login' difficult
              ticket system
              0.12dev
              unscheduled
              defect
              major
              
              new
              2006-03-20T20:12:24+01:00
              2010-06-28T22:30:16+02:00
              I'm really irritated that most trac sites (including this one) doesn't offer a registration link (only Login).
This leads to some frustrating situations:
I come along, want to report a bug. Trac tells me, I need "CREATE_TICKET" permissions. Why do you show "New Ticket" if I can't??
Now, I try to find a way to register. But there isn't.
Next, i try to find some other way to post my bug report but there isn't.
I give up.
I suggest that you disable the links to the ticket system when anonymous posting is disabled plus put a big warning next to the option for the site admin.
              digulla@…

            
              6820
              change display for duplicate tickets
              ticket system
              
              unscheduled
              enhancement
              minor
              jonas
              new
              2008-02-12T23:54:26+01:00
              2010-11-17T09:16:59+01:00
              When a ticket is marked as a duplicate the ticket link is displayed with a strike-through character in a wiki page or a search. This is confusing, since it indicates to the reader, that the issue is solved, which must not be the case. The ticket is  simply marked as closed, but the request is still open.
Is it possible to use e.g. a double strike through character?
A much better solution would be the build in support for specifying the duplicate ticket, as suggested in #1395. Then the display could change depending on the status of the referenced duplicate ticket. 
              trac@…

            
              8504
              Named Custom Queries
              ticket system
              0.11.5
              unscheduled
              enhancement
              minor
              
              new
              2009-07-23T08:42:23+02:00
              2010-07-03T23:56:19+02:00
              When running a custom query, customizing it further by adding filters, grouping, etc - the query is still a "Custom Query".
What I'd like is to have "named" or "saved" queries. Just saving a query is easy, you just add a link to a wiki page. But the headline still says "Custom Query" rather some real, readable, title.

              noamtm@…

            
              8736
              Boundary of background does not encompass intended fields.
              ticket system
              none
              unscheduled
              defect
              minor
              
              new
              2009-10-13T13:57:16+02:00
              2010-09-10T14:47:51+02:00
              Fields like the summary or component field are not encompassed by the white background.  See attached image.
              Miruba

            
              10532
              Show diff when summary changes (instead of <old value> to <new value>)
              ticket system
              0.13dev
              unscheduled
              enhancement
              minor
              
              new
              2012-01-19T09:47:24+01:00
              2012-01-19T18:29:56+01:00
              In this [http://trac.edgewall.org/ticket/8135#comment:11 summary change] you do not see any changes at once - and I guess there is not a change at all (which might be a defect).
It would be better readable if summary changes would be displayed in a diff view instead of "<old value> to <new value>" manner, since most summary changes are typos or small changes.
If it is a bigger change (maybe using some smart algorithm to determine that it has changed more than 50%) Trac could display it in this way: <old value> to <new value>.
              framay <franz.mayer@…>

            
              508
              'Related checkins' feature
              ticket system
              0.7
              unscheduled
              enhancement
              normal
              
              new
              2004-06-03T20:52:37+02:00
              2010-11-17T09:24:44+01:00
              In CVSTrac, a ticket has a field called "Related Checkins" which shows a list of checkins (they would be changsets in trac) and their comments.  
You can add and remove from this list by editing a comma-seperated list of related checkins.
However, the most useful part, is that by putting a ticket number into your checkin message, it automatically adds that checkin to the "Related Checkins" of the ticket.
Eg. svn commit -m 'Added the ability to edit existing tickets. This fixes ticket #411'
Then when you view the ticket #411 you can see that checkin there without doing any more work.
This feature made CVSTrac sooo useful, because it was very easy to make this connection from the ticket to the checkins that attempted to fix it.
bonus marks:
The whole idea of two-way linking useful in general -- once you had this feature you might also show wiki pages linking to a ticket, or tickets linking to a wiki page.  Often with information given by people, the incoming links are as relevant as the outgoing ones.  
BUT the automatic pingback from the checkins to the tickets is by far the most useful!

              dobes

            
              925
              [PATCH] Allow wiki syntax in labels for custom fields
              ticket system
              devel
              unscheduled
              enhancement
              normal
              athomas
              assigned
              2004-11-13T22:11:29+01:00
              2010-06-15T23:13:28+02:00
              The proposal is to add a possibility to use Wiki syntax in labels for custom fields.
Example 1: We need to put emphasis on ''Platform'' field
{{{
[ticket-custom]
platform         = select
platform.order   = 1
platform.label   = '''Platform'''
platform.options = |Intel P4|Intel XEON|AMD Athlon 64|Other
}}}
Example 2: We need to define a link to help screen for ''Platform'' field
{{{
[ticket-custom]
platform         = select
platform.order   = 1
platform.label   = [wiki:HelpPlatform Platform]
platform.options = |Intel P4|Intel XEON|AMD Athlon 64|Other
}}}
Attached patch contains an implementation for the proposal.

              pkou <pkou at ua.fm>

            
              2775
              Automatic matching of similar issues
              ticket system
              0.9.4
              unscheduled
              enhancement
              normal
              jonas
              reopened
              2006-02-17T11:07:42+01:00
              2010-09-10T14:47:51+02:00
              So in order to make things easier when prioritizing, it would be really cool to see something that displays how many issues there are with closely matching content. This would help when duplicate tickets are created, in order to more easily show the user where the dupes are, and also when prioritizing which issues should be worked on first (if the basis is the amount of requests)
              chris@…

            
              2968
              need a "contains" option for Owner if restrict_owner is true
              ticket system
              0.9.4
              unscheduled
              enhancement
              normal
              jonas
              new
              2006-03-31T16:05:30+02:00
              2010-09-10T16:28:19+02:00
              #1439 ([1664]) tied up the "restrict_owner" to control not only the newticket page but also the search page.
However in light of requests to edit or clean-up the userlist (#2351, #1347) - it should be recognised that dropdown for owners of "new tickets" may not be the same as the owners you want to search for. 
so we need the "contains, startswith, endswith" options for owner even if the restrict_owner is true.
This does stop those of us using the "query" system from effectively managing our reporters. 

              anonymous

            
              3003
              milestone could be a ticket
              ticket system
              0.9.4
              unscheduled
              enhancement
              normal
              cboos
              new
              2006-04-09T09:31:51+02:00
              2012-04-20T08:01:08+02:00
              can milestones be implemented as tickets too, just by marking a ticket as milestone? a milestone can depend on other milestones, they can be in parallel, they have a responsible, they have an importance, and they depend on the completion of tickets.
currently the milestone concept has a few weaknesses:
 * changes are not tracked
 * no responsible
 * no dependencies (or just implicit by setting dates)
 * consolidated view over multiple trac instances, i.e. have a big milestone consisting of small ones stored in other trac instances.
mark a ticket as a milestone, intertrac, and ticket dependencies would solve 95% of these issues. do you see any disadvantage in doing this?

              ThurnerRupert

            
              3785
              Regular Expression Match against custom field values
              ticket system
              devel
              unscheduled
              enhancement
              normal
              athomas
              new
              2006-09-25T23:42:20+02:00
              2010-06-28T23:56:14+02:00
              It would be handy to add an option to the Trac Custom Fields feature that allows a regular expression match string as a sanity check against a custom field.  As some fields require the flexibility of text input, but within certain parameters that a SELECT field doesn't offer, this could be very handy.  The match string would just have to evaluate to true if the field works.
I did a few searches and didn't see anything like this -- please enlighten me if otherwise.  I could attempt to look at a patch if there is interest, though I haven't worked with Python before.
Suggestion for implementation:
{{{
[ticket-custom]
test_date_field = text
test_date_field.label = Test a Date
test_date_field.value = 
test_date_field.match = /\d{4}-\d{2}-\d{2}/
}}}

              nmelnick@…

            
              4173
              When "View Ticket" is selected, sub-options should always be visible.
              ticket system
              0.10
              unscheduled
              enhancement
              normal
              jonas
              new
              2006-11-15T14:00:38+01:00
              2010-09-10T17:01:39+02:00
              This request is to help lower the learning curve and to make navigation more obvious.
I've used trac for many months now, but still keep forgetting how to navigate to "Custom Query". Some people in my team didn't know this feature exists - they just use Search. Why? The link is not always visible. 
When viewing a ticket (where I spend most of my time), the "View Tickets" button is selected (but with no sub-options shown). Therefore I never think to click it again. So instead: 
 * I click something else like "Search". Nope not there...
 * I click "View Tickets", and the text appearing on the left attracts my view. I don't even notice something small has appeared under "view tickets", because there was nothing there before. 
 * I scratch my head and hunt around some more.
'''Proposed solution''':
In all screens where the "View Tickets" button is rendered selected, the two sub-options "Available Reports" and "Custom Query" should also be displayed.

              l.usherwood@…

            
              4632
              Dropdown list for the CC field
              ticket system
              0.10.3
              unscheduled
              enhancement
              normal
              jonas
              reopened
              2007-01-31T10:10:23+01:00
              2013-04-11T13:59:34+02:00
              I want to make CC field in view as Multiple selection dropdown list.
How can i do it??
              anonymous

            
              5378
              ajax bandbox for input of milestone, component, assign to, and cc
              ticket system
              
              unscheduled
              enhancement
              normal
              jonas
              new
              2007-05-26T14:01:52+02:00
              2010-06-30T23:48:42+02:00
              it would be gread to have a ajax bandbox (see [http://zkoss.org/zkdemo/userguide/ zkoss userguide, bandboxes) for the following fields:
 * milestone: select one, search not necessary if they are sorted right, link to add a new one
 * component, search, select one, link to add a new one
 * assign to, search, select one
 * cc, search, multiple select
with jquery i did not see a similar demo, sorry.

              ThurnerRupert

            
              6548
              different types of ticket need different workflows
              ticket system
              0.11b1
              unscheduled
              enhancement
              normal
              jonas
              reopened
              2007-12-23T02:02:06+01:00
              2011-12-29T09:18:20+01:00
              Actions should be selectable based on the ticket type (different Workflows for different tickets.
This is becoming a frequent request, with clear usecases.  The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point.
              anonymous

            
              7015
              Provide interface to fill custom select-boxes
              ticket system
              
              unscheduled
              enhancement
              normal
              cboos
              new
              2008-03-18T14:08:34+01:00
              2010-07-13T13:27:33+02:00
              would be nice to have a interface which can provide data for the selectboxes you can find in the properties fieldset of a ticket.
we have the problem that our software has a lot of plugins which are all described in the trac-wiki and the ticket system is used for managing the bugs etc.
The component select-box is very often not uptodate because someone added a new plugin and this plugin wasn't added to the component list yet.. so the problem is, that nobody can report bugs/feature request which are related to the new plugin..
              Markus.Staab

            
              7290
              restrict_owner_force Option to populate user list
              ticket system
              
              unscheduled
              enhancement
              normal
              
              new
              2008-06-01T20:36:53+02:00
              2010-07-02T23:18:04+02:00
              The restrict_owner setting changes the field to a dropdown list that has (1) TICKET_MODIFY rights and (2) logged in at least once.
In an environment where you add users - and want them to be assigned tickets - even if they have not logged in before can be useful. Maybe the following option can be added:
Something like Add restrict_owner_force = TRUE in ini file to populate the list with the TICKET_MODIFY rights, without having logged in. This way either the filtered and unfiltered lists can be made available depending on the environment requirements. I have need for both situations.
              bill.meyer@…

            
              7300
              [PATCH] Support for ticket reassignment in trac-post-commit-hook
              ticket system
              
              unscheduled
              enhancement
              normal
              
              new
              2008-06-04T00:27:22+02:00
              2010-07-19T09:34:30+02:00
              I extended [source:trunk/contrib/trac-post-commit-hook trac-post-commit-hook] to support reassignment in the form of:
reassign #1 to user
assign #1 user

              ian@…

            
              7911
              Optional validation for custom fields
              ticket system
              none
              unscheduled
              enhancement
              normal
              
              new
              2008-12-24T18:04:39+01:00
              2010-07-03T23:09:21+02:00
              JQuery permits a nice environment to build custom/dynamic drop-down lists for custom fields in trac tickets; unfortunately validation for the ticket fails as the dynamic value for a field with an option list cannot be found in the configuration file.
At least two solutions are possible: 
 1. Add an option for turning off validation in comparing the value against the option list, and
 1. Allow for dynamic validation.
I have implemented the solution for #1 (attached).
              trac@…

            
              8069
              [PATCH] Support list of users as options list in ticket custom field
              ticket system
              0.11.3
              unscheduled
              enhancement
              normal
              
              reopened
              2009-02-18T19:57:54+01:00
              2012-08-20T15:46:20+02:00
              In the process of migrating from a Borland StarTeam install to Trac+SVN, I needed the ability to assign multiple users to a ticket.  Borland provided the ability to include custom Change Request fields which could be limited to the list of valid users within the StarTeam project.
Attached is a patch which implements similar behavior in Trac.  The patch introduces a simple variable replacement scheme to the options attribute of a custom ticket field.  The INI section looks like this:
{{{
[ticket-custom]
devtest_assigned = select
devtest_assigned.label = Dev Tester Assigned
devtest_assigned.options = $userlist
}}}
Code in ticket/api.py checks for a select custom field which has an options attribute of literally "$userlist".  If such a field is found, the field is passed to the existing function eventually_restrict_owner() to insert the listing of valid users.
The attached trivial three-line patch appears to work well against Trac-0.11.3.
              Zachary Bedell <zbedell@…>

            
              8163
              Grouping owners
              ticket system
              none
              unscheduled
              enhancement
              normal
              
              new
              2009-03-26T12:18:11+01:00
              2010-06-10T21:13:54+02:00
              If I set restrict_owner = 'true' in trac.ini, I can select from a list of people who have the proper permission to edit tickets as "owner". The drop down list itself is only alphabetically arranged, without any classifications. 
It would be good if there is a something to set the drop down list like the following example.
{{{
Group 1
- User A
- User D
Group 2
- User E
- User F
Group 3
- User B
- User C
- User G
- User H
}}}

              repeat <repeat@…>

            
              8653
              [PATCH] Don't allow anonymous users to modify some fields
              ticket system
              0.11.5
              unscheduled
              enhancement
              normal
              
              new
              2009-09-09T19:15:47+02:00
              2010-11-26T15:00:13+01:00
              This patch lets you set a comma separated list of fields that won't be visible at /newticket time to users without TICKET_MODIFY status. 
Included is a bonus exception check we received when there were non-numeric ticket numbers. 
To use:  in trac.ini, we have this line:
{{{
[ticket]
not_anon_fields=load,priority,keywords,revw,owner,cc,xref,weeks,milestone
}}}
These are fields we do NOT want 'anonymous' users to modify when creating a ticket.  (For example, revw is used to mark a ticket with the name of a reviewer.)
Note that there is a default list of fields hidden as well with this patch. The default could be made empty.

              Steven R. Loomis <srl@…>

            
              8702
              Different workflows when viewing own tickets/others tickets
              ticket system
              0.11.5
              unscheduled
              enhancement
              normal
              
              new
              2009-09-29T22:49:10+02:00
              2010-07-04T00:04:49+02:00
              I want to have an "accept and resolve" workflow for accepting someone else's ticket and closing it in one step, but it's extraneous when you're viewing your own tickets. It would be nice if I could create a workflow that would only show up when you're viewing your own ticket, or only show up if you're viewing someone else's ticket. Maybe something like `workflow_name.owner = ( self | others | any )` (of course `any` being the default, the current behavior).
              adrian.price@…

            
              8812
              Text field with post-label and right alignment
              ticket system
              none
              unscheduled
              enhancement
              normal
              
              new
              2009-11-12T16:52:59+01:00
              2010-07-04T00:15:07+02:00
              The TH:TimingAndEstimation plugin uses text fields as number fields.
Either allow for a proper number inputfield or extend the text field to allow for:
 * a right alignment of the value
 * an post-label that can be used as an unit

              guido.stet@…

            
              9289
              Permissions for custom ticket fields
              ticket system
              0.11.4
              unscheduled
              enhancement
              normal
              
              reopened
              2010-05-04T12:17:24+02:00
              2011-05-11T01:55:53+02:00
              I would like to request a feature to be able to specify permissions for custom ticket fields. So that for a defined custom field you would be able to define users which can edit it on ticket opening, edit it later and also see it (or not) altogether.
This is very hard to do properly with a plugin as it requires finding out in `post_process_request` phase where all field has been displayed and removing that (ticket view, RSS, alternative views, ticket notifications, ticket queries, searching tickets...). It would be much easier if Trac would simply remove it from a list of fields in the first place if user would not have access to it (in a given ticket state).
              Mitar

            
              9495
              CommitTicketUpdater - git and replayed commits
              ticket system
              0.12dev
              unscheduled
              enhancement
              normal
              
              new
              2010-07-11T20:33:36+02:00
              2010-09-13T13:00:38+02:00
              I do all my development over two branches, a stable one and an experimental one, which I merge periodically. So, each time I merge `stable` into `experimental`, commits from `stable` are again passed on to the ticket updater. So, sometimes this ends up producing duplicate comments and the ticket being closed twice...
My opinion is that could be an option that would somehow trigger the detection of duplicate commits and ignore them. I'm not very sure how to do this, if I should check if there's already a comment with the given commit sha1 associated with the ticket (kind of hacky), or checking the past repository history (ignoring the last changeset) for the commit (not sure how fast it will be).
I would be willing to produce a patch for that, if you believe this is something worth investing time on. Otherwise, I can just try changing a bit my commit hook.
However, I believe that this will be a problem with most distributed VCs, so...
              pferreir

            
              9505
              Missing feature from ticket query module: color tickets based on contents of field
              ticket system
              
              unscheduled
              enhancement
              normal
              
              new
              2010-07-16T18:08:16+02:00
              2010-07-16T20:56:13+02:00
              '''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 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.'''
I think that a missing feature is the ability to color tickets based on values. For example, you can color tickets red that have the priority of "blocker".
If this already exists, could you please provide some documentation on how to accomplish this query?
              aaronaddleman@…

            
              9508
              Provide per-type resolution lists
              ticket system
              
              unscheduled
              enhancement
              normal
              
              new
              2010-07-18T16:53:29+02:00
              2010-09-23T16:34:18+02:00
              The default set of resolutions (fixed, invalid, wontfix, etc) are fine for defects, but don't make a lot of sense for tasks.
It would be nice to be able to have the "Resolve as" menu include choices specific to each ticket type.  For a task, that might be "done","wontdo","postpone", etc.

              roy@…

            
              9530
              Ask questions to the ticket reporter.
              ticket system
              0.11.5
              unscheduled
              enhancement
              normal
              
              new
              2010-07-28T20:49:45+02:00
              2010-07-28T22:40:16+02:00
              I'd like the posibility to ask questions to the ticket reporter, asking for more detail or specific questions about the ticket. Questions should be included in the notification system so that the reporter can receive an mail with the question and then answer. Questions should be visualize with the ticket.
              fglaeser@…

            
              9706
              New ticket_change class: commit
              ticket system
              0.12-stable
              unscheduled
              enhancement
              normal
              
              new
              2010-10-23T00:58:34+02:00
              2010-12-28T23:54:39+01:00
              We have had an issue on our instance of TRAC where a developer typed a commit message awkwardly, and (because he had an edit button), attempted to fix the wording.
The problem he had was that upon clicking submit, the page would refresh but the changes would not be applied, yet if he would click edit again, his changes would be present there.
While I do consider this a bug, I respect the fact that as it stands, it would be way too hard and unnecessary to change, because you would cause an instance where a commit message says one thing, and the TRAC comment says another.
I am proposing a new type of value for use in the ticket_change table,"field" column, named "commit".
This would be functionally identical to the comment 'field' type, except it will show the reply button (maybe), but remove the edit button from view. It should only be set when using the commit ticket updater plugin, and similar methods.
              jsalaz@…

            
              9736
              Add an AND operator to ticket query syntax
              ticket system
              0.12dev
              unscheduled
              enhancement
              normal
              
              new
              2010-10-31T04:39:14+01:00
              2011-05-11T02:06:12+02:00
              Add an add operator to ticket query syntax (used for example in macro). Currently it is only possible to do or operator queries. So it is impossible to query for example tickets, which have keywords A and keyword B at the same time.
              Mitar

            
              9740
              Impossible to CC a username with spaces
              ticket system
              0.12-stable
              unscheduled
              defect
              normal
              
              new
              2010-11-01T14:22:20+01:00
              2010-11-01T16:05:19+01:00
              It is impossible to CC a username with spaces in the username such as "Joe Bloggs", attempting to enter that treats as two different users Joe and Bloggs.
Suggest first attempt to establish that usernames separated by commas as known usernames before splitting by spaces for known usernames.
              david+trac@…

            
              9930
              Allow configuration of ticket query cache time
              ticket system
              0.12.1
              unscheduled
              enhancement
              normal
              
              new
              2010-12-15T11:36:16+01:00
              2010-12-15T19:46:56+01:00
              The [/query] page stores the query results for one hour in the user session. When the same query is run in this time period the differences are highlighted with italic font. I would like to be able to alter this behavior, either by disabling the cache or by reducing the cache time, which is hard coded as one hour.
              Jorrit Schippers <jorrit@…>

            
              10018
              no apparent way to make set_owner default to existing owner
              ticket system
              0.12-stable
              unscheduled
              defect
              normal
              
              new
              2011-02-09T22:00:51+01:00
              2012-11-21T00:08:46+01:00
              We are using the custom workflow to manage our tickets and my users want the assignment of the owner to be separate from the promotion of state.  For example, we have defined the Work state, which has TICKET_MODIFY permissions and set_owner operation.  
Here is the problem we are seeing:  The owner is assigned when the ticket is created (but sometimes, it may not be assigned until it is moved to Work).  If the owner was assigned, then the radio dial that sets Work as the current state also has an owner field that defaults to the current editor, not the current owner.  In order to keep the same owner, the editor has to cut and paste it.  We would like a way to promote tickets without affecting the owner.  
              matkinson@…

            
              10508
              Support for networkedhelpdesk.org
              ticket system
              
              unscheduled
              enhancement
              normal
              
              new
              2011-12-21T15:01:06+01:00
              2013-02-04T17:02:06+01:00
              Add Support for the networkedhelpdesk.org initiative. So Trac would work together with other Application and Ticketing systems...
See for futher information the Website [http://networkedhelpdesk.org]
              michael.imhof@…

            
              10698
              Workflow action with non-ascii letters fails to change owner properly
              ticket system
              0.12-stable
              unscheduled
              defect
              normal
              
              new
              2012-05-18T13:45:07+02:00
              2012-05-21T19:29:27+02:00
              Hi,
Consider the two workflow actions below :
{{{
[ticket-workflow]
reassign = * -> *
reassign.operations = set_owner,leave_status
reassign.set_owner = client,po,team
todo = * -> todo
todo.operations = set_owner
todo.set_owner = client,po,team
}}}
If i set the owner with reassign action, it works well, as expected.
If i use the `toto` action, the owner is set to `client,po,team` literally, even if i select properly `client`.
Trac should set the status to `todo` and the `owner` to the one selected.
Can you confirm this ?
Regards,
Étienne
              ebersac@…

            
              10776
              set custom fields via ticket workflow
              ticket system
              0.11.5
              unscheduled
              enhancement
              normal
              
              new
              2012-07-19T12:19:43+02:00
              2012-07-19T15:44:42+02:00
              I have two questions which i can't find example how to config them in the trac.ini file.
I want to add to the workflow two states but I need them to enable insert data:
attachment Picture added
{{{ 
Released in revision _______________ need to add a number of revision.
}}}
I saw examples like configure a number (like in duplicate) or assigning ticket to other user.
But I didn’t see detailed example of how to add text box.
I know I have to configure the text under [ticket-custom] but how do I use this configured field:
{{{
[ticket-custom]
released = text
released.label = released in version
}}}
Do I add under [ticket-workflow] like this?
{{{
[ticket-workflow]
released = text
}}}
Thanks,
Asaf Levy 
              asaf.levy@…

            
              8135
              [PATCH] Prev, Query, Next links at bottom of ticket page
              ticket system
              0.13dev
              next-dev-1.1.x
              enhancement
              normal
              
              reopened
              2009-03-17T19:27:21+01:00
              2012-06-23T20:08:03+02:00
              When you're viewing a ticket after selecting it from some report/query, there are usually three links at the top of the page saying (roughly):
* Previous ticket
* Back to Query
* Next ticket
Is there some way to have these links repeated at the bottom of the page? When updating tickets, most of the work happens at the bottom of the page and it's a pain to keep scrolling to the bottom to do the work, then to the top to click "Next ticket" then back to the bottom again...
I tried looking around for some HTML templates that I can edit to achieve this but I got as far as finding that the changes I need to make are probably in ticket/web_ui.py before calling it a day.
Can I request this feature be added? Also, if there is a quick hack I can make to my existing (trac 0.11.3) install, I'm all ears...
Ta.

              srevill@…

            
              2616
              Show ticket submission time in Change History
              ticket system
              0.9.3
              next-major-releases
              enhancement
              minor
              jonas
              reopened
              2006-01-16T20:52:30+01:00
              2009-04-09T17:52:48+02:00
              It would be very useful if it were easier to figure out the exact date and time of a ticket's submission. Currently it's only shown as e.g. "three months ago" at the detailed ticket view instead of "2005-10-12 15:18". All modifications are shown with the exact second it happened, but not the original creation.[[BR]]
I suggest the time of creation is added to the Change History of the ticket view.
              johan.levin-atsign-lorensbergs.com

            
              3734
              Provide Possibility to 'freeze' a Milestone
              ticket system
              devel
              next-major-releases
              enhancement
              minor
              jonas
              reopened
              2006-09-16T02:04:54+02:00
              2010-09-10T14:56:06+02:00
              It should be possibly to flag a milestone as 'freezed', thus no new tickets can be filed.
see #3730 for an example-conflict.
              ilias@…

            
              5663
              Suggestions for Ticket Reports
              ticket system
              
              next-major-releases
              enhancement
              minor
              nkantrowitz
              new
              2007-07-05T21:10:08+02:00
              2011-05-11T02:15:45+02:00
              One nice feature of the ticketing system at http://versionone.com/ is the ability to edit ''Ticket Properties'' fields in the table view itself, i.e. via dropdowns right there, without having to open each individual ticket. I know this feature would help me.
Another idea which would help me is to load at least part of the ''Description'' field (even in a plain text version) onto the report page and then show it to me in a popup when I rollover the ticket. This would also help me, as the ''short summary'' is often not enough to recall the full details.
Thanks.
              fredthejonester@…

            
              7558
              New TracQuery match operator for "contains the word" would be useful
              ticket system
              0.11.1
              next-major-releases
              enhancement
              minor
              
              new
              2008-08-24T04:52:14+02:00
              2010-10-31T02:35:26+01:00
              In a number of situations, it's useful to be able to search field values that ''contain a certain word'', not just a certain string (as `~=` does). The distinction is essentially a word boundary regex versus an all-inclusive regex. That is, I'd like to be able search like this:
{{{
.*\bmyvalue\b.*
}}}
where `\b` is a "word boundary" as defined by [http://www.pcre.org/pcre.txt the PCRE standards]. Right now, using `~=`, I can only search like this:
{{{
.*myvalue.*
}}}
The most pressing use case for such a facility (at least for my projects) is support for [http://marc.info/?l=trac&m=121936459010029&w=2 "subticket keywords", an extremely flexible technique of associating one ticket with another] by using the TracLinks conventions in the keyword field.
For example, to associate a new ticket as a "subticket" of ticket:13, I place `#13` in its keyword field. Currently, this can later be extracted with a TracQuery such as `[[TracQuery(keywords~=#13)]]` however this incorrectly matches `#130`, `#131`, and so on. Thus, a word boundary match operator was [http://marc.info/?l=trac&m=121941561920166&w=2 suggested by Remy Blank later in the same thread].
At first blush, it seems that the TracQuery "mini language" is actually [source:trunk/trac/ticket/query.py@7484:439-444#L437 implemented with simple ANSI SQL-based wildcards], which makes implementing word boundary matches non-trivial. I'd imagine one might have to wrap a call to [source:trunk/trac/ticket/query.py@7484:254-311#L254 Query.execute] that catches the results of a `~=` query and then filters these results further (possibly with a [Wikipedia:Decorator_pattern decorator]?).
              meitarm@…

            
              8677
              Ability to follow/unfollow a ticket
              ticket system
              none
              next-major-releases
              enhancement
              minor
              
              new
              2009-09-16T09:05:59+02:00
              2011-06-07T17:51:05+02:00
              It would be great to be able to start following (receive notifications to email) or stop following any ticket you are watching in one click. This would work for logged in users only of course. 

              Alexey Timanovsky <timanovsky@…>

            
              548
              [Patch] Support for subcomponents
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              jonas
              reopened
              2004-06-15T04:44:22+02:00
              2013-01-27T22:12:21+01:00
              I'd like to request the addition of a subcomponent field.  This would be useful for breaking large component pieces into smaller subsets.  In particular, the project I'm working on includes a core engine and several plug-in style projects.  It makes sense to keep it all in the same svn repository as well as the same trac db.  However, with the addition of a subcomponet (or feature or something like that), the granularity of tracking for the plug-in projects would be much better.
              acarter24@…

            
              1395
              Text box for duplicate when a bug is a duplicate
              ticket system
              devel
              next-major-releases
              enhancement
              normal
              
              reopened
              2005-04-03T13:22:08+02:00
              2010-05-02T11:33:37+02:00
              There should be a form item for writing the bug number when you mark a ticket as a duplicate.
Developers are lazy, they tend to forget stuff, etc.
The original bug should get a notice that given bug was marked a dupe of it

              ludde

            
              2467
              Link user name in reports to custom query showing that user's open tickets
              ticket system
              0.9.2
              next-major-releases
              enhancement
              normal
              jonas
              new
              2005-12-09T16:46:10+01:00
              2007-03-08T22:57:04+01:00
              It would be nice if the usernames in the report view linked to custom queries showing active tickets belonging to that user.
              earle at downlode dot org

            
              2497
              Change custom query with group to also have a table of contents for group
              ticket system
              0.9.2
              next-major-releases
              enhancement
              normal
              jonas
              new
              2005-12-16T19:28:33+01:00
              2007-04-02T11:26:20+02:00
              If group results option is selected in a custom query it would be nice if the results starts off with a table of contents (TOC) with links to the coresponding table.  For example if group by components is selected then list of components should be listed with links to the individual component ticket tables.  It may also be good to list the number of tickets that are new, assigned, reopened, and closed for each component in the TOC.
              anonymous

            
              3153
              Include tickets without milestone in iCal
              ticket system
              0.9.5
              next-major-releases
              enhancement
              normal
              mgood
              new
              2006-05-15T16:53:34+02:00
              2010-12-07T18:45:10+01:00
              Currently if you wish to download your tickets for a specific project in Ical format that can be read using Mac's Ical (which is what I use). Often I write tickets with no specific milestone on gamedev.acm.cs.rpi.edu and I would like them in the same format as all my other tickets. My request is that the feature enabling me to download milestones to Ical be implimented on the ticket system.
              bowenk@…

            
              3255
              Context-sensitive new ticket prefill
              ticket system
              none
              next-major-releases
              enhancement
              normal
              cboos
              reopened
              2006-06-13T00:27:35+02:00
              2012-06-23T20:30:05+02:00
              I'd like to extend the idea behind a `worksforme`-ed #3253 as follows: it'd be nice to enter a ticket quickly based on the conditions I'm ''looking at'' right now.
  Example: I create a query for __owner__ ''X'' and __milestone__ ''Y'' using TracQuery. I review the results and decide to add to the workload of ''X'' and create one more task. It'd be great to simply be able to click on a link that says __Create new ticket in this view__ (not a good wording) or something like that.
Similarly, and that's what #3253 was proposing, it'd be nice to create a ticket right from the milestone's page that is assigned to this milestone. Or create a ticket assigned to this milestone and a particular component by clicking one of the `[`now imaginary`]` knobs next to one of the __sort by ''component''__ progress bars on the right of the milestone's view. Or by clicking somewhere in the query that results from clicking on this progress bar... You get the idea.
Moreover, I actually would prefer the standard __New Ticket__ action to be ''context-sensitive'' as I describe above and always prefill ticket fields for me based on what is in the current page's view.
To extend this beyond milestones and queries, when I'm looking at a Wiki page or a commit log or a source code item, and I click __New Ticket__, I'd be glad to see that there's a [wiki:TracLinks TracLink-ified] reference to that object. Maybe that's one of the ideas TracObjectModelProposal is trying to accommodate, but it would need help from Trac on how to ''deduce'' some relations between Trac objects, in this case to help fill out a ticket more quickly.
              s.lipnevich@…

            
              4374
              Custom Tickets Select Box Auto-generation
              ticket system
              0.10.2
              next-major-releases
              enhancement
              normal
              jonas
              new
              2006-12-11T16:36:37+01:00
              2010-09-10T11:37:48+02:00
              It would be nice if instead of specifying all the available options for a select box like: 
option1|option2|option3...
in trac.ini, which could run into hundreds, if instead you could specify some kind of query so that this list is automatically generated from the database and keeps up to date. For example, if you had 'is associated with customer' as a select box and the customers are generated from a 'Customers' table in the database. e.g. 'select name from Customer where active=1' so that only customers who are still active (assuming this list changes quite often) are shown in the list. 
Apologies for the poor example.
At the moment I have written a script that reads trac.ini and modifies this manually but it is far from ideal as it only runs once a day so the data isnt always up-to-date
              a.rodger@…

            
              6525
              Disable Submit Ticket Button
              ticket system
              
              next-major-releases
              enhancement
              normal
              jonas
              new
              2007-12-19T16:02:01+01:00
              2012-09-13T08:31:44+02:00
              It would be a nice idea to disable the ''Submit ticket'' button until the ''Preview'' button has been clicked. This is similar to editing wikipedia pages and may prevent to many errors in tickets.
              anonymous

            
              8314
              Dynamic Default Values
              ticket system
              0.11-stable
              next-major-releases
              enhancement
              normal
              
              new
              2009-05-22T22:30:53+02:00
              2010-06-09T11:49:08+02:00
              In the config file, we have options to provide default values for multiple fields. It appears that these can only be string literals though. 
Is it possible, or easy to implement, a dynamic default value. 
More specific:
The way I have permissions set-up, there are several groups. Each user belongs to one of these groups, and has no other permissions set. 
I want this group to be the default value for a field, so that we can later sort them by what group/company these tickets originated from.
thanks
              anonymous

            
              8681
              Allow adding usernames to a ticket CC list
              ticket system
              0.11.4
              next-major-releases
              enhancement
              normal
              
              new
              2009-09-22T00:27:26+02:00
              2012-07-26T20:43:50+02:00
              Allow adding usernames to a ticket CC list instead of e-mail addresses for users which can only select checkbox to add themselves to the CC list (and thus cannot control content). For our setup it would be enough to just add a project-wide configuration switch which would tell Trac whether to prefer usernames or e-mail addresses.
              Mitar

            
              9445
              Adding new action
              ticket system
              0.11
              next-major-releases
              enhancement
              normal
              
              new
              2010-06-17T13:33:45+02:00
              2010-06-17T14:15:28+02:00
              I need to give action permission to create/edit component to particular user, without giving TICKET_ADMIN action permission. Means how can I add following permission
COMPONENT_ADMIN, COMPONENT_CREATE, COMPONENT_DELETE, COMPONENT_MODIFY.

              anonymous

            
              7617
              Various ticket fields don't like leading or trailing /
              ticket system
              0.11.1
              next-minor-0.12.x
              defect
              minor
              rblank
              new
              2008-09-10T23:53:29+02:00
              2011-09-17T17:03:35+02:00
              As an example, create a milestone where the name either starts or ends with a `/`. It will be visible in the roadmap, but clicking on the link will lead to an error, saying that the milestone cannot be found. The same problem applies to other enumerated fields like components, priorities or versions, when edited in the admin module.
The problem is due to the roadmap module creating links to milestones using `req.href.milestone(milestone_name)`, and `href` stripping leading and trailing slashes at [source:branches/0.11-stable/trac/web/href.py@7493:147#L147 this location]. The same analysis applies to the admin module.
I'm not sure if the solution is to build the milestone and admin links differently, or to remove the automatic stripping in `Href`. Opinions welcome.
              rblank

            
              7874
              Changing component makes owner "none" while owner should be empty
              ticket system
              0.11.1
              next-minor-0.12.x
              defect
              minor
              
              new
              2008-12-09T11:22:58+01:00
              2010-05-03T22:13:53+02:00
              I have a set of tickets of type "defect"
When an action "add comment" is performed, the ticket is disowned (owner is empty), and status becomes new.
The ticket shows up in "new defects", this is exactly as expected.
When I change the component of a "defect" ticket, the owner becomes "None" (seen when listing all tickets), the ticket itself shows "new defect".
But when the owner is "None" in stead of empty, the ticket does not show up in the "new defects list", while the ticket is a new defect.
so:
1) changing the component of "defect" tickets makes it's owner "None" while it should be empty.
2) lisitng "new defect" does not list the new defects with owner "None", only the ones with an empty owner field
3) the "None" owner is seen in the "list all tickets", but when showing http://trac/xx/ticket/<number>, the "owned by" field of a ticket owned by "None" is empty 
              linuxificator@…

            
              9457
              Unsubmitted comments lost after attaching files
              ticket system
              0.11.6
              unscheduled
              enhancement
              minor
              
              new
              2010-06-23T18:04:02+02:00
              2010-09-30T09:48:22+02:00
              While modifying assigned tickets of mine, I've noticed that if I add comments and then go to attach a file, when I selected the "Back to Ticket#" button at the top of the page, the attachment is saved but my un-submitted comments are erased.  Trac should save all modifications in memory until the changes are submitted.
              andrew.c.martin@…

            
              642
              RSS feed with all events for the tickets in a report
              ticket system
              0.7.1
              unscheduled
              enhancement
              normal
              jonas
              new
              2004-07-22T00:13:54+02:00
              2010-09-10T14:47:51+02:00
              To be able to track all changes of the tickets in the for example My Tickets report. 
              anonymous

            
              5866
              [patch] Workflow tweak: handle "not-state" transition specifications
              ticket system
              devel
              unscheduled
              enhancement
              normal
              jonas
              new
              2007-08-13T15:27:47+02:00
              2011-03-16T17:43:01+01:00
              I found myself wanting things like this in my [ticket-workflow]: 
{{{
reassign = * -> * 
reassign.operations = set_owner,leave_status 
reassign.permissions = TICKET_MODIFY 
needinfo = * -> needinfo 
needinfo.name = need info 
needinfo.operations = set_owner 
needinfo.permissions = TICKET_MODIFY
}}}
...but this would create two action options for a ticket in the 
"needinfo" state: "reassign and leave as needinfo", and "assign to new 
owner and leave as needinfo" ...which are of course the same thing.  I 
wanted to be able to do this instead: 
{{{
needinfo = *,!needinfo -> needinfo 
needinfo.name = need info 
needinfo.operations = set_owner 
needinfo.permissions = TICKET_MODIFY
}}}
 
This would indicate that the "needinfo" state was a valid next state from every other state ''except'' "needinfo".  To make this work, make the following tweak to /trac/ticket/default_workflow.py (line 161):
{{{
 if oldstates == ['*'] or status in oldstates:
}}}
...becomes... 
{{{
 if ('*' in oldstates or status in oldstates) and ("!%s"%status not in oldstates):
}}}
 
I haven't tested this extensively, and even though it should be backwards-compatible... use with extra initial scrutiny.
              Morris

            
              4636
              Component field sort order doesn't use locale
              ticket system
              0.10.3
              next-major-releases
              defect
              minor
              jonas
              new
              2007-02-01T11:03:46+01:00
              2012-04-03T20:36:41+02:00
              The items listed in the ticket drop-down menu for '''Component''' are sorted alphabeticaly.  However, this alphabetical sorting '''doesn't use the locale''' setting, an item as ''épargne'' will be at the bottom of the list, instead of being between the items ''crédit'' and ''guichet'' for example.
              antoine.delvaux@…

            
              1069
              query by example (e.g. when creating a new ticket, check for similar tickets)
              ticket system
              0.8
              next-major-releases
              enhancement
              normal
              cboos
              new
              2004-12-17T15:46:06+01:00
              2010-09-10T09:01:20+02:00
              There could be some ways to reduce the amount of ''duplicate''
tickets getting created. The simplest way would be to advertise doing a search:
E.g (any better english is welcome, of course): 
=== Create New Ticket ===
''Have you checked that the issue you want to report was not already raised before? If not, please '''Search''' for existing tickets describing your problem before creating a new one.''
Your email or username:
...
----
A more sophisticated way would be to do a search (in the tickets)
based on the content of the ''Short summary'' field and the ''Keywords'' field,
when the reporter ''Preview''s his new ticket. 
The result of the search would also appear on the ticket preview page.
From that point, the reporter could choose either to go on with the creation of
his new ticket (maybe clarifying what distinguishes it from other, similar
tickets), or to contribute to existing similar tickets if some are found 
and relevant for him.
              cboos@…

            
              1514
              Mantis conversion script
              ticket system
              
              next-major-releases
              enhancement
              normal
              cboos
              new
              2005-05-06T20:17:11+02:00
              2010-09-10T09:07:24+02:00
              A script to convert from Mantis(http://www.mantisbt.org/) to Trac would be super-cool!

              Paul Baranowski <paul@…>

            
              3006
              Want to be able to merge tickets
              ticket system
              none
              next-major-releases
              enhancement
              normal
              cboos
              new
              2006-04-09T22:50:38+02:00
              2011-05-31T21:44:53+02:00
              Rather than marking ticket A as closed and a duplicate of ticket B, it should be possible to mark ticket A as a duplicate of another ''without'' closing it; then when B is closed, A is closed as well, and the resolution message appended to both.
              dcrosta

            
              10352
              Docs do not reflect difference in wiki processing between custom text and textarea fields
              ticket system
              0.12.2
              next-minor-0.12.x
              defect
              minor
              
              new
              2011-09-13T19:01:30+02:00
              2011-09-13T22:04:15+02:00
              In http://trac.edgewall.org/wiki/TracTicketsCustomFields it is stated that both type=text and type=textarea fields can be set to format=wiki.  This is true, but the contents of the two fields are processed differently.  Specifically, macros aren't expanded in type=text fields even if they only generate one line of text.
The choice to have these two fields behave differently seems to be a conscious choice, following the comments and commits from ticket:1791.
This is not consistent with the behavior of built-in fields.  Typing a macro into the keywords field will cause the macro to be expanded.
I don't really have a problem with the current behavior, but for consistency's sake, either custom type=text fields should behave the same as built-in fields when format=wiki '''or''' the [http://trac.edgewall.org/wiki/TracTicketsCustomFields custom field docs] should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get.
              jj33@…