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,,new,2004-11-05T12:44:10+01:00,2023-04-13T09:07:18+02: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@… 11719,"Auto-preview breaks TicketExt plugin, possibily others",ticket system,1.0.1,next-major-releases,defect,major,,new,2014-08-15T18:27:07+02:00,2021-07-03T20:18:35+02:00,"When auto-preview kicks in and new ticket content is returned via XHR, `trac/ticket/templates/ticket.html` uses jQuery's `.replaceWith()` function to update the page. This has the effect of dropping all the `display: none` added to the page on initial load by `TicketExt`. One solution is to pass pass the XHR response through the same filters as the initial page load so the same manipulation (e.g., setting display attributes) can be applied. Another is to change contents rather than replace the entire DOM subtree. This can be done with: {{{#!diff diff --git a/trac/ticket/templates/ticket.html b/trac/ticket/templates/ticket.ht index 353ef63..d0865c3 100644 --- a/trac/ticket/templates/ticket.html +++ b/trac/ticket/templates/ticket.html @@ -79,7 +79,14 @@ $(""#propertyform"").autoSubmit({preview: '1'}, function(data, reply) { var items = $(reply); // Update ticket box - $(""#ticket"").replaceWith(items.filter('#ticket')); + var newProps = $('table.properties td', items); + $('#ticket table.properties td').each(function(i) { + $(this).html(newProps.eq(i).html()); + }); + var newDescription = $('div.description div.searchable', items); + $('#ticket div.description div.searchable').html(newDescription.html()); + if (items.hasClass('ticketdraft')) + $('#ticket').addClass('ticketdraft'); // Unthread, unrevert and update changelog if (!$('#trac-comments-oldest').checked()) $('#trac-comments-oldest').click().change(); }}} though this is likely a partial fix. (This has also been discussed at th:#11923.)",chris.nelson.1022@… 1962,Due dates on tickets & email notification on overdue dates,ticket system,0.8.4,next-major-releases,enhancement,minor,,new,2005-08-25T04:25:51+02:00,2021-06-03T22:03:37+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,,new,2004-01-29T05:53:39+01:00,2022-08-30T20:23:04+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 1084,Percentage complete,ticket system,0.8,next-major-releases,enhancement,normal,,new,2004-12-26T16:53:05+01:00,2023-02-11T22:54:18+01: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,2020-08-07T00:45:49+02: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@… 9648,[PATCH] Improve ticket fields with tooltips,ticket system,0.12,next-major-releases,enhancement,normal,,new,2010-09-27T11:29:42+02:00,2017-03-07T02:56:26+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 3370,"Custom query RSS feed differes from CSV, Tab files",ticket system,0.9.4,unscheduled,enhancement,normal,,new,2006-07-10T03:41:48+02:00,2021-02-28T19:55:05+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@… 12188,Suggest / autocomplete keywords in ticket properties,ticket system,,,enhancement,normal,,new,2015-08-27T13:58:40+02:00,2023-02-22T22:06:48+01:00,Similar to the requests for users (#7628) and milestones (comment:12:ticket:7628 / #1901) it would be a huge time saver to get suggestions and autocompletion for ''keywords'' that have been used before on other tickets.,anonymous 9740,Impossible to CC a username with spaces,ticket system,0.12-stable,1.6.1,defect,normal,,new,2010-11-01T14:22:20+01:00,2021-05-28T21:54:30+02: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@… 11469,Add a custom field admin panel,ticket system,,1.7.1,enhancement,normal,,new,2014-02-03T05:27:06+01:00,2022-11-16T06:31:12+01:00,"The th:CustomFieldAdminPlugin seems to be a reasonable start for integrating a custom field admin panel to the Trac core. Here is an outline of the changes: * Rework the template for minor enhancements (e.g. #11027 and #11056), improved styling and to make the markup more consistent with the other ticket `admin_*` templates. * Add a `CustomField` class to `trac.ticket.model` that wraps the configuration. Later on, the storage can be changes from //trac.ini// to the database without changing the interface. * Modify the `CustomFieldAdminPanel` class to inherit from `TicketAdminPanel` and refactor. * Add functional test cases. Proposed changes will be posted within the next few days.",Ryan J Ollos 13282,Ticket timeline events can't be filtered using a permission policy,ticket system,,1.7.1,defect,normal,,new,2020-05-02T05:05:15+02:00,2021-05-28T21:28:12+02:00,I'm trying to implement a solution for private ticket comments (th:#13776) and finding that the permission checking for timeline events is too coarse to implement a permissions policy that filters by resource realm `comment` and resource id `cnum`.,Ryan J Ollos 1233,Descriptions of Components,ticket system,0.8,next-dev-1.7.x,enhancement,major,,new,2005-02-28T15:52:00+01:00,2020-12-29T09:45:39+01: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 5211,Ticket - Wiki Integration enhancement/suggestion,ticket system,,next-dev-1.7.x,enhancement,minor,,new,2007-04-24T17:36:50+02:00,2020-12-29T09:45:39+01: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 10532,Show word diff when summary changes (instead of to ),ticket system,0.13dev,next-dev-1.7.x,enhancement,minor,,new,2012-01-19T09:47:24+01:00,2020-12-29T09:45:39+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 "" to "" 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: to .",framay 8069,[PATCH] Support list of users as options list in ticket custom field,ticket system,0.11.3,next-dev-1.7.x,enhancement,normal,,new,2009-02-18T19:57:54+01:00,2020-12-29T09:45:39+01: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 10040,Support for integer/float custom fields,ticket system,,next-dev-1.7.x,enhancement,normal,,new,2011-02-22T12:38:30+01:00,2020-12-29T09:45:39+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 10948,[PATCH] Clone functionality should also be available for users with TICKET_CREATE permission,ticket system,1.0,next-dev-1.7.x,enhancement,normal,,new,2012-11-12T09:20:15+01:00,2020-12-29T09:45:39+01: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@… 11367,"Ticket change history not updated when deleting or renaming Components, Versions and Ticket System Enums",ticket system,,next-dev-1.7.x,defect,normal,,new,2013-11-16T06:29:59+01:00,2020-12-29T09:45:39+01:00,"Similar to what we saw in #4582 for milestones, the ticket change history of associated tickets is not updated when deleting or renaming the following ticket system items: * Components * Enums (Priorities, Resolution, Severities, Ticket Types) * Versions The current behavior is that on rename the ticket field's value has the new name, and on delete the ticket field's value has the deleted name.",Ryan J Ollos 11856,Default values of ticket workflow fields should be configured in the [ticket-workflow] section,ticket system,,next-dev-1.7.x,enhancement,normal,,new,2014-12-02T01:21:31+01:00,2023-07-18T15:15:19+02:00,"The fields //resolution// and //status// in the list of `Ticket.protected_fields` ([browser:/tags/trac-1.0.2/trac/ticket/model.py@:51-52#L49]) are only modified by the workflow. #2045 moves Trac one step closer to adding `owner` to `Ticket.protected_fields` and only allowing the workflow to change the owner field (see comment:60:ticket:2045). Having `default_resolution` and `default_owner` as attributes of a ticket workflow action and configured through the `[ticket-workflow]` section rather than the `[ticket]` section has a few advantages: * It should be clear that these fields are controlled by the ticket workflow. * Unique default values can be provided for each action in the workflow. I've also found the attribute names `set_owner` and `set_resolution` to be a bit confusing. We might consider renaming these to `resolutions` / `owners` or `allowed_resolutions` / `allowed_owners`. For completeness, we could also consider adding `restrict_owner` as a workflow attribute, replacing or overriding `[ticket] restrict_owner`. This was mentioned in comment:1:ticket:11976.",Ryan J Ollos 11861,Add email fields property to TicketSystem,ticket system,,next-dev-1.7.x,enhancement,normal,,new,2014-12-03T16:02:21+01:00,2020-12-29T09:45:39+01:00,In comment:3:ticket:11594 adding `email_fields` to the `TicketSystem` was discussed. A patch that needs more work was proposed in [a6ea05df/rjollos.git]. The proposed change will be further investigated in this ticket.,Ryan J Ollos 13185,Keywords: remove duplicates and fixup separators,ticket system,,next-dev-1.7.x,enhancement,normal,,new,2019-07-30T23:10:45+02:00,2022-07-12T05:47:17+02:00,"In comment:16:ticket:13179, the following changes to the keywords field were proposed: * Fixup separators. Example: `kw1, kw2; kw3 kw4` -> `kw1, kw2, kw3, kw4` (or use whitespace rather than comma separators). This would match the behavior for the CC field. * Remove duplicates.",Ryan J Ollos 13206,Add ICustomFieldTypeProvider interface,ticket system,,next-dev-1.7.x,enhancement,normal,,new,2019-09-06T20:51:38+02:00,2023-04-07T05:38:06+02:00,"Copied from [ticket:11469#comment:4]: > Replying to [comment:3 rjollos]: > > * th:#7156 - API for defining new types of custom fields? > > Previously, I've worked it in https://github.com/jun66j5/trac-customfieldadminplugin/commit/8532c814 by reference to FieldRefactoring. In the branch, it added `ICustomFieldTypeProvider` interface which allows to define new types. I'd like to consider rebasing these changes and including in a 1.5.x release. Use cases: * th:comment:8:ticket:10284",Ryan J Ollos 221,Creating TR for multiple components,ticket system,,next-major-releases,enhancement,critical,,new,2004-04-02T02:41:40+02:00,2020-09-09T13:20:24+02: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,,new,2006-11-30T09:00:23+01:00,2016-04-10T12:08:45+02: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@… 1329,Ticket Search should (optionally) search only non-closed tickets,ticket system,0.8.1,next-major-releases,enhancement,major,,new,2005-03-21T09:19:37+01:00,2015-05-26T20:50:57+02: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 2464,Conditional fields in tickets,ticket system,0.9.2,next-major-releases,enhancement,major,,new,2005-12-09T11:34:48+01:00,2021-08-19T21:34:04+02: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 ==== Abilty to have different ticket fields for different ticket components ==== As for ticket types, but for components. See #2752 ==== 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@… 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,2014-07-31T15:41:40+02: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 3320,Custom fields can't be hidden,ticket system,devel,next-major-releases,enhancement,minor,,new,2006-06-26T16:16:35+02:00,2015-05-26T20:50:57+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@… 6249,Customized field labels for standard fields,ticket system,,next-major-releases,enhancement,minor,,new,2007-10-26T14:56:12+02:00,2015-05-26T20:50:57+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,2015-07-28T12:31:04+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 ;-) ).",Christian Boos 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@… 918,[patch] Custom Ticket Fields should support the multiple selection type,ticket system,devel,next-major-releases,enhancement,normal,,new,2004-11-12T19:42:28+01:00,2018-05-12T08:56:20+02:00,"I propose an addition to the TracTicketsCustomFields. Currently, there is support for the simple selection 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. ",Christian Boos 2662,assign tickets to multiple users,ticket system,0.9.3,next-major-releases,enhancement,normal,,new,2006-01-25T13:36:02+01:00,2021-09-19T18:37:53+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,,new,2006-03-30T21:41:12+02:00,2018-02-26T12:59:51+01: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@… 3749,recent ticket-comments macro,ticket system,0.9.6,next-major-releases,enhancement,normal,,new,2006-09-18T23:14:26+02:00,2020-05-19T19:23:14+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 4130,Ticket Component Interface Fails to Properly Check for Existing Component,ticket system,0.10,next-major-releases,defect,normal,,new,2006-11-11T00:33:08+01:00,2015-05-26T20:50:57+02: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 4549,"[PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ...",ticket system,0.10,next-major-releases,enhancement,normal,,new,2007-01-16T14:05:36+01:00,2017-01-02T16:49:48+01: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,2014-02-19T19:06:36+01:00,I.e. expand the [is|is not] operator set a bit.,macke@… 5999,From ticket to wiki : add links to ticket/comment metadata when appropriate,ticket system,,next-major-releases,enhancement,normal,,new,2007-09-10T11:24:56+02:00,2015-05-26T20:50:57+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,,new,2007-10-09T01:18:19+02:00,2015-05-26T20:50:57+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,,new,2007-11-12T12:59:29+01:00,2015-05-26T20:50:57+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) ",Emmanuel Blot 7176,Workflow actions indistinguishable from user changes,ticket system,devel,next-major-releases,defect,normal,,new,2008-04-30T03:17:34+02:00,2015-05-26T20:50:57+02: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. ",Eli Carter 7196,restrict ticket properties to add/edit only/...,ticket system,,next-major-releases,enhancement,normal,,new,2008-05-05T10:16:39+02:00,2015-05-26T20:50:57+02: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,2019-12-03T03:44:58+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@… 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_ 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,2023-04-19T18:08:14+02: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,,new,2008-12-12T18:26:14+01:00,2017-05-08T11:14:10+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,2015-03-30T18:37:03+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@… 9510,Action block stays visible when no actions available,ticket system,0.11-stable,next-major-releases,defect,normal,,new,2010-07-20T12:20:58+02:00,2015-03-02T22:27:22+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@… 9550,Ticket should be divisible,ticket system,,next-major-releases,enhancement,normal,,new,2010-08-06T04:51:22+02:00,2015-05-26T20:50:57+02: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,2014-08-02T06:47:32+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 9807,Wrong sections are collapsed by default!,ticket system,,next-major-releases,enhancement,normal,,new,2010-11-10T01:38:35+01:00,2015-03-19T15:20:49+01: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,,new,2011-04-10T21:35:04+02:00,2015-05-26T20:50:57+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 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,2015-03-03T15:34:58+01: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,2015-12-19T16:53:00+01: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 10755,[PATCH] CommitTicketUpdater does not allow user to define what state to jump to,ticket system,0.12.3,next-major-releases,enhancement,normal,,new,2012-07-02T22:27:07+02:00,2022-03-16T23:13:24+01: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 10983,PATCH (and RFC) for IQueryPreprocessor extension point,ticket system,0.11.6,next-major-releases,enhancement,normal,,new,2012-12-13T18:27:55+01:00,2018-06-14T19:47:14+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.1022@… 11301,intermittent failure with notification test,ticket system,1.0-stable,next-major-releases,defect,normal,,new,2013-09-15T18:32:54+02:00,2013-09-17T00:41:15+02:00,"The usual `make test` after a recent pull on trunk gave me the following: {{{ ERROR: test_from_author (trac.ticket.tests.notification.NotificationTestCase) Using the reporter or change author as the notification sender ---------------------------------------------------------------------- Traceback (most recent call last): File ""c:\Trac\repos\trunk\trac\ticket\tests\notification.py"", line 369, in test_from_author ticket.save_changes('noemail', 'More changes') File ""c:\Trac\repos\trunk\trac\ticket\model.py"", line 387, in save_changes old_db_values[name], db_values.get(name, ''))) File ""c:\Trac\repos\trunk\trac\db\util.py"", line 121, in execute cursor.execute(query, params) File ""c:\Trac\repos\trunk\trac\db\util.py"", line 54, in execute r = self.cursor.execute(sql_escape_percent(sql), args) File ""c:\Trac\repos\trunk\trac\db\sqlite_backend.py"", line 78, in execute result = PyFormatCursor.execute(self, *args) File ""c:\Trac\repos\trunk\trac\db\sqlite_backend.py"", line 56, in execute args or []) File ""c:\Trac\repos\trunk\trac\db\sqlite_backend.py"", line 48, in _rollback_on_error return function(self, *args, **kwargs) IntegrityError: columns ticket, time, field are not unique ---------------------------------------------------------------------- Ran 1212 tests in 13.759s FAILED (errors=1) }}} Twice in a row... also on 1.0-stable, then not anymore: I could do 10 runs without any errors. Wonder if it's a timing issue or something like that. The errors all happened with Python 2.7 but I don't think this has anything to do with it. Looking at the code, I find a succession of 4 `save_changes` calls, without much done in between. It might simply be that the 3rd `save_changes` (line 369) happens within the same microsecond(?) than the 2nd `save_changes` (line 361). This raises the interesting question if we should try to fix this for the tests only or if it would be useful to introduce a small delay in general for the `save_changes` so that this API becomes ""timing"" safe. For example, here's a very simple way to reproduce this error: {{{#!diff Index: trac/ticket/tests/model.py =================================================================== --- trac/ticket/tests/model.py (revision 12049) +++ trac/ticket/tests/model.py (working copy) @@ -110,6 +110,8 @@ ticket2 = self._create_a_ticket() ticket2.insert() ticket2['summary'] = 'Bar' + ticket2['foo'] = 'New value 0' + ticket2.save_changes('santa', 'this is my comment 0') ticket2['foo'] = 'New value' ticket2.save_changes('santa', 'this is my comment') return ticket2 }}} But ""fixing"" this is not straightforward, as experimenting shows that it's not obvious how to pick the appropriate value for the delay. On Windows, adding a call to `time.sleep(0.001)` did the trick, but 0.0001 didn't. I wonder if 0.001 would be good enough for all platforms and versions of Python. Then of course, using ""time"" as part of the key was also not the best idea we ever had...",Christian Boos 11452,Implement a set_field workflow action,ticket system,,next-major-releases,enhancement,normal,,new,2014-01-21T08:13:21+01:00,2015-07-28T10:01:15+02:00,"As mentioned on the [https://groups.google.com/d/msg/trac-users/lxDpEoiF8ws/VvQXnM0YmNMJ mailing list], it would be nice to have a `set_field` action that would couple a specified field to a workflow action in the same way that `set_owner` and `set_resolution` couple the owner and resolution fields to the workflow action. ",Ryan J Ollos 11633,Allow CommitTicketReferenceMacro to be used in tickets that aren't referenced in the changeset message,ticket system,,next-major-releases,enhancement,normal,,new,2014-05-31T19:12:08+02:00,2016-05-10T01:10:22+02:00,"It was discussed in gdiscussion:trac-users:sCVEU-z8y_A that it would be useful to allow the !CommitTicketReferenceMacro to be used from tickets that the changeset does not reference. Currently the message //The changeset message doesn't reference this ticket// is displayed for that use case. TODO: Document on CommitTicketUpdater page.",Ryan J Ollos 11637,Hide versions and components,ticket system,,next-major-releases,enhancement,normal,,new,2014-06-02T07:43:02+02:00,2019-12-05T03:55:09+01:00,"Closed milestones are only visible on the ticket form for users that possess `TICKET_ADMIN`. However, all Versions and Components are visible for all users, and the only way to hide them is to delete them. These lists can grown very long, and it would be nice to narrow the list that is seen from the ticket form, while keeping the entries on the Query form.",Ryan J Ollos 11702,Add a macro for listing ticket Components,ticket system,,next-major-releases,enhancement,normal,,new,2014-08-03T08:23:47+02:00,2022-11-02T17:52:58+01:00,"As discussed in comment:9:ticket:1233, it would be nice to have a macro for listing ticket system //Components//. comment:25:ticket:1233 suggests having a link to the query page from an //open tickets// column generated by the macro. The `TicketQuery` macro might be the most similar in term of existing macros, given its output //format//s that we might want to pattern after. Macros for //Milestones//, //Versions// and //Ticket enums// might follow after this one. A macro for listing ticket enums could be used on the TracTicketTriage#StatusandResolution page. The macro would be useful on the TracTicketTriage, where we currently do not list the components. Addition of this macro would deprecate [th:ComponentsProcessorMacro].",Ryan J Ollos 11879,Prevent ticket workflow hints from wrapping,ticket system,,next-major-releases,enhancement,normal,,new,2014-12-12T20:46:30+01:00,2015-03-02T22:27:22+01:00,"It would be nice to prevent the text wrapping in the workflow hint that is seen even with the default workflow. One option would be to prevent line wrapping and truncate overflow with ellipsis. The entire hint could be shown in the `title` of the `span`. [[Image(20141212T104313.png,100%)]]",Ryan J Ollos 11939,Workflow graph should account for user/group permissions,ticket system,,next-major-releases,defect,normal,,new,2015-01-27T09:11:12+01:00,2017-05-18T18:12:42+02:00,"The workflow actions have a [TracWorkflow#BasicTicketWorkflowCustomization permissions] attribute. Workflows can be configured such that different users will be configured with different actions. It would be useful to be able to visualize the workflow for a particular user or group using the [WikiMacros#Workflow-macro WorkflowMacro]. The !WorkflowMacro could be modified to accept a `username_or_group` argument. In the ticket workflow dialog the workflow for that user could be shown in a popover. Alternatively, it might be more useful to show all the workflow transitions but make it clear which transitions the current user is allowed to initiate.",Ryan J Ollos 11959,"Add custom fields to ""Group results by"" drop down in Custom Query page.",ticket system,1.0.1,next-major-releases,enhancement,normal,,new,2015-02-12T19:21:21+01:00,2015-08-09T05:33:28+02:00,"Currently, the ""Group results by"" drop down in the ""Custom Query"" page only includes standard fields. No custom ticket fields appear there. It would be very useful to include custom fields there. ",anonymous 12077,Ticket workflow should support negated permissions,ticket system,,next-major-releases,enhancement,normal,,new,2015-05-17T01:38:13+02:00,2015-07-28T22:46:02+02:00,"This would support the user case of overlapping workflow actions in which it is redundant to show both actions to a user that has the higher permission. For example, consider a case in which any user with `TICKET_MODIFY` can reopen a ticket, but only a user with `TICKET_ADMIN` can reopen and change the owner of a ticket. The user with `TICKET_ADMIN` would see both the //reopen// and //reopen_and_assign// actions, which is redundant. {{{#!ini reopen.permissions = TICKET_MODIFY, !TICKET_ADMIN reopen_and_assign.permissions = TICKET_ADMIN }}}",Ryan J Ollos 12162,Edit comment should be AJAX or standalone edit screen,ticket system,,next-major-releases,enhancement,normal,,new,2015-08-09T12:06:55+02:00,2019-09-06T19:51:32+02:00,"As of today's trunk, editing a comment means the request still loads all the other comments, which on a big ticket is massively slow. I have yet to feel I need to take a look at other comments while editing my target. AJAX would be preferred, it's cleraly the fastest way to do it, but perhaps an incremental improvement could be achived much quicker by just patching out the other comments from the edit page load. ",lkraav 12485,Add an ITicketCommentProvider interface,ticket system,,next-major-releases,enhancement,normal,,new,2016-05-21T01:31:23+02:00,2018-02-26T13:10:13+01:00,"The design of the CommitTicketUpdater makes it difficult to retroactively add changeset comments (#11478). !CommitTicketUpdater comments added retroactively are not likely to be in the correct chronological order. It would be difficult to remove !CommitTicketUpdater comments if it's later decided to use a plugin such as [th:TracTicketChangelogPlugin] instead of having the changeset comments inline in the ticket changelog. The repository links are no longer correct if the repository name is changed (although this is generally true for TracLinks to the repository). I've also used the [https://wiki.jenkins-ci.org/display/JENKINS/Trac+Publisher+Plugin Jenkins Trac Publisher Plugin] which has similar issues. I've considered another approach. * Add an `ITicketCommentProvider` interface, that returns a comment along with a timestamp and possibly some other metadata. The ticket changelog would be created from data provided by `ITicketCommentProvider` implementations. * One of the `ITicketCommentProvider` methods could be `get_comment_filter`, so that it would be possible to have a filter such as //Show changesets// or //Show build results//. * The full history of a `ITicketCommentProvider` source would be available upon activating the plugin, and the comments would have the correct chronological ordering. * !CommitTicketUpdater would create a table associating tickets with changeset. As an aside, the table would also be useful for th:#12621. * !CommitTicketUpdater would provide comments through an implementation of `ITicketCommentProvider`. One difficult aspect might be, on activating the plugin it might be desired to remove all previous instances of comments containing `CommitTicketReferenceMacro` instances. This could be done in an upgrade script, or through a script provided in `contrib`.",Ryan J Ollos 12854,"""rows"" can be used as custom field but rows=... condition in query doesn't work",ticket system,,next-major-releases,defect,normal,,new,2017-06-27T05:43:08+02:00,2019-09-06T19:51:32+02:00,"Ticket with //rows// field can be created like this but query:status!=closed&rows=42 ignores `rows=42` condition. {{{#!ini [ticket-custom] rows = text }}} Because `rows` parameters is used for full rows feature in ticket query. See also wiki:TracQuery#Fullrows. I think we should add `'rows'` to `TicketSystem.reserved_field_names` because field named `rows` might be rarely used.",Jun Omae 10232,Validating Ticket accounts for new or removed fields?,ticket system,0.11.5,next-stable-1.6.x,defect,normal,,new,2011-06-23T16:33:44+02:00,2023-09-23T22:33:10+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-stable-1.6.x,defect,normal,,new,2011-11-15T16:50:37+01:00,2023-09-23T22:33:10+02: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@… 11125,Truncate very long text in the ticket properties dialog,ticket system,,next-stable-1.6.x,enhancement,normal,,new,2013-03-19T23:17:09+01:00,2023-09-23T22:33:10+02: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 11530,Ticket default_description cannot include new lines,ticket system,,next-stable-1.6.x,enhancement,normal,,new,2014-03-10T15:14:04+01:00,2023-09-23T22:33:10+02:00,"Two issues were discussed on the [https://groups.google.com/d/msg/trac-users/lWB2c3U3TtM/IpK3ziT3zPcJ mailing list]: 1. It should be documented that lines 2:end need to be indented with whitespace to have a multi-line ticket description. For example, {{{#!ini [ticket] default_description = line1 line2 line3 line4 }}} This would be applicable to any `textarea`. Description is currently the only one in `[ticket]` section (TracIni#ticket-section), but we may also need to consider the `value` parameter of `textarea` custom fields (TracTicketsCustomFields#AvailableFieldTypesandOptions). 2. Empty lines can't be included in the `[ticket] default_description` because `ConfigParser` in Python 2.x does not appear to support empty lines. The empty lines are stripped out. We'll need a workaround such as specifying empty lines with a single `\` character, and then stripping out the character before rendering an empty line in the ticket description.",Ryan J Ollos 11612,ability to set and retain preferred comment order,ticket system,1.0.1,next-stable-1.6.x,defect,normal,,new,2014-05-14T04:00:09+02:00,2023-09-23T22:33:10+02:00,"r10989 added the OldestFirst/NewestFirst/Threaded option of viewing comments, which I generally like. However if I want something other than the default behavior, there does not seem to be a way to save my preference: I need to keep changing it on every ticket. It would be nice to specify my default-comment-sort-order in ""Preferences"". Also, the ticket-comment-order CHANGES automatically when I add a comment or reply-to a comment. If I select ""oldest first"" then reply to a comment, it auto-changes to ""newest first"". Is this intentional? I'm on Windows 7. I typically use Firefox (v29); but verified the same behavior in Chrome (v34) and Internet Explorer (v10) Trac 1.0.1 using standalone 'tracd' ; Python 2.5.4 on Windows 2008 R2",jeremy.j.dunn@… 11714,Log unknown attributes in ticket workflow,ticket system,,next-stable-1.6.x,enhancement,normal,,new,2014-08-11T19:27:48+02:00,2023-09-23T22:33:10+02:00,"It would be useful to either log a warning or raise a `ConfigurationError` when an attribute in the `[ticket-workflow]` section is unknown. For example: {{{#!ini [ticket-workflow] resolve.permission = TICKET_MODIFY }}} where `permission` is used rather than `permissions`, should result in a warning such as: {{{ 10:20:50 AM Trac[default_workflow] WARNING: Unknown attribute 'permission' in [ticket-workflow] section of trac.ini: resolve.permission = TICKET_MODIFY }}} More extensive changes are planned, but a starting point is log:rjollos.git:t11714.",Ryan J Ollos 12123,progress says 100% but it's not finished!,ticket system,1.0.4,next-stable-1.6.x,defect,normal,,new,2015-07-16T10:41:49+02:00,2023-09-23T22:33:10+02:00,"If target value is not equal to current value, it should never say 100%! [[Image(wrong.PNG)]]",anonymous 12449,Batch modify should block tickets when selecting unavailable action for the tickets,ticket system,,next-stable-1.6.x,defect,normal,,new,2016-04-10T20:03:36+02:00,2023-09-23T22:33:10+02:00,"When `[ticket-workflow]` has the following actions and both `reopened` and `closed` tickets are shown in custom query, both `resolve` and `reopen` actions are available in batch modify form. {{{ resolve = new,assigned,accepted,reopened -> closed resolve.permissions = TICKET_MODIFY resolve.operations = set_resolution reopen = closed -> reopened reopen.permissions = TICKET_CREATE reopen.operations = del_resolution }}} Then, if a user checks `reopened` and `closed` tickets and submits with `resolve` action, the `resolve` action wouldn't be applied to the `closed` tickets. The behavior is right but just confuse the users. I think we should block submitting batch modify form when selecting unavailable actions for the tickets. Example: it seems that //resolve// action is available for #2 in query:id=2|12449 but #2 has been resolved.",Jun Omae 12458,"TypeError: coercing to Unicode: need string or buffer, NoneType found",ticket system,1.0.10,next-stable-1.6.x,defect,normal,,new,2016-04-18T17:01:08+02:00,2023-09-23T22:33:10+02:00,"It seems that this issue occurs when timeline view shows th:#12742 which has blank summary. ==== How to Reproduce ==== While doing a GET operation on `/timeline`, Trac issued an internal error. Request parameters: {{{ {} }}} User agent: `Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:45.0) Gecko/20100101 Firefox/45.0` ==== System Information ==== || '''`Trac`''' || `1.0.10` || || '''`Babel`''' || `2.1.1` || || '''`dnspython`''' || `1.12.0` || || '''`Docutils`''' || `0.12` || || '''`FullBlog`''' || `0.1.5` || || '''`Genshi`''' || `0.6 (without speedups)` || || '''`httplib2`''' || `0.9.2` || || '''`mod_wsgi`''' || `4.3.0 (WSGIProcessGroup /srv/trac-hacks.org WSGIApplicationGroup %{GLOBAL})` || || '''`Pillow`''' || `3.0.0` || || '''`psycopg2`''' || `2.6.1` || || '''`Pygments`''' || `2.1` || || '''`Python`''' || `2.7.9 (default, Mar 1 2015, 13:01:26) ` [[br]] `[GCC 4.9.2]` || || '''`python-oauth2`''' || `1.9.0.post1` || || '''`pytz`''' || `2015.7` || || '''`RPC`''' || `1.1.5` || || '''`setuptools`''' || `20.2.2` || || '''`SpamBayes`''' || `1.1b2` || || '''`Subversion`''' || `1.8.10 (r1615264)` || || '''`jQuery`''' || `1.7.2` || || '''`jQuery UI`''' || `1.8.21` || || '''`jQuery Timepicker`''' || `1.0.1` || ==== Enabled Plugins ==== || '''`BlogDraftPlugin`''' || `N/A` || || '''`ChangeLogMacro`''' || `0.4.dev0` || || '''`EmailProcessor`''' || `r10962 ` || || '''`FootNoteMacro`''' || `1.5` || || '''`SvnAuthzAdminPlugin`''' || `1.0.dev0` || || '''`TracAccountManager`''' || `0.5.dev0` || || '''`TracAcronyms`''' || `0.2` || || '''`TracAutoWikify`''' || `0.2` || || '''`TracExtractUrl`''' || `0.3` || || '''`TracFullBlogPlugin`''' || `0.1.5` || || '''`TracHacks`''' || `3.0.1.dev0` || || '''`TracIncludeMacro`''' || `3.0.0.dev0` || || '''`TracIniAdminPanel`''' || `1.0.1` || || '''`TracNewsFlash`''' || `1.0.2` || || '''`TracPoll`''' || `0.3.0.dev0` || || '''`TracServerSideRedirectPlugin`''' || `1.0.0` || || '''`TracSpamFilter`''' || `1.0.9.dev0` || || '''`TracTags`''' || `0.9.dev0` || || '''`TracTocMacro`''' || `11.0.0.5` || || '''`TracVote`''' || `0.5.1.dev0` || || '''`TracWikiExtras`''' || `1.0.dev0` || || '''`TracXMLRPC`''' || `1.1.5` || ==== Python Traceback ==== {{{ Traceback (most recent call last): File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/web/main.py"", line 554, in _dispatch_request dispatcher.dispatch(req) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/web/main.py"", line 267, in dispatch iterable=chrome.use_chunked_encoding) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/web/chrome.py"", line 1114, in render_template encoding='utf-8') File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 183, in render return encode(generator, method=method, encoding=encoding, out=out) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 58, in encode for chunk in iterator: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 339, in __call__ for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 826, in __call__ for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 670, in __call__ for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 771, in __call__ for kind, data, pos in chain(stream, [(None, None, None)]): File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/output.py"", line 586, in __call__ for ev in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/web/chrome.py"", line 1309, in _generate for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 686, in _unmark for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 1145, in __call__ for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 714, in __call__ for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 682, in _mark for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 686, in _unmark for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 1081, in __call__ for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 117, in __iter__ event = self.stream.next() File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 714, in __call__ for mark, event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/filters/transform.py"", line 682, in _mark for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 605, in _include for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/markup.py"", line 378, in _match ctxt, start=idx + 1, **vars): File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/markup.py"", line 378, in _match ctxt, start=idx + 1, **vars): File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/markup.py"", line 327, in _match for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 545, in _flatten for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/path.py"", line 588, in _generate subevent = next() File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 605, in _include for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/markup.py"", line 316, in _strip event = next() File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 545, in _flatten for kind, data, pos in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/core.py"", line 288, in _ensure for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/path.py"", line 588, in _generate subevent = next() File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 605, in _include for event in stream: File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/markup.py"", line 316, in _strip event = next() File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 565, in _flatten result = _eval_expr(data, ctxt, vars) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/base.py"", line 277, in _eval_expr retval = expr.evaluate(ctxt) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/genshi/template/eval.py"", line 178, in evaluate return eval(self.code, _globals, {'__data__': data}) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/timeline/templates/timeline.html"", line 59, in ${format_time(event.date, 'short')} ${event.render('title', context)} File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/timeline/web_ui.py"", line 366, in provider.render_timeline_event(context, field, event) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/ticket/web_ui.py"", line 394, in render_timeline_event resolution, type) File ""/srv/trac-hacks.org/pve/lib/python2.7/site-packages/trac/ticket/api.py"", line 576, in format_summary summary = type + ': ' + summary TypeError: coercing to Unicode: need string or buffer, NoneType found }}}",Jun Omae 12714,TypeError is raised when passing value to time field via query string of /newticket,ticket system,,next-stable-1.6.x,defect,normal,,new,2017-03-06T06:43:21+01:00,2023-09-23T22:33:10+02:00,"`/newticket?timefield=0` crashes. `/newticket?timefield=now` and `/newticket?timefield=2017-03-06T12:34:56+00:00` work. However, `/newticket?timefield=2017-03-06T12:34:56Z` differs with `/newticket?timefield=2017-03-06T12:34:56+00:00`. {{{ 02:32:43 PM Trac[main] ERROR: Internal Server Error: , referrer None Traceback (most recent call last): File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/web/main.py"", line 613, in _dispatch_request dispatcher.dispatch(req) File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/web/main.py"", line 273, in dispatch iterable=chrome.use_chunked_encoding) File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/web/chrome.py"", line 1159, in render_template encoding='utf-8') ... File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/ticket/templates/ticket_box.html"", line 94, in ${pretty_dateinfo(value, field.format, dateonly=field.format != 'relative') if value else None} File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/timeline/web_ui.py"", line 283, in pretty_dateinfo absolute = user_time(req, format_datetime, date) File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/util/datefmt.py"", line 909, in user_time return func(*args, **kwargs) File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/util/datefmt.py"", line 312, in format_datetime return _format_datetime(t, format, tzinfo, locale, 'datetime') File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/util/datefmt.py"", line 268, in _format_datetime t = to_datetime(t, tzinfo or localtz) File ""/venv/trac/1.2/lib/python2.6/site-packages/trac/util/datefmt.py"", line 179, in to_datetime type(t)) TypeError: expecting datetime, int, long, float, or None; got }}}",Jun Omae 12743,Closed milestones always shown on batch modify form,ticket system,,next-stable-1.6.x,defect,normal,,new,2017-03-23T02:10:48+01:00,2023-09-23T22:33:10+02:00,"Closed milestones are only shown on the ticket page if the user has `TICKET_ADMIN`: [browser:tags/trac-1.2/trac/ticket/web_ui.py@:1582-1583#L1572]. However all milestones are shown on the batch modify form if the user has `TICKET_BATCH_MODIFY` and `MILESTONE_VIEW`, without having `TICKET_ADMIN`. Also, empty milestone select is shown if user doesn't have `MILESTONE_VIEW`, but field should probably just be hidden.",Ryan J Ollos 12809,Add set_owner_default attribute to specify default value of set_owner in ticket-workflow,ticket system,,next-stable-1.6.x,enhancement,normal,,new,2017-05-17T04:42:04+02:00,2023-09-23T22:33:10+02:00,"`set_owner` attribute in ticket-workflow currently uses `req.authname` for the default value. It would be useful to specify any username, //reporter//, //previous owner// or //component owner//. That is inspired by th:AdvancedTicketWorkflowPlugin. || //action//.set_owner_default = || Ticket's reporter || || //action//.set_owner_default = || Previous owner || || //action//.set_owner_default = || Component's owner || || //action//.set_owner_default = username || Any username || I implemented it via `IRequestFilter.post_process_request` with Trac 1.0.x.",Jun Omae 12909,Adding Ticket.select to bulk fetch records,ticket system,,next-stable-1.6.x,enhancement,normal,,new,2017-09-07T05:05:13+02:00,2023-09-23T22:33:10+02:00,"When retrieving ticket records in custom query, `QueryModule` executes `SELECT` query to `ticket_custom` table N times a `Ticket` instance. That behavior is slow.... I think we could reduce it to 1 time with `Ticket.select` to bulk fetch records. th:ExcelDownloadPlugin does bulk fetch tickets at th:source:exceldownloadplugin/0.12/tracexceldownload/ticket.py@16204#L57.",Jun Omae 9624,Project-specific ticket prefixes and numbering,ticket system,0.12,topic-multiproject,enhancement,normal,,new,2010-09-16T21:12:36+02:00,2020-02-10T13:36:30+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@… 10681,commit_updater.py create wrong comment number,ticket system,0.12.2,undecided,defect,normal,,new,2012-04-27T12:47:43+02:00,2023-05-30T09:31:09+02: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@… 11197,Batch Modification of Custom Text Area,ticket system,1.0,undecided,enhancement,normal,,new,2013-06-03T19:04:28+02:00,2021-02-24T07:54:32+01:00,"Text areas are excluded from batch modification (TracBatchModify#Excludedfields). There may be utility in allowing batch modification of custom text areas in a case like the following: There is a custom final resolution text area in a ticket. A group of tickets are resolved by updating registry settings. A `.reg` file updates all the required reg settings. The final resolution is running the reg file on systems to resolve the group of tickets. Batch modifying the text area would make this more streamlined instead of having to go to each individual ticket to enter the info into the text area.",beardedbrawler@… 11466,in-place modifying of ticket fields like in Apache Bloodhound Trac,ticket system,,undecided,enhancement,normal,,new,2014-01-29T13:27:49+01:00,2017-06-09T09:10:48+02:00,"If one creates a [https://bh-demo2.apache.org/newticket new Bloodhound demo site ticket], it can modified afterwards by editing the ticket fields in-place! This is what's missing. The recent Trac version just has a 'modify ticket' section at the bottom of the ticket, and it's quite confusing to have it shown at the top also. Please backport the in-place editor of Bloodhound for modifying ticket fields in the top area of a Trac ticket.",s-fr@… 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,2022-07-09T12:25:40+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@… 11644,Add an email domain blacklist/whitelist to prevent proprietary info leaks in notifications,ticket system,0.12.2,unscheduled,enhancement,major,,new,2014-06-12T15:01:55+02:00,2018-11-20T10:41:14+01:00,"For organizations potentially dealing with proprietary information within their tickets, it is necessary to be able to block notification emails outside designated domains. Otherwise a user could inadvertently (or not) include a Cc to an email address that would leak proprietary information to non-need-to-know persons. I tried using the `admit_domains` attribute in the trac.ini `[notifications]` section to no avail. rjollos responded to me in gdiscussion:trac-users:7NJDOpvmTCE that this doesn't appear to be the intent of the `admit_domains` attribute and suggested submitting this for possible consideration as a future enhancement.",jeffrey.yoder@… 6820,change display for duplicate tickets,ticket system,,unscheduled,enhancement,minor,,new,2008-02-12T23:54:26+01:00,2015-05-26T20:55:39+02: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@… 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 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,,new,2004-11-13T22:11:29+01:00,2017-05-17T01:18:25+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 2775,Automatic matching of similar issues,ticket system,0.9.4,unscheduled,enhancement,normal,,new,2006-02-17T11:07:42+01:00,2015-05-26T20:55:39+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@… 3003,milestone could be a ticket,ticket system,0.9.4,unscheduled,enhancement,normal,,new,2006-04-09T09:31:51+02:00,2015-05-26T20:55:39+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,,new,2006-09-25T23:42:20+02:00,2015-05-26T20:55:39+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,,new,2006-11-15T14:00:38+01:00,2015-05-26T20:55: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@… 5378,"ajax bandbox for input of milestone, component, assign to, and cc",ticket system,,unscheduled,enhancement,normal,,new,2007-05-26T14:01:52+02:00,2015-05-26T20:55:39+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,,new,2007-12-23T02:02:06+01:00,2017-05-17T00:53:34+02: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 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@… 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 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,2022-11-08T12:06:28+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 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@… 9289,Permissions for custom ticket fields,ticket system,0.11.4,unscheduled,enhancement,normal,,new,2010-05-04T12:17:24+02:00,2017-02-05T08:55:12+01: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,2014-10-13T23:46:13+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,2015-06-11T20:58:31+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@… 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@… 9930,Allow configuration of ticket query cache time,ticket system,0.12.1,unscheduled,enhancement,normal,,new,2010-12-15T11:36:16+01:00,2021-12-25T01:55:18+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 11321,browser doesn't highlite the last opened ticket,ticket system,,unscheduled,defect,normal,,new,2013-10-07T14:52:09+02:00,2013-10-07T20:07:05+02:00,"go to an ticket overview list, open a ticket, now go back (with the BROWSER back) to that overview, expected: => it is clear to see which ticket was last opened actual: => no idea which ticket was opened",anonymous 11424,Remove `req` from ITicketActionController method signatures,ticket system,,unscheduled,enhancement,normal,,new,2014-01-01T19:43:22+01:00,2021-06-01T00:35:16+02:00,"Currently all methods of the `ITicketActionController` interface require a `req` request parameter. This couples the `ITicketActionController` system tightly with web requests, and makes it very difficult to use workflow components at all in contexts other than a web request where the requesting user is directly viewing or acting on a ticket. This is because a `Request` object is difficult to instantiate directly (needs an environ and start_response); has an indeterminate interface (environ keys, request callbacks, etc); and must be capable of handling exceptional situations like `req.send` and `req.redirect`. If this coupling were looser, it would become much easier to use workflow in situations like: * workflow-aware actions triggered by commit messages (#10755) * workflow-aware actions in `ITicketChangeListener` components that subscribe to ticket_change events, where a `req` is not available * directly through any Python code that has a Trac environment, a ticket, and a (real or simulated) initiator for a workflow action I looked through the code of the following `ITicketActionController` implementations: * `trac.ticket.default_workflow` * th:AdvancedTicketWorkflowPlugin * th:WorkflowNotificationPlugin * th:MultipleWorkflowPlugin * th:TypedTicketWorkflowPlugin * th:TestManagerForTracPlugin / th:TracGenericWorkflowPlugin As far as I can see, the only request properties that are ever accessed in any of these implementations are `req.perm`, `req.args` and `req.authname`. There are only two exceptions, neither of which seems critical. (One is discussed below; the other is a hack in my own th:WorkflowNotificationPlugin which I'd prefer to clean up anyway.) So, I'm proposing to replacing the `req` argument in `ITicketActionController` method signatures with individual arguments `perm` (a Permission object), `args` (a dict), and `author` (a string). An illustration is provided in the attached patch. Unlike a Request object, these three parameters are trivial to construct from any calling context and to instantiate directly. Aside from backwards compatibility concerns, the only potential problem I see, based on the documented interfaces and their implementations in the wild, is that it's recommended to use `trac.web.chrome.add_warning(req, ...)` within a component's `get_ticket_changes` method if `args['preview']` is set and if the component will have any side effects in `apply_action_side_effects`. In practice, I can only find one use of this recommendation, in th:AdvancedTicketWorkflowPlugin's `TicketWorkflowOpXRef` component. This could be solved by extending the `get_ticket_changes` method with an optional `add_warning` callback/accumulator (which could be set to `lambda *x: chrome.add_warning(req, *x)` in web contexts, or e.g. a logging.warn call in other contexts) or by extending the interface with a `get_ticket_change_warnings` method.",ethan.jucovy@… 11477,Extend ITicketManipulator (or similar) - Filter Comments,ticket system,1.0.1,unscheduled,enhancement,normal,,new,2014-02-06T21:50:03+01:00,2014-03-09T16:23:41+01:00,"Example: Version 1.0.1 code in ticket/web_ui.py {{{#!python def _get_comment_history(self, req, ticket, cnum): history = [] for version, date, author, comment in ticket.get_comment_history(cnum): history.append({ 'version': version, 'date': date, 'author': author, 'comment': _(""''Initial version''"") if version == 0 else '', 'value': comment, 'url': self._make_comment_url(req, ticket, cnum, version) }) return history }}} If ITicketManipulator in ticket/api.py contained a method like: {{{#!python def comment_filter(self, req, version, date, author, comment): """"""Validate if a comment can be displayed Must return a 4-tuple corresponding to version, date, author, comment The 4 may be empty or None to ""nullify display of the comment """""" }}} The code from above in web-ui.py could be rewritten as: {{{#!python def _get_comment_history(self, req, ticket, cnum): history = [] for version, date, author, comment in ticket.get_comment_history(cnum): for manipulator in self.ticket_manipulators: version, date, author, comment = manipulator.comment_filter(req, version, date, author, comment) if version or date or author or comment: # Only if the comment has not been fully ""nullified"" add it to the list to display history.append({ 'version': version, 'date': date, 'author': author, 'comment': _(""''Initial version''"") if version == 0 else '', 'value': comment, 'url': self._make_comment_url(req, ticket, cnum, version) }) return history }}} This allows filtering of comments by Plugins which can create set of rules (user, group, permission based, ...) The existing th:PrivateCommentPlugin is broken beyond 0.12 because it filters the Template Stream and needs to adapt to changes in the stream. The proposed modification allows filtering ""objects"" rather than content and therefore eases up the creation of a Comment Filtering Plugin.",anonymous 12907,Avoid duplicate references by commit_updater,ticket system,,,enhancement,normal,,new,2017-09-06T11:27:52+02:00,2017-09-10T05:38:20+02:00,"When creating new branches out of a git repository with commits with references to ticket, CommitTicketUpdater will happily add new, duplicate, comments. Attached patch for 1.0 adds two features along with their toggles : 1. detection of comments that already reference the changeset that is being ''added'', and skips the update in that case. So no new comment nor email notification; 1. and the disabling of email notifications when a changeset references to a closed ticket. The comment in the ticket **is** added however. Point number 2 is specially helpful for the case where an svn repository is migrated to git: even though it is nice to have the reference to the git commit, it's useless to spam people about ancient commits. ",Raphael Geissert 2616,Show ticket submission time in Change History,ticket system,0.9.3,next-major-releases,enhancement,minor,,new,2006-01-16T20:52:30+01:00,2015-05-26T20:50:57+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,,new,2006-09-16T02:04:54+02:00,2015-05-26T20:50:57+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,,new,2007-07-05T21:10:08+02:00,2015-05-26T20:50:57+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,2017-10-06T00:43:32+02: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 11493,Add config option to show changeset files in ticket's comment,ticket system,1.0-stable,next-major-releases,enhancement,minor,,new,2014-02-21T02:50:45+01:00,2017-09-09T00:45:38+02:00,"I want to confirm changeset files in comment related to the ticket. It's useful to find a particular file related to the ticket. I made a patch to do this. How does that sound? {{{ #!ini [ticket] commit_ticket_reference_show_files = true }}} [[Image(show-changeset-files-in-comment.png)]]",t2y 548,[Patch] Support for subcomponents,ticket system,devel,next-major-releases,enhancement,normal,,new,2004-06-15T04:44:22+02:00,2015-12-19T16:59:28+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,,new,2005-04-03T13:22:08+02:00,2023-05-04T02:49:53+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,,new,2005-12-09T16:46:10+01:00,2015-05-26T20:50:57+02: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,,new,2005-12-16T19:28:33+01:00,2015-05-26T20:50:57+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,,new,2006-05-15T16:53:34+02:00,2015-05-26T20:50:57+02: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,,new,2006-06-13T00:27:35+02:00,2015-05-26T20:50:57+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,,new,2006-12-11T16:36:37+01:00,2015-05-26T20:50:57+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@… 8135,"[PATCH] Prev, Query, Next links at bottom of ticket page",ticket system,0.13dev,next-major-releases,enhancement,normal,,new,2009-03-17T19:27:21+01:00,2015-05-26T20:50:57+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@… 8314,Dynamic Default Values,ticket system,0.11-stable,next-major-releases,enhancement,normal,,new,2009-05-22T22:30:53+02:00,2015-10-13T22:35:38+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,[PATCH] 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,2015-12-19T17:03:38+01: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 13223,"""All Tickets Reported by Me"" should mention if a ticket is open or closed",ticket system,,next-major-releases,enhancement,trivial,,new,2019-11-17T19:57:48+01:00,2019-11-17T20:28:47+01:00,"""{9} All Tickets Reported by Me "" should mention if a ticket is open or closed. Powered by Trac 1.2.2 Quite important, vs. other items it mentions. Do add a column.",jidanni@… 7617,Various ticket fields don't like leading or trailing /,ticket system,0.11.1,next-stable-1.6.x,defect,minor,,new,2008-09-10T23:53:29+02:00,2023-09-23T22:33:10+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.",Remy Blank 12367,Error message with untranslated text when removing no selected items,ticket system,,next-stable-1.6.x,defect,minor,,new,2016-02-26T11:46:59+01:00,2023-09-23T22:33:10+02:00,"In /admin/ticket/priority page, `Remove selected items` with no selection shows the following message in French. {{{ Aucun priority sélectionné }}} `priority` text is untranslated.... {{{ 2016-02-26 19:27:04,572 Trac[main] WARNING: [192.168.11.11] HTTPInternalError: 500 Erreur Trac (Aucun priority sélectionné) }}} It would be good to add localized message for each enum of ticket. {{{#!diff diff --git a/trac/ticket/admin.py b/trac/ticket/admin.py index acd9d4ec5..ef410cbb7 100644 --- a/trac/ticket/admin.py +++ b/trac/ticket/admin.py @@ -599,6 +599,7 @@ class AbstractEnumAdminPanel(TicketAdminPanel): _type = 'unknown' _enum_cls = None + _no_item_selected = None # TicketAdminPanel methods @@ -651,7 +652,7 @@ class AbstractEnumAdminPanel(TicketAdminPanel): elif req.args.get('remove'): sel = req.args.get('sel') if not sel: - raise TracError(_(""No %s selected"") % self._type) + raise TracError(gettext(self._no_item_selected)) if not isinstance(sel, list): sel = [sel] with self.env.db_transaction: @@ -789,24 +790,28 @@ class PriorityAdminPanel(AbstractEnumAdminPanel): _type = 'priority' _enum_cls = model.Priority _label = (N_('Priority'), N_('Priorities')) + _no_item_selected = N_(""No priority selected"") class ResolutionAdminPanel(AbstractEnumAdminPanel): _type = 'resolution' _enum_cls = model.Resolution _label = (N_('Resolution'), N_('Resolutions')) + _no_item_selected = N_(""No resolution selected"") class SeverityAdminPanel(AbstractEnumAdminPanel): _type = 'severity' _enum_cls = model.Severity _label = (N_('Severity'), N_('Severities')) + _no_item_selected = N_(""No severity selected"") class TicketTypeAdminPanel(AbstractEnumAdminPanel): _type = 'type' _enum_cls = model.Type _label = (N_('Ticket Type'), N_('Ticket Types')) + _no_item_selected = N_(""No ticket type selected"") _command_type = 'ticket_type' _command_help = { }}}",Jun Omae 11759,TypeError raises when non existent comment of ticket is modified,ticket system,0.12-stable,next-stable-1.6.x,defect,normal,,new,2014-09-16T05:26:17+02:00,2023-09-23T22:33:10+02:00,"=== How to reproduce 1. Create new ticket and add comment to the ticket 2. Show ""Edit"" form for the comment 3. Remove the comment from another browser 4. Submit new comment The issue occurs with both 0.12-stable and 1.0-stable. {{{ 2014-09-16 12:15:40,582 Trac[main] ERROR: Internal Server Error: Traceback (most recent call last): File ""/src/tracdev/git/trac/web/main.py"", line 529, in _dispatch_request dispatcher.dispatch(req) File ""/src/tracdev/git/trac/web/main.py"", line 243, in dispatch resp = chosen_handler.process_request(req) File ""/src/tracdev/git/trac/ticket/web_ui.py"", line 174, in process_request return self._process_ticket_request(req) File ""/src/tracdev/git/trac/ticket/web_ui.py"", line 499, in _process_ticket_request ticket.modify_comment(change['date'], req.authname, comment) TypeError: unsubscriptable object }}}",Jun Omae 9457,Unsubmitted comments lost after attaching files,ticket system,0.11.6,unscheduled,enhancement,minor,,new,2010-06-23T18:04:02+02:00,2017-05-08T11:14:15+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,,new,2004-07-22T00:13:54+02:00,2015-05-26T20:55:39+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,,new,2007-08-13T15:27:47+02:00,2017-05-17T05:55:59+02:00,"I found myself wanting things like this in my `[ticket-workflow]`: {{{#!ini 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: {{{#!ini 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): {{{#!python if oldstates == ['*'] or status in oldstates: }}} ...becomes... {{{#!python 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,,new,2007-02-01T11:03:46+01:00,2017-01-26T11:38:44+01: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,,new,2004-12-17T15:46:06+01:00,2023-02-16T12:47:08+01: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.",Christian Boos 1514,Mantis conversion script,ticket system,,next-major-releases,enhancement,normal,,new,2005-05-06T20:17:11+02:00,2017-03-28T02:42:21+02:00,"A script to convert from Mantis(http://www.mantisbt.org/) to Trac would be super-cool! ",Paul Baranowski 3006,Want to be able to merge tickets,ticket system,none,next-major-releases,enhancement,normal,,new,2006-04-09T22:50:38+02:00,2015-05-26T20:50:57+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