Created
May 14, 2013 16:48
-
-
Save dflock/5577487 to your computer and use it in GitHub Desktop.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ticket | summary | component | version | milestone | type | severity | owner | status | created | _changetime | _description | _reporter | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 886 | Add support for Master tickets | ticket system | devel | next-major-releases | enhancement | major | nkantrowitz | reopened | 2004-11-05T12:44:10+01:00 | 2012-11-05T09:34:19+01:00 | It would be cool if you could create master tickets that other tickets refer to. Work could then be broken down into chunks (and assigned to different people), but the master ticket could only be closed when all referring tickets had been resolved. You could also have it so that referring tickets are excluded from the Roadmap ticket counts. | dmurphy25@… | |
| 10755 | CommitTicketUpdater does not allow user to define what state to jump to | ticket system | 0.12.3 | unscheduled | enhancement | major | new | 2012-07-02T22:27:07+02:00 | 2013-04-30T20:15:56+02:00 | The CommitTicketUpdater will only ever close a ticket. In general, the closed state is for when no more work is to be done, aka ''after'' QA has verified the fix. Trac should allow configuration of what state name the ticket will get updated to. | patrick.little@… | ||
| 9648 | [PATCH] Improve ticket fields with tooltips | ticket system | 0.12 | next-dev-1.1.x | enhancement | normal | rblank | new | 2010-09-27T11:29:42+02:00 | 2011-03-20T13:15:31+01:00 | I've created a patch that allows a Trac admin to specify tooltips for arbitrary ticket fields in Trac: [[Image(tooltip.png)]] This way the admin can explain a certain field in more detail (for example the difference between priority and severity) or provide information about the syntax used in that field. The tooltips appear in the following places: * the ticket box on the top of an existing ticket page (only on labels, not on values) * in the ticket history for changes values * the ticket input fields (on labels and input fields) All labels get a help cursor if a tooltip is available. Tooltips are specified in the `trac.ini` under the new section `[ticket-hints]`. Just assign the tooltip value to the name of the field. The user may also provide the same tooltip in multiple languages by appending the language code to the field name. Works for built-in fields as well as for custom fields (this patch is a generalization of #899). Example: {{{ [ticket-hints] reporter = The reporter of this ticket owner = The owner of this ticket blockedby = Tickets preventing this one from closing. Accepts comma delimited ticket number (without #) complexity = The estimated complexity involved in fixing this ticked. complexity_de = Die geschätzte Komplexität zur Lösung des Tickets }}} I've decided to use the `trac.ini` for localization as it would be too much overhead to create translation files for just some tooltips. | Sebastian Krysmanski <sebastian@…> | |
| 10735 | create a new ticket starting from an existing ticket comment | ticket system | 0.13dev | next-dev-1.1.x | enhancement | normal | cboos | new | 2012-06-23T20:29:01+02:00 | 2012-07-14T21:13:06+02:00 | The idea is much the same as the one for TicketClone, but instead of "cloning" the whole ticket in intent (as materialized by copying the ticket's description over), we would refine a specific ticket comment (by taking the ticket's comment as the new ticket description). This can be handy to avoid derailing a ticket into handling too many things at once, so when something is identified and that clearly needs a dedicated treatment, making a new ticket out of it is just a click away, and you'll have the new ticket starting off with the same fields as the "parent" ticket (yes, the same UI could lead to the creation of subtickets once we have that). Interestingly, the current source:trunk/tracopt/ticket/clone.py@11079 feature is implemented as an extension using Genshi (`ITemplateStreamFilter`). The present extension achieves a similar result but relies on JavaScript only. For now, only the "create from comment" is done via JavaScript (well, CoffeeScript actually, as this is better suited for embedding little HTML snippets), but the "clone ticket" action itself could be ported to js as well. This could even be generalized and provide a sound basis for #3255. === Related branches - repos:cboos.git:clone-from-comment | cboos | |
| 1962 | Due dates on tickets & email notification on overdue dates | ticket system | 0.8.4 | next-major-releases | enhancement | minor | jonas | new | 2005-08-25T04:25:51+02:00 | 2010-10-02T14:07:29+02:00 | It maye be there already but i cannot find it. One things as a software project manager that drives me crazy about track is the inability to add a due date to tickets. Prioritization is all well and good, and most certainly handy, but as part of the timeline / roadmap and the ticket inspector you REALLY need to have a due date on a ticket. It'd also be fantastic for Trac to notify the allocated user that the ticket is now overdue and bug them on a daily / configurable timeframe. As i said, correct me if this is already in trac (please tell me where!!) but if it's not, this is a really string feature request & i think a definite must have. Thanks - trac is awesome & we;'re really starting to use it now :) Regards Owen | owen@… | |
| 31 | Bug dependencies/relations feature | ticket system | devel | next-major-releases | enhancement | normal | cboos | new | 2004-01-29T05:53:39+01:00 | 2013-05-07T17:23:09+02:00 | A simple list of related bugs without logical/implicit constraints might be useful. It'd be nice to be able to relate bugs and issues in a useful manner. It would also thus allow for reports showing "a bug and all related bugs" in some fashion, which could be neat. This would also require checking for circular dependencies/relations. | daniel | |
| 918 | [patch] Custom Ticket Fields should support the multiple selection type | ticket system | devel | next-major-releases | enhancement | normal | ecarter | new | 2004-11-12T19:42:28+01:00 | 2012-07-12T10:56:20+02:00 | I propose an addition to the TracTicketsCustomFields. Currently, there is support for the simple selection field: {{{ <field>.type = select }}} I would like to have the {{{multi}}} type as well, for multiple selection fields. The usage in {{{trac.ini}}} for {{{multi}}} would be the same as it is for {{{select}}}. I implemented it in a crude way (see the accompanying patch). I'm not entirely pleased with the patch: * the support for query is partial (i.e. it won't work) * the display of the fields is not as neat as I would like A better solution would involve a change in the database: drop the unicity constraint on the {{{(id,name)}}} pair for the {{{ticket_custom}}} table. With that, the query support would be easier to add. | cboos@… | |
| 1084 | Percentage complete | ticket system | 0.8 | next-major-releases | enhancement | normal | cboos | new | 2004-12-26T16:53:05+01:00 | 2013-05-03T12:19:57+02:00 | Im using Trac in my projet to track bugs, but also to maintaint a list of tasks to do. One thing that would be great is the possibility to have a "percentage complete" field. This way the task can be updated to reflect the percentage complete. Right now the task can only be "0% complete" or "100% complete". I mean a task is either finished or unfinished, which is not always the case. | cerel | |
| 2463 | Mandatory fields in tickets | ticket system | 0.9.2 | next-major-releases | enhancement | normal | new | 2005-12-09T11:18:09+01:00 | 2012-02-10T23:02:16+01:00 | It would be great with ability to set some ticket fields as mandatory. These fields should be verified before allowing submit when creating a new ticket. | johan.regnell@… | ||
| 3370 | Custom query RSS feed differes from CSV, Tab files | ticket system | 0.9.4 | unscheduled | enhancement | normal | jonas | reopened | 2006-07-10T03:41:48+02:00 | 2010-12-13T16:37:48+01:00 | The RSS feed for a custom ticket query does not contain same fields as what the CSV and Tab Separated files do. The following important fields appear to be missing from the RSS feed: owner, type, priority, mileston and resolution. | tomek.piatek@… | |
| 11145 | wrap author information for ticket change comments in a span to make them stylable | ticket system | enhancement | minor | new | 2013-04-05T17:46:46+02:00 | 2013-04-05T17:46:46+02:00 | It would be nice to be able to to adjust the style of the author of a ticket change independently of the rest of the change header. Trac can make this easy to do by wrapping the author's identity in a `<span class="author">` tag. I think the following change does this without producing any bad side effects: {{{ diff --git a/trac/web/chrome.py b/trac/web/chrome.py index 3aed33d..4ec9f7d 100644 --- a/trac/web/chrome.py +++ b/trac/web/chrome.py @@ -1058,9 +1058,9 @@ class Chrome(Component): return sep.join(all_cc) def authorinfo(self, req, author, email_map=None): - return self.format_author(req, + return tag.span(self.format_author(req, email_map and '@' not in author and - email_map.get(author) or author) + email_map.get(author) or author), class="author") def get_email_map(self): """Get the email addresses of all known users.""" }}} this allows someone who wants the author names to show up (for example) in bold to add the following to their local css file: {{{ h3.change span.author { font-weight: bold; } }}} | dkg@… | ||||
| 10948 | [PATCH] Clone functionality should also be available for users with TICKET_CREATE permission | ticket system | 1.0 | 1.0.2 | enhancement | normal | cboos | assigned | 2012-11-12T09:20:15+01:00 | 2013-04-18T08:03:57+02:00 | As described in ticket [ticket:4686#comment:14], it would be nice to enable clone functionality also for "normal" users, which have `TICKET_CREATE` permission. As you could copy / clone a ticket manually with `TICKET_CREATE` permission (by copy-paste) it should be sufficient to check `TICKET_CREATE` permission in `clone.py`. As described in [ticket:10856#comment:6] it would also make more sense to put the clone-button on top of the properties table, since when you clone a ticket you clone '''all''' properties and not only the description. | franz.mayer@… | |
| 10984 | Hide the milestone select from the ticket form if the user doesn't have MILESTONE_VIEW | ticket system | 1.0 | 1.0.2 | enhancement | normal | new | 2012-12-15T03:58:28+01:00 | 2013-04-12T10:45:54+02:00 | If the user doesn't have `MILESTONE_VIEW` the milestone select is shown with no options. It might as well be hidden and not clutter up the ticket form. Hiding it also exposes less information because the user without `MILESTONE_VIEW` doesn't know whether there are any milestones defined. After the patch, the behavior is the same whether there are milestones defined but the user doesn't have `MILESTONE_VIEW` or there are no milestones defined. In both cases there are no mentions of milestone on the ticket form. | Ryan J Ollos <ryan.j.ollos@…> | ||
| 11100 | tracopt.ticket.deleter Genshi stream transformer may not work with themes | ticket system | 1.0-stable | 1.0.2 | enhancement | normal | new | 2013-03-04T06:17:23+01:00 | 2013-03-04T09:03:24+01:00 | The XPath expression relies on an `h3` being present, but a theme may want to change this to, for example, an `h5`. Would there be any harm in the following change, since the `id` elements must be unique anyway: {{{ #!diff diff --git a/tracopt/ticket/deleter.py b/tracopt/ticket/deleter.py index 75b93fa..75b1724 100644 --- a/tracopt/ticket/deleter.py +++ b/tracopt/ticket/deleter.py @@ -95,7 +95,7 @@ class TicketDeleter(Component): buffer = StreamBuffer() return stream | Transformer('//div[@class="description"]' - '/h3[@id="comment:description"]') \ + '/*[@id="comment:description"]') \ .after(delete_ticket).end() \ .select('//div[starts-with(@class,"change")]/@id') \ .copy(buffer).end() \ }}} This would also seem to be more robust against future changes to the Trac ticket template. | Ryan J Ollos <ryan.j.ollos@…> | ||
| 1329 | Ticket Search should (optionally) search only non-closed tickets | ticket system | 0.8.1 | next-dev-1.1.x | enhancement | major | rblank | new | 2005-03-21T09:19:37+01:00 | 2013-02-24T22:40:43+01:00 | One of the popular uses for searching (I believe) is to search the ticket database if an issue has already been filed. It would help if the search would only search tickets that have not been closed. This request is similar to Ticket #584 but I would like a way to filter the results so that only open tickets are displayed in the search result. It does not help much if you need to browse loads of resolved tickets to find the one open ticket you are looking for. ''fixed typos'' | Norbert Unterberg <nepo@…> | |
| 7979 | New tickets should be able to default owner to the current user | ticket system | 0.11.2.1 | next-dev-1.1.x | enhancement | normal | cboos | assigned | 2009-01-17T05:41:12+01:00 | 2013-04-25T11:06:06+02:00 | We use Trac very actively to manage our Dev tasks and not just as bug tracking system. We have much more tasks than defects or enhancements and in most of the cases Devs are filing tasks for themselves. It would be very useful if "default_owner" ticket setting could support value like "$USER" meaning that currently logged-in user is pre-selected in the owner field on the new ticket form. | lashchev@… | |
| 9510 | Action block stays visible when no actions available | ticket system | 0.11-stable | next-dev-1.1.x | defect | normal | new | 2010-07-20T12:20:58+02:00 | 2012-02-10T23:04:10+01:00 | The action block on the ticket page is visible (empty) even if there are no actions available. I've implemented a custom workflow for our trac site, removing the "leave" action for users that were having just that option (senseless). In that case though, the action block is still there, empty (senseless and ugly now :)). | fredck@… | ||
| 10040 | Support for integer/float custom fields | ticket system | next-dev-1.1.x | enhancement | normal | new | 2011-02-22T12:38:30+01:00 | 2011-03-08T17:33:30+01:00 | See http://article.gmane.org/gmane.comp.version-control.subversion.trac.devel/6561 for some discussion. We'd like to be able to mark some custom fields as "contains integer" or "contains floating number". This would then let us sort numerically, validate user input, add an aggregation/summing feature, and so on. We're not thinking of changing the ''storage'' type, nor, currently, the Python type that exists in the ticket.fields list. Instead, we just validate the user input and then later we can also attempt to convert the field value to the numeric type if we want to do sorting or summing. This can fix #3080, but walks in the wrong way for FieldRefactoring. | pipern | |||
| 10983 | PATCH (and RFC) for IQueryPreprocessor extension point | ticket system | 0.11.6 | next-dev-1.1.x | enhancement | normal | new | 2012-12-13T18:27:55+01:00 | 2013-04-17T18:58:54+02:00 | I'm working in 0.11.6 and I don't expect this to be adopted there but I'd like to get feedback on structure, naming, etc. so I can make this patch more acceptable before porting to an active version. In my PM work, I find it desirable to query tickets based in special ways like asking for all the tickets required by a ticket (and their predecessors, etc.) or all the descendants of a ticket. My plugin supports this with `goal=id|id|...` and `root=id|id|...` but every place I want this support, I have to modify plugin source to use my preprocessor or query wrapper. For example, I did this locally for Estimation Tools so I could do a workload chart of all the work in a ticket's predecessors. By adding an extension point to the core query system, all ticket queries can benefit from the PM logic. For example, you could do `[[TicketQuery(goal=self)]]` in a ticket to list all the ticket's predecessors. This patch defines and uses IQueryPreprocessor to accomplish this extensible query system. Then I implement this interface in my PM plugin: {{{ #!py class PMQueryHelper(Component): implements(IQueryPreprocessor) def __init__(self): self.pm = TracPM(self.env) # IQueryPreprocessor methods # Return the list of constraints handled by process_constraints() def custom_constraints(self): return ['root', 'goal', 'scheduled'] # Turn custom constraints (e.g., root) into standard contraints (e.g., id) # # @param req the Trac web request object, may be None # @param constraints hash indexed by contraint name (e.g., 'root', # 'id'). Each entry is a list of values. # # @return updated constraints. def process_constraints(self, req, constraints): # constraint values are lists, TracPM.preQuery() expects # pipe-delimited strings. options = {} for constraint in self.custom_constraints(): if constraint in constraints: options[constraint] = "|".join(constraints[constraint]) del constraints[constraint] ids = list(self.pm.preQuery(options, req)) if len(ids): if 'id' not in constraints: constraints['id'] = [] for tid in ids: if tid not in constraints['id']: constraints['id'].append(tid) return constraints }}} and the above `TicketQuery()` works. | Chris.Nelson@… | ||
| 221 | Creating TR for multiple components | ticket system | next-major-releases | enhancement | critical | cboos | new | 2004-04-02T02:41:40+02:00 | 2013-03-01T11:03:46+01:00 | Its sometimes necessary to fix a bug in both a branch release and the mainline trunk. It would be very useful to have a method by which a ticket can be assigned to multiple releases ---- Note: see rather #4298 for the association to multiple versions (or milestones). This ticket is focused on the association to multiple '''components''' (cf. comment:10) | banerjed@… | ||
| 4298 | tickets linked to multiple versions | ticket system | 0.10.2 | next-major-releases | enhancement | critical | jonas | new | 2006-11-30T09:00:23+01:00 | 2013-03-01T11:05:00+01:00 | As far as I understand, bug 2945 dealt only with description changes for requirement issues. I have a different scenario. Say I have a project with versions 1.0, 1.0.1, 1.0.2 and 1.1. a bug is found in 1.0. it is fixed in some way in 1.0.2 and in another way in 1.1 What I'd like to have is the ability to see all open bugs in 1.0 or 1.0.1 (the above bug included), in 1.0.2 (the above bug is fixed, and the comment describing the fix affects 1.0.2) and 1.1 (the bug is fixed in another way) I think it means only the ability to associate status changes with a version. maybe also priority and severity (in the above scenario, the fix in 1.0.2 may have been partial, not exactly closing the bug for the 1.0.x stream, but lowering the priority) | ittayd@… | |
| 1233 | Descriptions of Components | ticket system | 0.8 | next-major-releases | enhancement | major | rblank | new | 2005-02-28T15:52:00+01:00 | 2013-05-09T07:39:01+02:00 | One annoying problem we have with our existing bug-tracking system is that users often don't know what component to select for a ticket. They often end up choosing an inappropriate one. One could argue that better component names would minimise this, but I've often found users to be endlessly creative in their quest to misunderstand the (seemingly) obvious ;-) A nice feature of bugzilla is that the component selector label is a link to a page listing the components for the project, along with owner and description. (If you prefer the link could be a separate item, like a '?' icon.) (Currently I'm conducting a trial of trac, and I quite like it!) | Matthew Harrison | |
| 2464 | Conditional fields in tickets | ticket system | 0.9.2 | next-major-releases | enhancement | major | cboos | new | 2005-12-09T11:34:48+01:00 | 2012-11-14T21:31:19+01:00 | Not necessarily all possible fields should be presented to the user. There could be preconditions attached to fields, for checking if they're applicable at all and for checking if the current user can actually set/modify them. Then, as an advanced case, instead of being an all or nothing situation, the possible content of one field could be dependent on the ticket state: see #1299, #2752 and [#comment:13]. === Use cases === ==== Ability to have different ticket fields for different ticket types ==== ''(original one)'' When using quite different types of tickets (bug-report, requirement, etc), there is a need for different fields depending on the ticket type. This might add just the flexibility required for complying with existing development processes. Great feature in particular when support for master and child tickets is planned, trac could be more of a requirements management system beyond the issue database approach. See also duplicates: #4028, #4643 ==== Hide the ''Keywords:'' field ==== See #3281 ==== Hide some fields for new tickets ==== See #1580. This could be achieved quite simply by putting the ticket `id` in the condition. | johan.regnell@… | |
| 3580 | AssignTo Ideas | ticket system | devel | next-major-releases | enhancement | major | new | 2006-08-18T16:09:45+02:00 | 2011-03-17T00:16:39+01:00 | This is what I was thinking about the ''Assign To'' list. Please note that this will only work if you have a finite number of users you want to show in the ''Assign To'' list. 1. The `trac.ini` file will have a new option added. Maybe something like "`restrict_grouplist`". This group list will determine what users will be added to the ''Assign To'' list. 1. In the PERMISSION table, someone has to add the usernames associated to the group(s) that will be used to populate the ''Assign To'' list. 1. Modify the code accordingly. Just a thought... Feel free to comment. | shawn | ||
| 8637 | "Add to CC" for anonymous with TICKET_APPEND permissions | ticket system | 0.11.5 | next-major-releases | enhancement | major | new | 2009-09-04T16:25:46+02:00 | 2010-12-04T02:33:03+01:00 | Currently when `always_notify_updater` is set to `false` an commenter/updater has to put himself/herself to the CC list of a ticket to be notified about future changes. However, to do so the user is required to have `TICKET_MODIFY` permissions. If an administrator only want the users to be able to comment on tickets (i.e. only grants `TICKET_APPEND` permissions) the user has no way of being notified about future changes. So it would be nice to activate this checkbox even when the user only has `TICKET_APPEND` permissions. | Sebastian Krysmanski <sebastian@…> | ||
| 2045 | shortcut to "accept" a ticket when creating it, and enable the "accept" option for other statuses | ticket system | devel | next-major-releases | enhancement | minor | cboos | new | 2005-09-11T19:29:32+02:00 | 2010-07-20T14:48:23+02:00 | Long time ago, on the mailing list, I proposed a patch to immediately set the status of a newly created ticket to "assigned" if the reporter and the assignee are the same person. This saves one step, as the next logical step would be to "accept" the ticket that the reporter has just created for himself. Therefore I propose the patch once again, for discussion: {{{ #!diff Index: model.py =================================================================== --- model.py (revision 2202) +++ model.py (working copy) @@ -142,6 +142,11 @@ # Assume that no such component exists pass + # If the owner creates the ticket, status is directly 'assigned' + owner = self.values.get('owner') + if owner and owner == self.values.get('reporter'): + self['status'] = 'assigned' + # Insert ticket record std_fields = [f['name'] for f in self.fields if not f.get('custom') and f['name'] in self.values.keys()] }}} | cboos | |
| 3320 | Custom fields can't be hidden | ticket system | devel | next-major-releases | enhancement | minor | athomas | new | 2006-06-26T16:16:35+02:00 | 2008-07-04T17:27:18+02:00 | Though this is already fixed in the new workflow branch, it would be nice to fix this for 0.10. All that needs to be done is add to following [source:trunk/trac/ticket/api.py@3444#L161 here]: {{{ #!python 'skip': config.getbool(name + '.skip', False) }}} | coderanger@… | |
| 5211 | Ticket - Wiki Integration enhancement/suggestion | ticket system | next-major-releases | enhancement | minor | cboos | new | 2007-04-24T17:36:50+02:00 | 2010-09-07T17:44:35+02:00 | Supposing that one used CamelCase to name their components, and that one then created wiki pages for their components; how about having the 'Component' column of reports created by the ticket system contain clickable links for each component that has a wiki page created for it. Also perhaps, in the case that components do not have a page already created; those components might have a link to create the wiki page. Thanks, Cullen | Cullen Newsom <cullennewsom@…> | ||
| 6249 | Customized field labels for standard fields | ticket system | next-major-releases | enhancement | minor | jonas | new | 2007-10-26T14:56:12+02:00 | 2007-10-26T15:21:39+02:00 | I'd like to be able to easily modify the labels on standard fields. | anonymous | ||
| 9149 | Conf option for showing previous query instead of default query | ticket system | 0.12dev | next-major-releases | enhancement | minor | new | 2010-03-19T12:38:50+01:00 | 2010-06-23T17:53:27+02:00 | Trac stores query_href into session. It would be nice to have option for using that value as a default value. {{{ [query] default_query = ${session_query_href} }}} | anonymous | ||
| 9478 | Concurrent ticket modifications is still possible | ticket system | 0.12 | next-major-releases | defect | minor | new | 2010-07-02T14:02:03+02:00 | 2010-07-02T17:52:25+02:00 | Before saving a ticket modification, we try to detect if the page was not already modified by another user (r5449). However this check is not done within a single transaction, and therefore it can be ineffective if two changes happen concurrently. See ticket:9235#comment:10 for an example (or `comments:10` actually ;-) ). | cboos | ||
| 10027 | TicketQuery groups without translation | ticket system | 0.12.2 | next-major-releases | defect | minor | new | 2011-02-14T15:49:28+01:00 | 2011-02-25T11:11:46+01:00 | I'm using Trac 0.12.2 with German language. On my WikiStart page I have a TicketQuery with "order=milestone". The group title results in "test milestone Tickets:". Due to my language settings I would expect something like "test Meilenstein Tickets:" as the German word "Meilenstein" is associated with the English "Milestone". Without having it tested, I assume it's the same e.g. for component ("Komponente") and all these normally translated default fields. (see [source:/tags/trac-0.12.2/trac/ticket/query.py#L1338 here]) | the3illings@… | ||
| 10207 | Clicking 'Submit' or 'Modify Ticket' from comment edit is blocked by comment preview function | ticket system | 0.12-stable | next-major-releases | defect | minor | rblank | new | 2011-06-03T18:32:54+02:00 | 2012-06-17T13:35:46+02:00 | Here is the scenario: * I am adding a comment to a ticket by typing in the textarea (Firefox 4.0) * I finish typing my comment and am ready to submit, so use the mouse to click the '''Submit changes''' button * the wiki-preview of the comment is updated but the ticket is not updated - i.e. I am still in edit mode. * I have to click '''Submit changes''' again to update the ticket It took a few times of this happening before I realized that probably the "lost focus" handler that updates the preview was firing just before the button click, and was therefore preventing the submit from happening. The other note is that this is not 100% reproducible - sometimes the submit goes through, other times it does not. It seems like only the first time the wiki preview is updated the problem exhibits - after that it works as expected. {{{ Trac 0.12 CustomFieldAdmin 0.2.2 Docutils 0.6 Genshi 0.6 mod_python 3.3.1 pysqlite 2.3.2 Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] RPC 1.1.2-r0 setuptools 0.6c9 SQLite 3.3.4 Subversion 1.6.6 (r40053) jQuery: 1.4.2 }}} | txcraig@… | |
| 710 | Add basic time tracking | ticket system | devel | next-major-releases | enhancement | normal | new | 2004-08-23T12:28:38+02:00 | 2012-09-12T08:15:26+02:00 | I would like trac to have basic time reporting as a module. The (logged in) user should be able to add that he/she worked for X hrs with something and add a short description of what. This time report could refer to a ticket and/or a changeset. I am not familiar with the internals of trac, but I think that this could just be a new table in the DB and some basic templates/function to add and view data. | joel@… | ||
| 2662 | assign tickets to multiple users | ticket system | 0.9.3 | next-major-releases | enhancement | normal | jonas | reopened | 2006-01-25T13:36:02+01:00 | 2012-10-24T22:52:39+02:00 | It would be very nice, if I could assign a ticket to more than one user. I set the restrict owner-parameter to false and typed in two users. I tried with different syntax, but the trac system did not notice the ticket to belong to the them. Would be fine... | mala | |
| 2961 | custom comment fields | ticket system | 0.9.4 | next-major-releases | enhancement | normal | jonas | new | 2006-03-30T21:41:12+02:00 | 2012-07-25T22:19:45+02:00 | I'd like a function similar to TracTicketsCustom, but for comments. I'm looking to integrate time tracking into Trac to eliminate some double entry, but unlike all the folks at #710, I'd like my "hours spent" field to be on the comment, so we can track who is putting in the time when, and not just have one field on the ticket everyone keeps updating. | Ryan@… | |
| 3281 | make Keywords field optional | ticket system | 0.9.5 | next-major-releases | enhancement | normal | new | 2006-06-17T23:38:46+02:00 | 2011-12-27T08:46:16+01:00 | It is very annoying that the Keywords field takes up screen space even if it's not needed. I know that it has been requested by many people, but I'm sure that there are even more people who don't use it, at all. Please make it optional. Why is it not possible to make the Keywords field one of those [TracTicketsCustomFields]? | wkornew | ||
| 3749 | recent ticket-comments macro | ticket system | 0.9.6 | next-major-releases | enhancement | normal | cboos | new | 2006-09-18T23:14:26+02:00 | 2011-04-22T07:50:05+02:00 | I think it would be nice to have a page that lists recent ticket comments to see what tickets are being actively discussed. | Gary Wilson <gary.wilson@…> | |
| 4130 | Ticket Component Interface Fails to Properly Check for Existing Component | ticket system | 0.10 | next-major-releases | defect | normal | jonas | new | 2006-11-11T00:33:08+01:00 | 2008-02-11T14:42:35+01:00 | When using the ticket.model.Component class, it will raise a `TracError` if passed the name of a non-existent component on instantiation. If the component is instantiated with an existing component name, it will assert an error if one tries to call insert(). However, if one instantiates the object with out a name, and then sets the name and owner after the fact, and then calls insert(), no checking of duplicate rows is done. Possible borkage: {{{ #!python c = Component(env) c.name = 'component1' c.owner = 'sombody' c.insert() }}} The API should be modified to either raise a TracError in the case in question, and/or provide a method for discovering whether or not a Component exist. Personally, I think that the following would be desired behavior: {{{ #!python c = Component(env, 'new component') c.insert() }}} Where the insert() is a noop if the component already exists. The `exists` property could also reflect whether or not the Component instance references an existing component or not. {{{ #!python c = Component(env, 'new component') if not c.exists: c.insert() }}} I find this preferable to: {{{ #!python try: c = Component(env, 'new component') except TracError: c = Component(env) c.name = 'new component' c.insert() }}} | pacopablo | |
| 4266 | Provide a list of users a ticket can be assigned to | ticket system | 0.10.2 | next-major-releases | enhancement | normal | jonas | new | 2006-11-27T13:02:19+01:00 | 2013-02-07T01:05:00+01:00 | It would be nice if trac could provide the user with a list of people a ticket can be assigned to. What I would like to see is drop-down list with all users (or a list of all peoples tickets have been assigned to in the past) in the Assign to: field when I enter a new ticket. | dallmeier@… | |
| 4549 | [PATCH] Ticket std/custom fields improvements - sql based values, order by, labels, value evals, ... | ticket system | 0.10 | next-major-releases | enhancement | normal | jonas | new | 2007-01-16T14:05:36+01:00 | 2010-09-10T11:44:17+02:00 | Hi, First to say, I find Trac very useful and programmed nicely (appologies for my English). Revision 5 is trac 0.10. Ticket fields std/custom improvements: * field values (combo) filled with sql * customized order of fields * std fields - customized label/default values * values - evaluation of variables TRAC.INI with samples: {{{ std fields default_* - default values order_* - order by (not applicable for some fields - e.g. ticket title) label_* - labels custom fields req_who.options - sql filling the fields req_when.value = $(today) - variable evaluation *.order }}} I plan to implement following - but the question is when :( * obligatory/optional/hidden field definition in ini * init ticket callback - can change field definition (value, type, order ...) * save ticket callback - can check/reject/change field values * ticket initialization * add to ticket/ticket_change "status by user" (like unread ticket, ticket, ...) can be used also as internal mail ... instead of sending the mail mark ticket/ticket_change to be read by some users * customized home page for the user - will show number of unread tickets newly * ticket "factory" for periodical tickets - e.g. one ticket generated for every month It would be nice to have customized statuses, so in the future trac could be some kind of workflow system (add allowed state-transitions/persons). Each status could have extra fields, e.g. if status is "fixed" then field could be revision number. Hope this will be useful. Best regards from Croatia, Robert | trebor74hr@… | |
| 5031 | Queries ought to support less/great than for ordered values (i.e. priorities and severities) | ticket system | 0.10.2 | next-major-releases | enhancement | normal | new | 2007-03-27T10:48:40+02:00 | 2009-10-26T11:16:08+01:00 | I.e. expand the [is|is not] operator set a bit. | macke@… | ||
| 5425 | Make the state transition dependant on group membership in addition to the boiled down group permissions in workflows | ticket system | devel | next-major-releases | enhancement | normal | jonas | new | 2007-06-05T10:17:17+02:00 | 2010-06-10T21:07:31+02:00 | That would make it possible to only allow users that are members of the group user_group to perform the workflow action. {{{ disapprove = solved -> reopened disapprove.name = Disapprove Solution disapprove.permissions = user_group # instead of TICKET_APPEND disapprove.operations = del_owner }}} | jim@… | |
| 5979 | Add more option to filters with drop-downs in custom query | ticket system | devel | next-major-releases | enhancement | normal | jonas | new | 2007-09-05T17:08:14+02:00 | 2010-01-25T19:45:16+01:00 | Adding a "contains" option to filters with drop-downs in custom query would be really helpful. The hard part is that it would have to ignore the drop-down and use a text input field. It is really necessary for people overloading the Component field, due to the fact we don't have component/subcomponent capability. ie. How do you search for all of component "blob" when your choices are "blob: bit","blob: bot","blob: bat","thingie: subdodad"? | asloan12@… | |
| 5999 | From ticket to wiki : add links to ticket/comment metadata when appropriate | ticket system | next-major-releases | enhancement | normal | cboos | new | 2007-09-10T11:24:56+02:00 | 2010-06-24T17:54:01+02:00 | In a ticket, we have several metadata that relates to something existing in the Trac system: milestone, component, etc. It would be helpful to have these fields link to their actual wiki page (or to a template-based url, defined in the configuration file): * the milestone field would redirect to the milestone page, * the component would redirect to the component view in the milestone page, Plus, in case these would exist as well in the near future: * each keyword could redirect to a search page looking for every item with this keyword, * each person (reporter, owner, on cc list, anyone who adds to the ticket) could redirect to a user page summarizing done and pending work in the whole Trac. While not adding direct context to a ticket, it would make it easier to access data related to it, without a need for a manually typed search or several clicks. | romain.dalverny@… | ||
| 6154 | better formatted rss feed | ticket system | 0.10.4 | next-major-releases | enhancement | normal | jonas | new | 2007-10-09T01:18:19+02:00 | 2010-10-03T22:39:07+02:00 | would be nice to have more contents and details in the rss feed. The Bucktracker Bugdar has a nice layout for RSS Feeds see e.g. (with a rss reader) http://www.bluestatic.org/bugs/syndicate.php | markus.staab@… | |
| 6330 | 'Back to query' when no query has been used | ticket system | devel | next-major-releases | defect | normal | jonas | new | 2007-11-12T12:59:29+01:00 | 2010-09-10T17:28:30+02:00 | I'm not sure whether its a feature or a bug: When a ticket is entered in the search box with the quickjump syntax, the ticket page contains the usual "previous ticket","back to query" and "next ticket" links. The "back to query" link is quite unexpected, as no query has been used to reach the ticket page, and the default report ({6}) seems to come a bit out of the blue to me. I would have expected that in this case (no query, direct access to the ticket) the 'Back to query' link not to be shown, and that 'previous ticket' and 'next ticket' links lead to the immediate existing tickets, ''i.e.'' for ticket #''N'', 'previous ticket' jumps to ticket #''N,,-1,,'' and 'next ticket' jumps to ticket #''N,,+1,,'', whatever their status (closed or not) | eblot | |
| 6634 | ITicketManipulator.validate_ticket() return values should be able to include markup | ticket system | 0.11b1 | next-major-releases | enhancement | normal | new | 2008-01-11T08:16:10+01:00 | 2012-02-10T22:56:52+01:00 | Since the error messages returned from validate_ticket() by implementations of ITicketManipulator are displayed to the user, it would be good if plugins providing that interface could return some form of markup in the error message. For example, the error message: You can't make that change because you are not part of the security team. Might be better rendered as: You can't make that change because you are not part of [wiki:SecurityTeam the security team] But i can't find a way to do that in 0.11b1. asked about this on IRC, coderanger suggested: ''"it should probably be fixed to allow Markup() and genshi.builder elements"'' | Daniel Kahn Gillmor <dkg-debian.org@…> | ||
| 7176 | Workflow actions indistinguishable from user changes | ticket system | devel | next-major-releases | defect | normal | ecarter | new | 2008-04-30T03:17:34+02:00 | 2011-02-01T10:06:47+01:00 | - someone writes a workflow action that modifies a user-modifiable ticket field - user selects that action, and previews the change - user selects a different action - user previews or submits changes The changes made by the workflow action will still be present; they will not be reverted. Internally, the code does not differentiate between user changes and workflow changes across a preview. The correct behavior here, particularly in cases where the user modifies the same fields as the workflow, is open for debate. | ecarter | |
| 7196 | restrict ticket properties to add/edit only/... | ticket system | next-major-releases | enhancement | normal | cboos | reopened | 2008-05-05T10:16:39+02:00 | 2009-02-24T15:23:23+01:00 | would be nice to have the ability to define if a property should be readonly/disabled/not mentioned at all, if in ticket add-mode/edit-mode... so e.g. the milestone field could be set to edit-mode, so the creator is not able to choose the value for it... this is the intended behavior on t.e.o. also the priorty field should be set by a developer, so maybe also a restriction to some usertypes would be great.. such restriction would also make sense for other fields and also in other scenarios. this would improve the user-experience and help also the developer team, because of less misfilled tickets | Markus.Staab | ||
| 7419 | Custom ticket status: customised ordering of statuses | ticket system | 0.11-stable | next-major-releases | enhancement | normal | new | 2008-07-09T17:52:49+02:00 | 2012-11-23T16:07:44+01:00 | We have a large number of custom ticket statuses now, thanks to 0.11 - it would be nice if I could define a sort order in the config file (similar to how you can do so in a [TracIni#milestone-groups-section "[milestone-groups]"] section) so that when ordering tickets by status, they appear in my defined order. | trac+jon@… | ||
| 7438 | Restrict edit permission for ticket description to ticket owner | ticket system | 0.11-stable | next-major-releases | enhancement | normal | new | 2008-07-16T21:04:08+02:00 | 2011-03-30T10:07:09+02:00 | THis is similar to #1316. It would be very helpful if permissions to edit a ticket's description could be restricted to the owner. This allows the administrator(ahem) to be freed up from changing ticket descriptions all the time, while not giving all users in my developer group the TICKET_EDIT_DESCRIPTION permission. | john.williams@… | ||
| 7660 | Be able to search for commenters by name | ticket system | 0.11.1 | next-major-releases | enhancement | normal | new | 2008-09-23T00:57:03+02:00 | 2009-10-26T15:35:12+01:00 | Somewhat related/started by http://trac.edgewall.org/ticket/7581 On the Pidgin instance of Trac I would like to be able to search (via the query module) for tickets that have been commented by myself...so search for text such as: "...ago by bernmeister..." Or really, just search for "bernmeister". At the moment there are a lot of Pidgin tickets I've touched and I want to search across all tickets to tell me which ones I've touched that are still NEW (or PENDING or CLOSED or ...). BTW, Pidgin's Trac instance does NOT have ticket reports enabled. What say you (please)? | anonymous | ||
| 7850 | [patch] Update default_<enum> options in trac.ini when enum value is updated/deleted | ticket system | devel | next-major-releases | enhancement | normal | new | 2008-12-01T18:49:08+01:00 | 2009-03-26T21:25:03+01:00 | I had a user complained that he deleted a component, but that the component was still showing up as the default when creating new tickets. I explained that this is the expected behavior, since the default_component is still set to that component, causing it to be displayed. But he pointed it that it's somewhat user-hostile to keep a default_component setting for a component that no longer exists, and I'm inclined to agree. Likewise the default_ setting should be updated when an enum value is updated. | ebray | ||
| 7884 | Ticket should contain a field for the expected time to complete/fix it | ticket system | none | next-major-releases | enhancement | normal | reopened | 2008-12-12T18:26:14+01:00 | 2010-09-10T17:48:30+02:00 | This would give a number of benefits, and among them: * a (super)user that has the rights to change the priority of the tickets can rearrange them based on the time to handle them * a milestone could show an expected time to be completed as the sum of the time of each ticket | dusty@… | ||
| 8403 | Encourage users to select meaningful values for 'required' fields | ticket system | none | next-major-releases | enhancement | normal | new | 2009-06-19T23:14:06+02:00 | 2009-06-26T15:57:26+02:00 | When an enum field, in particular, is marked as 'required', the blank option is removed from the select element, and the first option is selected by default, if no other default value is set. The problem with this is that it often leads to users submitting tickets with those fields left in their default values. It doesn't force them to select a meaningful value. A decent workaround is to have a catchall (like 'general' for the Component field) as the default value for the field. But I've had use cases where we want to make sure the user has paid some attention to the field. The desired behavior here would be to have something like 'Select a Component...' as the first option. If this option is selected when the form is submitted, a warning would be displayed, and the ticket would not be saved. | ebray | ||
| 8670 | Ticket owner list should not depend on TICKET_MODIFY permission | ticket system | none | next-major-releases | enhancement | normal | new | 2009-09-15T00:11:24+02:00 | 2012-02-10T22:50:27+01:00 | It's nice to be able to use `restrict_owner` in the `[ticket]` section of trac.ini to yield a select box (dropdown) for the "Assign to" field. But the list contains everyone who has a profile and has TICKET_MODIFY privileges. It would be very, very nice to have a restrict_group option after it, which would allow me to define a group with a given privilege constellation (e.g. developers), and then only have their names appear as candidates. | fewayne@… | ||
| 8672 | Filter ticket queries by user groups | ticket system | none | next-major-releases | enhancement | normal | new | 2009-09-15T15:20:27+02:00 | 2013-04-01T22:53:13+02:00 | We had a need to filter the results of a TicketQuery by user groups (from the permission system) to keep query results from becoming overwhelming. The attached patch does this by expanding a 'username' like '@software' in the owner field of a query to all the users with that role. This is a very rough implementation for now (the group functionality should be provided by the permissions system and there should be a way to list groups on the Custom Query page) but I'm putting it up anyway in the hope that the idea is useful. We use this like {{{ [[TicketQuery(status=blocked,order=owner,owner=@software)]] }}} | joshua.hoke@… | ||
| 8778 | Permission that uniquely controls assignment of tickets to milestones | ticket system | 0.11.5 | next-major-releases | enhancement | normal | new | 2009-10-26T19:38:45+01:00 | 2012-07-05T23:02:52+02:00 | I have found that the `MILESTONE_VIEW` permission allows a user to change the milestone with which a ticket is associated. That is, it causes the milestone drop-down list to be populated with the milestones and allows the user to change which milestone a ticket is associated with. It seems incorrect for a `*VIEW` permission to grant a '''change''' action. Also, it seems desirable to allow a user to view milestones, but not change the milestone assignment for a particular ticket. In my situation, the configuration control board (lead software developers) are in charge of assigning tickets to milestones, and it would be better if all users with `MILESTONE_VIEW` permissions did not have this level of control. Therefore, it would be nice to have a separate permissions to control the assignment of tickets to milestones. This permission should be named either `TICKET_ASSIGN_MILESTONE` or `MILESTONE_ASSIGN_TICKET`. I suspect the former is a better fit for the permissions naming schema (See: TracDev/Proposals/EvenFinerGrainedPermissions). Note, this permission should be different than the `MILESTONE_MODIFY`, which controls modifying the description, due date, and other milestone data. | ryano@… | ||
| 8966 | reporter_restrict option | ticket system | next-major-releases | enhancement | normal | new | 2010-01-13T18:37:06+01:00 | 2010-06-26T13:37:42+02:00 | As for the owner (when owner_restrict = true), it would be nice to be able to select the value of the 'reporter' field from a dropdown list. This option should come along with a permission setting allowing only a given set of users to report tickets on 'behalf' of other users. Along the dropdown list, the free input field should remain (useful for anonymous/unregistered users). Multiple reporters might be allowed, however this would be redundant with Cc. Literature: Existing dropdown list for 'Owner': TracTickets#Assign-toasDrop-DownList Proposed fullname list (in addition to usernames): #3807 Proposed multiple owner feature: #918 | vincentb1981@… | |||
| 9550 | Ticket should be divisible | ticket system | next-major-releases | enhancement | normal | cboos | new | 2010-08-06T04:51:22+02:00 | 2013-01-13T15:27:39+01:00 | Sometimes tickets are entered into the ticket system that contain more than one issue. These tickets should be diversible. When something like this happens I create new tickets with the parts and assign them to their owners. The all new ticket ids are put into the 'parent'. It would be nice if trac could help with this task and manage a parent/child relationship between tickets. When childs of a ticket are created the parent ticket should be set on hold until all children are resolved. The parent could show a progress bar or something. Notifications for children should be send to their subscribers and the subscribers of the parent ticket. | stephan@… | ||
| 9735 | TicketQuery adds reporter by default | ticket system | 0.12dev | next-major-releases | defect | normal | new | 2010-10-31T02:01:36+01:00 | 2011-10-29T18:28:35+02:00 | `TicketQuery` macro adds reporter row by default if using `rows` option. It seems this is [source:trunk/trac/ticket/query.py#L430 hard-coded]. It would be great to be able to disable this feature for those who wants more concise output. | Mitar | ||
| 9738 | Add "attach file" button at the end of the ticket | ticket system | 0.12dev | next-major-releases | enhancement | normal | new | 2010-10-31T21:39:09+01:00 | 2012-03-29T10:37:11+02:00 | Add "attach file" button at the end of the ticket as some (novice) users have problems finding a way to attach a file. They are used from wiki that button is at the bottom and in ticket also a change ticket form is at the bottom. So it is not really reasonable to imagine that there is one button up there (if you missed it). Even the anchor link to attachments does not help much. So I believe it would be useful to simply add "attach file" at the bottom, too. | Mitar | ||
| 9799 | Hardcoded special status values "new" and "closed" cannot be localized in Workflow | ticket system | 0.12.1 | next-major-releases | enhancement | normal | new | 2010-11-09T14:26:17+01:00 | 2010-12-29T00:04:11+01:00 | Custom workflows are problematic for localization. It's possible to be creative with section [ticket-workflow] in trac.ini. For example, (in Finnish) {{{ [ticket-workflow] accept = new,uusi,aloitettu,suljettu -> aloitettu accept.name = Ota lippu vastaan ja ota toteuttaminen vastuullesi accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY confirm = new -> uusi confirm.default = 2 confirm.name = Vahvista lippu (merkitään uudeksi) confirm.permissions = TICKET_MODIFY leave = * -> * leave.default = 1 leave.name = Ei muutosta leave.operations = leave_status reassign = uusi,aloitettu -> aloitettu reassign.name = Vaihda tekijä reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reopen = suljettu -> uusi reopen.name = Avaa uudelleen (ei olekaan vielä valmis) reopen.operations = del_resolution reopen.permissions = TICKET_CREATE resolve = new,uusi,aloitettu -> suljettu resolve.name = Merkitse suljetuksi resolve.operations = set_resolution resolve.permissions = TICKET_MODIFY close = suljettu -> closed close.name = Vahvista suljetuksi close.permissions = TICKET_MODIFY }}} In the above configuration "uusi" means "new","aloitettu" means "work started","suljettu" means "closed" in Finnish. The .name labels have been set to make sense in Actions form. Logically "uusi" is interpreted as "accepted new","suljettu" is interpreted as "closed" (but not to trac) and "closed" is interpreted as "verified closed" (and closed to trac). This is far from optimal, but the best I've come up with when using Trac 0.12.1. However, this does not allow changing displayed labels for status "new" or "closed". These values are leaked to end user through various locations. If I've understood correctly, these are hardcoded in the source and as such, cannot be specified in the configuration. As I see it, there're two possible solutions: 1. Add special code to correctly localize "new" and "closed" status in every place a status is displayed, or 2. Add two configuration parameters to define custom status values to replace "new" and "closed" status values. I personally would prefer 1 if #9472 is ever fixed to allow translating the workflow in whole (so that a single environment can display possible actions in any language the current user happens to use as opposed to using the single language coded in the trac.ini as in the example above). However, if the official method for translating the workflow (in the future) is to use custom status values with custom .name strings (as in the example above), then I prefer option 2 above because in that case all localization string related to custom workflow would be in a single file. If solution 2 above is used, I'd suggest two additional parameters to [ticket] section (notice that these cannot be added to [ticket-workflow] because any name in that section can be taken by custom workflow action): {{{default_status}}} (defaults to currently hardcoded "new"): Value of this parameter is used as status for all newly created tickets. {{{override_status_closed}}} (defaults to currently hardcoded "closed"): If the status of any ticket is set to this value, that ticket should be considered as closed for any code where the distinction between open and closed tickets do matter. I'm marking this as component "ticket system" in case option 2 above is implemented (which I believe is easier to implement). In case option 1 above is considered better, the correct component should be i18n. See also: #9472. | Mikko Rantalainen <mikko.rantalainen@…> | ||
| 9807 | Wrong sections are collapsed by default! | ticket system | next-major-releases | enhancement | normal | new | 2010-11-10T01:38:35+01:00 | 2012-09-29T12:41:07+02:00 | Collapsing the sections in a ticke is great - the trouble is that the section that is used 99% of the time is the "modify" section which is pre-collapsed. An ideal solution would be to make this system configurable (or even user configurable). It is going to pee-off my users to now have to press that extra button... petty I know.... but its the truth. | morgand | |||
| 10125 | CommitTicketUpdater should call manipulators and listeners | ticket system | 0.12-stable | next-major-releases | enhancement | normal | rblank | new | 2011-04-10T21:35:04+02:00 | 2012-06-17T13:28:54+02:00 | I don't use this hook myself, but I frequently get questions about it on IRC and try to help out. One very frequent request is some or handling for additional fields or related plugins that need to act on what gets updated on the ticket. Example can be also adjusting estimates or time spent on fixing bugs, or updating some other related fields and structures. Anyway, I quickly scanned the source and see that we don't call ticket system manipulators or listeners? That would provide the hooks to either change fields directly together with commit-update, or be handle updating of related information after-the-fact via listener. Any reason not to call manipulators and listeners? | osimons | |
| 10209 | Allow to deprecate components | ticket system | 0.13dev | next-major-releases | enhancement | normal | new | 2011-06-05T14:47:24+02:00 | 2011-06-17T23:57:23+02:00 | For JOSM we manage the core and also plugins in the same trac instance. Sometimes plugins are integrated into core and thus the components for these are no longer relevant. But there is no possibility to deprecate components. Deleting the components totally results in problems with searching. What I would like to see is a method to mark a component as deprecated: * It is no longer contained in the choice boxes of tickets * When the component is already assigned, it remains until changed. | dstoecker | ||
| 10325 | Way to delete ticket comments versions | ticket system | 0.12.2 | next-major-releases | enhancement | normal | new | 2011-08-20T23:03:11+02:00 | 2011-08-20T23:58:49+02:00 | In a similar way that it is possible to delete just wiki page versions, it would be great to be able to delete also ticket comments versions. Currently it is possible only to delete the comment as a whole, with all versions. Similar maybe also for summary versions? | Mitar | ||
| 10381 | Use full width for custom textarea fields, and make them collapsible | ticket system | 0.12.2 | next-major-releases | enhancement | normal | new | 2011-09-29T11:14:09+02:00 | 2012-09-10T15:23:16+02:00 | The content of custom textareas might get very big, so it would be better to place these fields in full width after description field. Furthermore it would be nice, if these fields are collapsable, so you could close them, if you do not need them at the moment. | anonymous | ||
| 10396 | [PATCH] New extension point interface to reformat the "replying to" block in a comment | ticket system | 0.12-stable | next-major-releases | enhancement | normal | new | 2011-10-05T12:13:27+02:00 | 2012-07-11T07:56:03+02:00 | Sometimes you don't want the original text in a response on a ticket in the "Replying to" line. Instead some sort of custom formatting (e.g. abbreviation, reference no.) could be used preferably. Solution: A new extension point ITicketCommentFormatter defined in ticket/api.py. The function quote_original() in ticket/web_ui.py calls the plugins, that implement the new extension point. So it is possible to reformat the "replying to" block in a comment, to leave it unchanged or to drop it at all. | juliak <kavalerchik@…> | ||
| 9549 | TicketQueryMacro and TracQueryLanguage documentation seems outdated | ticket system | 0.12dev | next-minor-0.12.x | defect | normal | new | 2010-08-05T21:48:04+02:00 | 2010-09-23T15:44:19+02:00 | Available documentation on the TicketQueryMacro is missing the '''col''' parameter which takes a "'''|'''" separated list of columns that will be diplayed. In addition, the documentation on the TracQueryLanguage states that in order to match multiple values one will have to separated them using a semicolon. This is not true for the TicketQueryMacro, here you have to separate individual values using "'''|'''". | Carsten Klein <carsten.klein@…> | ||
| 10232 | Validating Ticket accounts for new or removed fields? | ticket system | 0.11.5 | next-minor-0.12.x | defect | normal | new | 2011-06-23T16:33:44+02:00 | 2011-06-23T20:34:04+02:00 | On IRC today there appeared an issue that brought back memories of #4447 and #9663. A user has permission to reopen a ticket, and when doing so the preview looks like this: {{{ #!div style="background:#EEE" * '''status''' changed from ''closed'' to ''reopened'' * '''resolution''' ''answered'' deleted }}} Just like it should. And `trac.ticket.web_ui.TicketModule._validate_ticket()` accounts for the fact that workflow may change these two fields. Problem is that the user sees an error: {{{ #!div style="background:#FFFFBB" '''Warning:''' No permission to change ticket fields. }}} The user claims that this happens all the time, and the real question is why `changes` isn't empty after this in initial validation method: {{{ #!python changed = set(ticket._old) - set(['status', 'resolution']) }}} I suspect this is due to fields being added or removed in the system in the time since the ticket was previously edited. They are changes that will need to be recorded, but when they don't arise from user input it seems wrong to let it be a user problem. The problem is real, but my hypothesis is not completely researched yet... But, it feels like it makes sense... :-) | osimons | ||
| 10465 | Counting of Ticket-Comments defect | ticket system | 0.12.1 | next-minor-0.12.x | defect | normal | rblank | new | 2011-11-15T16:50:37+01:00 | 2011-11-16T01:08:43+01:00 | Hello, in our trac installation I see the error that the ticket comment after comment 79 gets again the number 3. All comments after that comment are increased from 3. OS is CentOS 6. Regards, Erwin Schliske | schliske@… | |
| 10838 | TicketQuery progress display link ignores order= keys in milestone_groups query_args causing query error | ticket system | 1.0 | next-stable-1.0.x | defect | minor | psuter | assigned | 2012-09-09T11:36:07+02:00 | 2013-02-15T21:45:54+01:00 | Using the macro invocation {{{ [[TicketQuery(owner=ian, format=progress)]] }}} in a wiki page creates a progress bar with links for various classes of ticket. The resulting progress bar creates query URLs that work for all classes of ticket except for closed tickets. For closed tickets it produces a link that looks like: {{{ /trac/msl/query?owner=ian&status=closed&group=resolution&order=time&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=severity&col=time&col=changetime&max=0&order=id }}} This URL includes two order= keys: order=time near the begining and order=id at the end. This confuses Trac and results in a runtime error. All other classes of ticket, such as accepted tickets produce a link that looks like: {{{ /trac/msl/query?owner=ian&status=accepted&max=0&order=id }}} with a single order=id statement. The source of this error is that our milestone groups includes an order=time key. We got this by direct copying from the sample at [http://trac.edgewall.org/wiki/TracIni#milestone-groups-section TracIni] without much thought about what it meant. {{{ [milestone-groups] ... # optional extra param for the query (two additional columns: created and modified and sort on created) closed.query_args = group=resolution,order=time,col=id,col=summary,col=owner,col=type,col=priority,col=component,col=severity,col=time,col=changetime ... }}} === Error message === {{{ Trac detected an internal error: TypeError: unhashable type: 'list' }}} === Python traceback === {{{ Most recent call last: File "build/bdist.win32/egg/trac/web/main.py", line 497, in _dispatch_request dispatcher.dispatch(req) File "build/bdist.win32/egg/trac/web/main.py", line 214, in dispatch resp = chosen_handler.process_request(req) File "build/bdist.win32/egg/trac/ticket/query.py", line 939, in process_request max) File "build/bdist.win32/egg/trac/ticket/query.py", line 77, in __init__ self.order = synonyms.get(order, order) # 0.11 compatibility }}} === System information === User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E) || Trac || 1.0 || || Docutils || 0.8.1 || || Genshi || 0.6 (without speedups) || || mod_python || 3.3.1 || || Pygments || 1.4 || || pysqlite || 2.4.1 || || Python || 2.6.6 (r266:84297, Aug 24 2010, 18:46:32) [MSC v.1500 32 bit (Intel)] || || setuptools || 0.6c11 || || SQLite || 3.5.9 || || Subversion || 1.7.1 (r1186859) || || jQuery || 1.7.2 || | ilewismsl | |
| 10772 | Set default component to empty string | ticket system | 0.11.5 | next-stable-1.0.x | task | normal | new | 2012-07-18T12:24:31+02:00 | 2012-07-18T12:34:11+02:00 | I am trying to set the default component to an empty string. but when ever I set the default value = to an empty value it will be set to the first on the list of components. | asaf.levy@… | ||
| 10962 | Show due date of milestone in ticket | ticket system | 1.0 | next-stable-1.0.x | enhancement | normal | new | 2012-11-22T11:23:03+01:00 | 2013-01-23T15:13:42+01:00 | In ticket view is a link to the assigned milestone. When you want to know what due date has that milestone, you have to click on the milestone link. It would be nice to have that information already in the ticket view. There might be two ways to achieve this: a. by tooltip a. by adding it after milestone name | franz.mayer@… | ||
| 11125 | Truncate very long text in the ticket properties dialog | ticket system | next-stable-1.0.x | enhancement | normal | new | 2013-03-19T23:17:09+01:00 | 2013-03-20T18:27:38+01:00 | Use a bit of CSS to prevent this from happening. It's a bit of a corner case because the text would have to be quite long, but will be easy to fix. [[Image(Overspill.png,100%)]] | Ryan J Ollos <ryan.j.ollos@…> | |||
| 6723 | Trac tickets send out on email as task on Mail Clients | ticket system | devel | not applicable | enhancement | normal | jonas | new | 2008-01-28T15:21:07+01:00 | 2010-12-07T20:18:21+01:00 | Most of the email clients (Outlook, GroupWise, Notes, Kontact) can handle task lists. Tasks can also be emailed to another person. It would be very usefull if Trac could email tasks out as a task that can be accepted in the normal email client with a lin to the Trac task. | bill.meyer@… | |
| 11085 | Submitting ticket changes breaks window.history on Chrome | ticket system | not applicable | defect | normal | new | 2013-02-27T17:24:52+01:00 | 2013-03-11T10:44:58+01:00 | To reproduce, using Chrome Version 25.0.1364.99 (Mac) 1. Go to `/newticket` and file a new ticket 1. The page will reload at `/ticket/N#ticket` 1. Click "Modify Ticket" 1. The page does not reload. The URL bar now reads `/ticket/N#no4` 1. Click "Resolve as fixed" and click "Submit changes" 1. The page reloads. The URL bar now reads `/ticket/N#comment:1` 1. Click the browser's Back button 1. The page does not reload. The URL bar now reads `/ticket/N#no4` 1. Click the browser's Back button again. 1. (This is the point at which it becomes a bug.) The page does not reload. The URL bar now reads `/ticket/N#comment:1` You are now stuck in a loop -- no matter how many times you click the browser's Back button, the page will never reload, and the URL bar will just cycle its fragment between `#no4` and `#comment:1`. To escape the loop you need to use the browser's History menu, or something like `javascript:window.history.go(-2)`, or (the option that's become my habit) actually follow another link from the Trac UI or just type in a different URL in the browser. This bug does '''not''' occur with Firefox 18.0.2 for Mac. I haven't tested on other browsers/OSes/devices. | ethan.jucovy@… | |||
| 9624 | Project-specific ticket prefixes and numbering | ticket system | 0.12 | topic-multiproject | enhancement | normal | new | 2010-09-16T21:12:36+02:00 | 2011-02-10T00:45:59+01:00 | With the addition of multiple projects in one Trac instance, it could be helpful to assign ticket identifiers with project-specific prefixes and independent numbering. The prefix would be configured wherever the project is configured. (trac.ini?) This would help differentiate tickets when referring to them by identifier. This is how JIRA assigns ticket identifiers. For example, in a Trac with two project named Database (DATA) and Web Service (WS), the ticket references would look like: * DATA-102 * WS-93 With the next Database ticket being assigned DATA-103 and the next Web Service ticket being assigned WS-94. Since changing the way tickets are identified would probably be a huge change, maybe assigned ticket aliases would be a simpler workaround to provide the same functionality? I'm not sure what the best way to use these identifiers as wiki links would be, but the idea is that something like the following could be used to create wiki links: * WS-93 * !ticket:WS-93 * #WS-93 * WS:93 (this might be easiest since you can treat each project prefix as a TracLinks namespace?) Of course, if the identifier is implemented as an alias then it could get confusing with the underlying numeric identifiers. WS:93 and !#342 could point to the same ticket. This also raises the question of what happens if a ticket is moved between projects. I don't have an understanding of the amount of work involved for this type of change, so this is just a suggestion for consideration. I do think it would be very useful for scenarios with 10+ projects sharing a ticket database. | nslowes@… | ||
| 10271 | set_owner not considering extra permissions | ticket system | 0.12dev | undecided | defect | major | new | 2011-07-17T13:56:06+02:00 | 2013-03-11T10:03:11+01:00 | We created a custom Workflow according to [http://trac.edgewall.org/wiki/TracWorkflow Workflow documentation] and assigned dedicated permissions using the optional [http://trac.edgewall.org/wiki/ExtraPermissionsProvider tracopt.perm.config_perm_provider.ExtraPermissionsProvider] which works fine in principle. The issue reported here is the fact that using .set_owner operation does not consider those users having assigned permissions via [http://trac.edgewall.org/wiki/ExtraPermissionsProvider tracopt.perm.config_perm_provider.ExtraPermissionsProvider] but only those having MODIFY_TICKET. OS: CentOS 5.5 Python: 2.4 | Ruedi <ruedi.silvestri@…> | ||
| 10681 | commit_updater.py create wrong comment number | ticket system | 0.12.2 | undecided | defect | normal | new | 2012-04-27T12:47:43+02:00 | 2013-03-11T10:03:11+01:00 | How to reproduce[[BR]] 1. create new ticket A,B 2. add a comment in ticket B 3. commit message like below TWICE in hg {{{ refs #B refs #A test commit updater }}} Expect result[[BR]] Ticket A will have comment 1,2[[BR]] Ticket B will have comment 1,2,3 In fact we get[[BR]] Ticket A has comment 1,2[[BR]] Ticket B has comment number 1,2,2 | haterw@… | ||
| 10833 | ConfigurableTicketWorkflow's "Reassign To" ignores fine-grained permissions with restrict_owner=True | ticket system | undecided | defect | normal | new | 2012-09-07T16:16:28+02:00 | 2013-03-11T10:03:11+01:00 | When `[ticket] restrict_owner = True`, the default ticket workflow implementation renders a dropdown box for actions that perform a `set_owner` operation. If the set of possible owners is not specified in the workflow configuration, it is populated with a call to `PermissionSystem(env).get_users_with_permission('TICKET_MODIFY')`, just like the similar dropdowns that are rendered by `TicketSystem.eventually_restrict_owner` on the new ticket form and query builder. However, after fetching the list of all known users with TICKET_MODIFY, the workflow does not check whether those users have the TICKET_MODIFY permission for the current ticket. If the system is configured to use a fine-grained permission policy like browser:trunk/sample-plugins/permissions/vulnerability_tickets.py, where the global TICKET_MODIFY permission does not guarantee TICKET_MODIFY for any given ticket, this could result in strange states where the ticket's owner does not have permission to close, modify or reassign the ticket. I'm not sure whether this actually is a bug that should be fixed. For one thing, as long as the users who have permission to reassign a ticket are trusted to know what they're doing, it's not really a problem. It's also not necessarily Trac's job to ensure that the owner field is restricted to "sensible" choices, and anyway there are plenty of other ways that the system could end up in a similar state with certain combinations of configuration. | Ethan Jucovy <ethan.jucovy@…> | |||
| 10843 | Make all textarea fields foldable | ticket system | 1.0 | undecided | enhancement | normal | new | 2012-09-10T12:16:34+02:00 | 2013-03-11T10:03:11+01:00 | Make all textarea fields, such as `Description` and custom textarea fields foldable / expandable. | framay <franz.mayer@…> | ||
| 2908 | No 'register' link (only Login), 'New Ticket' -> 'login' difficult | ticket system | 0.12dev | unscheduled | defect | major | new | 2006-03-20T20:12:24+01:00 | 2010-06-28T22:30:16+02:00 | I'm really irritated that most trac sites (including this one) doesn't offer a registration link (only Login). This leads to some frustrating situations: I come along, want to report a bug. Trac tells me, I need "CREATE_TICKET" permissions. Why do you show "New Ticket" if I can't?? Now, I try to find a way to register. But there isn't. Next, i try to find some other way to post my bug report but there isn't. I give up. I suggest that you disable the links to the ticket system when anonymous posting is disabled plus put a big warning next to the option for the site admin. | digulla@… | ||
| 6820 | change display for duplicate tickets | ticket system | unscheduled | enhancement | minor | jonas | new | 2008-02-12T23:54:26+01:00 | 2010-11-17T09:16:59+01:00 | When a ticket is marked as a duplicate the ticket link is displayed with a strike-through character in a wiki page or a search. This is confusing, since it indicates to the reader, that the issue is solved, which must not be the case. The ticket is simply marked as closed, but the request is still open. Is it possible to use e.g. a double strike through character? A much better solution would be the build in support for specifying the duplicate ticket, as suggested in #1395. Then the display could change depending on the status of the referenced duplicate ticket. | trac@… | ||
| 8504 | Named Custom Queries | ticket system | 0.11.5 | unscheduled | enhancement | minor | new | 2009-07-23T08:42:23+02:00 | 2010-07-03T23:56:19+02:00 | When running a custom query, customizing it further by adding filters, grouping, etc - the query is still a "Custom Query". What I'd like is to have "named" or "saved" queries. Just saving a query is easy, you just add a link to a wiki page. But the headline still says "Custom Query" rather some real, readable, title. | noamtm@… | ||
| 8736 | Boundary of background does not encompass intended fields. | ticket system | none | unscheduled | defect | minor | new | 2009-10-13T13:57:16+02:00 | 2010-09-10T14:47:51+02:00 | Fields like the summary or component field are not encompassed by the white background. See attached image. | Miruba | ||
| 10532 | Show diff when summary changes (instead of <old value> to <new value>) | ticket system | 0.13dev | unscheduled | enhancement | minor | new | 2012-01-19T09:47:24+01:00 | 2012-01-19T18:29:56+01:00 | In this [http://trac.edgewall.org/ticket/8135#comment:11 summary change] you do not see any changes at once - and I guess there is not a change at all (which might be a defect). It would be better readable if summary changes would be displayed in a diff view instead of "<old value> to <new value>" manner, since most summary changes are typos or small changes. If it is a bigger change (maybe using some smart algorithm to determine that it has changed more than 50%) Trac could display it in this way: <old value> to <new value>. | framay <franz.mayer@…> | ||
| 508 | 'Related checkins' feature | ticket system | 0.7 | unscheduled | enhancement | normal | new | 2004-06-03T20:52:37+02:00 | 2010-11-17T09:24:44+01:00 | In CVSTrac, a ticket has a field called "Related Checkins" which shows a list of checkins (they would be changsets in trac) and their comments. You can add and remove from this list by editing a comma-seperated list of related checkins. However, the most useful part, is that by putting a ticket number into your checkin message, it automatically adds that checkin to the "Related Checkins" of the ticket. Eg. svn commit -m 'Added the ability to edit existing tickets. This fixes ticket #411' Then when you view the ticket #411 you can see that checkin there without doing any more work. This feature made CVSTrac sooo useful, because it was very easy to make this connection from the ticket to the checkins that attempted to fix it. bonus marks: The whole idea of two-way linking useful in general -- once you had this feature you might also show wiki pages linking to a ticket, or tickets linking to a wiki page. Often with information given by people, the incoming links are as relevant as the outgoing ones. BUT the automatic pingback from the checkins to the tickets is by far the most useful! | dobes | ||
| 925 | [PATCH] Allow wiki syntax in labels for custom fields | ticket system | devel | unscheduled | enhancement | normal | athomas | assigned | 2004-11-13T22:11:29+01:00 | 2010-06-15T23:13:28+02:00 | The proposal is to add a possibility to use Wiki syntax in labels for custom fields. Example 1: We need to put emphasis on ''Platform'' field {{{ [ticket-custom] platform = select platform.order = 1 platform.label = '''Platform''' platform.options = |Intel P4|Intel XEON|AMD Athlon 64|Other }}} Example 2: We need to define a link to help screen for ''Platform'' field {{{ [ticket-custom] platform = select platform.order = 1 platform.label = [wiki:HelpPlatform Platform] platform.options = |Intel P4|Intel XEON|AMD Athlon 64|Other }}} Attached patch contains an implementation for the proposal. | pkou <pkou at ua.fm> | |
| 2775 | Automatic matching of similar issues | ticket system | 0.9.4 | unscheduled | enhancement | normal | jonas | reopened | 2006-02-17T11:07:42+01:00 | 2010-09-10T14:47:51+02:00 | So in order to make things easier when prioritizing, it would be really cool to see something that displays how many issues there are with closely matching content. This would help when duplicate tickets are created, in order to more easily show the user where the dupes are, and also when prioritizing which issues should be worked on first (if the basis is the amount of requests) | chris@… | |
| 2968 | need a "contains" option for Owner if restrict_owner is true | ticket system | 0.9.4 | unscheduled | enhancement | normal | jonas | new | 2006-03-31T16:05:30+02:00 | 2010-09-10T16:28:19+02:00 | #1439 ([1664]) tied up the "restrict_owner" to control not only the newticket page but also the search page. However in light of requests to edit or clean-up the userlist (#2351, #1347) - it should be recognised that dropdown for owners of "new tickets" may not be the same as the owners you want to search for. so we need the "contains, startswith, endswith" options for owner even if the restrict_owner is true. This does stop those of us using the "query" system from effectively managing our reporters. | anonymous | |
| 3003 | milestone could be a ticket | ticket system | 0.9.4 | unscheduled | enhancement | normal | cboos | new | 2006-04-09T09:31:51+02:00 | 2012-04-20T08:01:08+02:00 | can milestones be implemented as tickets too, just by marking a ticket as milestone? a milestone can depend on other milestones, they can be in parallel, they have a responsible, they have an importance, and they depend on the completion of tickets. currently the milestone concept has a few weaknesses: * changes are not tracked * no responsible * no dependencies (or just implicit by setting dates) * consolidated view over multiple trac instances, i.e. have a big milestone consisting of small ones stored in other trac instances. mark a ticket as a milestone, intertrac, and ticket dependencies would solve 95% of these issues. do you see any disadvantage in doing this? | ThurnerRupert | |
| 3785 | Regular Expression Match against custom field values | ticket system | devel | unscheduled | enhancement | normal | athomas | new | 2006-09-25T23:42:20+02:00 | 2010-06-28T23:56:14+02:00 | It would be handy to add an option to the Trac Custom Fields feature that allows a regular expression match string as a sanity check against a custom field. As some fields require the flexibility of text input, but within certain parameters that a SELECT field doesn't offer, this could be very handy. The match string would just have to evaluate to true if the field works. I did a few searches and didn't see anything like this -- please enlighten me if otherwise. I could attempt to look at a patch if there is interest, though I haven't worked with Python before. Suggestion for implementation: {{{ [ticket-custom] test_date_field = text test_date_field.label = Test a Date test_date_field.value = test_date_field.match = /\d{4}-\d{2}-\d{2}/ }}} | nmelnick@… | |
| 4173 | When "View Ticket" is selected, sub-options should always be visible. | ticket system | 0.10 | unscheduled | enhancement | normal | jonas | new | 2006-11-15T14:00:38+01:00 | 2010-09-10T17:01:39+02:00 | This request is to help lower the learning curve and to make navigation more obvious. I've used trac for many months now, but still keep forgetting how to navigate to "Custom Query". Some people in my team didn't know this feature exists - they just use Search. Why? The link is not always visible. When viewing a ticket (where I spend most of my time), the "View Tickets" button is selected (but with no sub-options shown). Therefore I never think to click it again. So instead: * I click something else like "Search". Nope not there... * I click "View Tickets", and the text appearing on the left attracts my view. I don't even notice something small has appeared under "view tickets", because there was nothing there before. * I scratch my head and hunt around some more. '''Proposed solution''': In all screens where the "View Tickets" button is rendered selected, the two sub-options "Available Reports" and "Custom Query" should also be displayed. | l.usherwood@… | |
| 4632 | Dropdown list for the CC field | ticket system | 0.10.3 | unscheduled | enhancement | normal | jonas | reopened | 2007-01-31T10:10:23+01:00 | 2013-04-11T13:59:34+02:00 | I want to make CC field in view as Multiple selection dropdown list. How can i do it?? | anonymous | |
| 5378 | ajax bandbox for input of milestone, component, assign to, and cc | ticket system | unscheduled | enhancement | normal | jonas | new | 2007-05-26T14:01:52+02:00 | 2010-06-30T23:48:42+02:00 | it would be gread to have a ajax bandbox (see [http://zkoss.org/zkdemo/userguide/ zkoss userguide, bandboxes) for the following fields: * milestone: select one, search not necessary if they are sorted right, link to add a new one * component, search, select one, link to add a new one * assign to, search, select one * cc, search, multiple select with jquery i did not see a similar demo, sorry. | ThurnerRupert | ||
| 6548 | different types of ticket need different workflows | ticket system | 0.11b1 | unscheduled | enhancement | normal | jonas | reopened | 2007-12-23T02:02:06+01:00 | 2011-12-29T09:18:20+01:00 | Actions should be selectable based on the ticket type (different Workflows for different tickets. This is becoming a frequent request, with clear usecases. The closest the current implementation will allow is to have a plugin provide a `triage` action that sets the next state based on the ticket type, so a `new` ticket would move to `new_task`, `new_defect`, etc., and the workflow graph would separate at that point. | anonymous | |
| 7015 | Provide interface to fill custom select-boxes | ticket system | unscheduled | enhancement | normal | cboos | new | 2008-03-18T14:08:34+01:00 | 2010-07-13T13:27:33+02:00 | would be nice to have a interface which can provide data for the selectboxes you can find in the properties fieldset of a ticket. we have the problem that our software has a lot of plugins which are all described in the trac-wiki and the ticket system is used for managing the bugs etc. The component select-box is very often not uptodate because someone added a new plugin and this plugin wasn't added to the component list yet.. so the problem is, that nobody can report bugs/feature request which are related to the new plugin.. | Markus.Staab | ||
| 7290 | restrict_owner_force Option to populate user list | ticket system | unscheduled | enhancement | normal | new | 2008-06-01T20:36:53+02:00 | 2010-07-02T23:18:04+02:00 | The restrict_owner setting changes the field to a dropdown list that has (1) TICKET_MODIFY rights and (2) logged in at least once. In an environment where you add users - and want them to be assigned tickets - even if they have not logged in before can be useful. Maybe the following option can be added: Something like Add restrict_owner_force = TRUE in ini file to populate the list with the TICKET_MODIFY rights, without having logged in. This way either the filtered and unfiltered lists can be made available depending on the environment requirements. I have need for both situations. | bill.meyer@… | |||
| 7300 | [PATCH] Support for ticket reassignment in trac-post-commit-hook | ticket system | unscheduled | enhancement | normal | new | 2008-06-04T00:27:22+02:00 | 2010-07-19T09:34:30+02:00 | I extended [source:trunk/contrib/trac-post-commit-hook trac-post-commit-hook] to support reassignment in the form of: reassign #1 to user assign #1 user | ian@… | |||
| 7911 | Optional validation for custom fields | ticket system | none | unscheduled | enhancement | normal | new | 2008-12-24T18:04:39+01:00 | 2010-07-03T23:09:21+02:00 | JQuery permits a nice environment to build custom/dynamic drop-down lists for custom fields in trac tickets; unfortunately validation for the ticket fails as the dynamic value for a field with an option list cannot be found in the configuration file. At least two solutions are possible: 1. Add an option for turning off validation in comparing the value against the option list, and 1. Allow for dynamic validation. I have implemented the solution for #1 (attached). | trac@… | ||
| 8069 | [PATCH] Support list of users as options list in ticket custom field | ticket system | 0.11.3 | unscheduled | enhancement | normal | reopened | 2009-02-18T19:57:54+01:00 | 2012-08-20T15:46:20+02:00 | In the process of migrating from a Borland StarTeam install to Trac+SVN, I needed the ability to assign multiple users to a ticket. Borland provided the ability to include custom Change Request fields which could be limited to the list of valid users within the StarTeam project. Attached is a patch which implements similar behavior in Trac. The patch introduces a simple variable replacement scheme to the options attribute of a custom ticket field. The INI section looks like this: {{{ [ticket-custom] devtest_assigned = select devtest_assigned.label = Dev Tester Assigned devtest_assigned.options = $userlist }}} Code in ticket/api.py checks for a select custom field which has an options attribute of literally "$userlist". If such a field is found, the field is passed to the existing function eventually_restrict_owner() to insert the listing of valid users. The attached trivial three-line patch appears to work well against Trac-0.11.3. | Zachary Bedell <zbedell@…> | ||
| 8163 | Grouping owners | ticket system | none | unscheduled | enhancement | normal | new | 2009-03-26T12:18:11+01:00 | 2010-06-10T21:13:54+02:00 | If I set restrict_owner = 'true' in trac.ini, I can select from a list of people who have the proper permission to edit tickets as "owner". The drop down list itself is only alphabetically arranged, without any classifications. It would be good if there is a something to set the drop down list like the following example. {{{ Group 1 - User A - User D Group 2 - User E - User F Group 3 - User B - User C - User G - User H }}} | repeat <repeat@…> | ||
| 8653 | [PATCH] Don't allow anonymous users to modify some fields | ticket system | 0.11.5 | unscheduled | enhancement | normal | new | 2009-09-09T19:15:47+02:00 | 2010-11-26T15:00:13+01:00 | This patch lets you set a comma separated list of fields that won't be visible at /newticket time to users without TICKET_MODIFY status. Included is a bonus exception check we received when there were non-numeric ticket numbers. To use: in trac.ini, we have this line: {{{ [ticket] not_anon_fields=load,priority,keywords,revw,owner,cc,xref,weeks,milestone }}} These are fields we do NOT want 'anonymous' users to modify when creating a ticket. (For example, revw is used to mark a ticket with the name of a reviewer.) Note that there is a default list of fields hidden as well with this patch. The default could be made empty. | Steven R. Loomis <srl@…> | ||
| 8702 | Different workflows when viewing own tickets/others tickets | ticket system | 0.11.5 | unscheduled | enhancement | normal | new | 2009-09-29T22:49:10+02:00 | 2010-07-04T00:04:49+02:00 | I want to have an "accept and resolve" workflow for accepting someone else's ticket and closing it in one step, but it's extraneous when you're viewing your own tickets. It would be nice if I could create a workflow that would only show up when you're viewing your own ticket, or only show up if you're viewing someone else's ticket. Maybe something like `workflow_name.owner = ( self | others | any )` (of course `any` being the default, the current behavior). | adrian.price@… | ||
| 8812 | Text field with post-label and right alignment | ticket system | none | unscheduled | enhancement | normal | new | 2009-11-12T16:52:59+01:00 | 2010-07-04T00:15:07+02:00 | The TH:TimingAndEstimation plugin uses text fields as number fields. Either allow for a proper number inputfield or extend the text field to allow for: * a right alignment of the value * an post-label that can be used as an unit | guido.stet@… | ||
| 9289 | Permissions for custom ticket fields | ticket system | 0.11.4 | unscheduled | enhancement | normal | reopened | 2010-05-04T12:17:24+02:00 | 2011-05-11T01:55:53+02:00 | I would like to request a feature to be able to specify permissions for custom ticket fields. So that for a defined custom field you would be able to define users which can edit it on ticket opening, edit it later and also see it (or not) altogether. This is very hard to do properly with a plugin as it requires finding out in `post_process_request` phase where all field has been displayed and removing that (ticket view, RSS, alternative views, ticket notifications, ticket queries, searching tickets...). It would be much easier if Trac would simply remove it from a list of fields in the first place if user would not have access to it (in a given ticket state). | Mitar | ||
| 9495 | CommitTicketUpdater - git and replayed commits | ticket system | 0.12dev | unscheduled | enhancement | normal | new | 2010-07-11T20:33:36+02:00 | 2010-09-13T13:00:38+02:00 | I do all my development over two branches, a stable one and an experimental one, which I merge periodically. So, each time I merge `stable` into `experimental`, commits from `stable` are again passed on to the ticket updater. So, sometimes this ends up producing duplicate comments and the ticket being closed twice... My opinion is that could be an option that would somehow trigger the detection of duplicate commits and ignore them. I'm not very sure how to do this, if I should check if there's already a comment with the given commit sha1 associated with the ticket (kind of hacky), or checking the past repository history (ignoring the last changeset) for the commit (not sure how fast it will be). I would be willing to produce a patch for that, if you believe this is something worth investing time on. Otherwise, I can just try changing a bit my commit hook. However, I believe that this will be a problem with most distributed VCs, so... | pferreir | ||
| 9505 | Missing feature from ticket query module: color tickets based on contents of field | ticket system | unscheduled | enhancement | normal | new | 2010-07-16T18:08:16+02:00 | 2010-07-16T20:56:13+02:00 | '''Note: The report module is being phased out in its current form because it seriously limits the ability of the Trac team to make adjustments to the underlying database schema. We believe that the query module is a good replacement that provides more flexibility and better usability. While there are certain reports that cannot yet be handled by the query module, we intend to further enhance it so that at some point the reports module can be completely removed. This also means that there will be no major enhancements to the report module anymore.''' I think that a missing feature is the ability to color tickets based on values. For example, you can color tickets red that have the priority of "blocker". If this already exists, could you please provide some documentation on how to accomplish this query? | aaronaddleman@… | |||
| 9508 | Provide per-type resolution lists | ticket system | unscheduled | enhancement | normal | new | 2010-07-18T16:53:29+02:00 | 2010-09-23T16:34:18+02:00 | The default set of resolutions (fixed, invalid, wontfix, etc) are fine for defects, but don't make a lot of sense for tasks. It would be nice to be able to have the "Resolve as" menu include choices specific to each ticket type. For a task, that might be "done","wontdo","postpone", etc. | roy@… | |||
| 9530 | Ask questions to the ticket reporter. | ticket system | 0.11.5 | unscheduled | enhancement | normal | new | 2010-07-28T20:49:45+02:00 | 2010-07-28T22:40:16+02:00 | I'd like the posibility to ask questions to the ticket reporter, asking for more detail or specific questions about the ticket. Questions should be included in the notification system so that the reporter can receive an mail with the question and then answer. Questions should be visualize with the ticket. | fglaeser@… | ||
| 9706 | New ticket_change class: commit | ticket system | 0.12-stable | unscheduled | enhancement | normal | new | 2010-10-23T00:58:34+02:00 | 2010-12-28T23:54:39+01:00 | We have had an issue on our instance of TRAC where a developer typed a commit message awkwardly, and (because he had an edit button), attempted to fix the wording. The problem he had was that upon clicking submit, the page would refresh but the changes would not be applied, yet if he would click edit again, his changes would be present there. While I do consider this a bug, I respect the fact that as it stands, it would be way too hard and unnecessary to change, because you would cause an instance where a commit message says one thing, and the TRAC comment says another. I am proposing a new type of value for use in the ticket_change table,"field" column, named "commit". This would be functionally identical to the comment 'field' type, except it will show the reply button (maybe), but remove the edit button from view. It should only be set when using the commit ticket updater plugin, and similar methods. | jsalaz@… | ||
| 9736 | Add an AND operator to ticket query syntax | ticket system | 0.12dev | unscheduled | enhancement | normal | new | 2010-10-31T04:39:14+01:00 | 2011-05-11T02:06:12+02:00 | Add an add operator to ticket query syntax (used for example in macro). Currently it is only possible to do or operator queries. So it is impossible to query for example tickets, which have keywords A and keyword B at the same time. | Mitar | ||
| 9740 | Impossible to CC a username with spaces | ticket system | 0.12-stable | unscheduled | defect | normal | new | 2010-11-01T14:22:20+01:00 | 2010-11-01T16:05:19+01:00 | It is impossible to CC a username with spaces in the username such as "Joe Bloggs", attempting to enter that treats as two different users Joe and Bloggs. Suggest first attempt to establish that usernames separated by commas as known usernames before splitting by spaces for known usernames. | david+trac@… | ||
| 9930 | Allow configuration of ticket query cache time | ticket system | 0.12.1 | unscheduled | enhancement | normal | new | 2010-12-15T11:36:16+01:00 | 2010-12-15T19:46:56+01:00 | The [/query] page stores the query results for one hour in the user session. When the same query is run in this time period the differences are highlighted with italic font. I would like to be able to alter this behavior, either by disabling the cache or by reducing the cache time, which is hard coded as one hour. | Jorrit Schippers <jorrit@…> | ||
| 10018 | no apparent way to make set_owner default to existing owner | ticket system | 0.12-stable | unscheduled | defect | normal | new | 2011-02-09T22:00:51+01:00 | 2012-11-21T00:08:46+01:00 | We are using the custom workflow to manage our tickets and my users want the assignment of the owner to be separate from the promotion of state. For example, we have defined the Work state, which has TICKET_MODIFY permissions and set_owner operation. Here is the problem we are seeing: The owner is assigned when the ticket is created (but sometimes, it may not be assigned until it is moved to Work). If the owner was assigned, then the radio dial that sets Work as the current state also has an owner field that defaults to the current editor, not the current owner. In order to keep the same owner, the editor has to cut and paste it. We would like a way to promote tickets without affecting the owner. | matkinson@… | ||
| 10508 | Support for networkedhelpdesk.org | ticket system | unscheduled | enhancement | normal | new | 2011-12-21T15:01:06+01:00 | 2013-02-04T17:02:06+01:00 | Add Support for the networkedhelpdesk.org initiative. So Trac would work together with other Application and Ticketing systems... See for futher information the Website [http://networkedhelpdesk.org] | michael.imhof@… | |||
| 10698 | Workflow action with non-ascii letters fails to change owner properly | ticket system | 0.12-stable | unscheduled | defect | normal | new | 2012-05-18T13:45:07+02:00 | 2012-05-21T19:29:27+02:00 | Hi, Consider the two workflow actions below : {{{ [ticket-workflow] reassign = * -> * reassign.operations = set_owner,leave_status reassign.set_owner = client,po,team todo = * -> todo todo.operations = set_owner todo.set_owner = client,po,team }}} If i set the owner with reassign action, it works well, as expected. If i use the `toto` action, the owner is set to `client,po,team` literally, even if i select properly `client`. Trac should set the status to `todo` and the `owner` to the one selected. Can you confirm this ? Regards, Étienne | ebersac@… | ||
| 10776 | set custom fields via ticket workflow | ticket system | 0.11.5 | unscheduled | enhancement | normal | new | 2012-07-19T12:19:43+02:00 | 2012-07-19T15:44:42+02:00 | I have two questions which i can't find example how to config them in the trac.ini file. I want to add to the workflow two states but I need them to enable insert data: attachment Picture added {{{ Released in revision _______________ need to add a number of revision. }}} I saw examples like configure a number (like in duplicate) or assigning ticket to other user. But I didn’t see detailed example of how to add text box. I know I have to configure the text under [ticket-custom] but how do I use this configured field: {{{ [ticket-custom] released = text released.label = released in version }}} Do I add under [ticket-workflow] like this? {{{ [ticket-workflow] released = text }}} Thanks, Asaf Levy | asaf.levy@… | ||
| 8135 | [PATCH] Prev, Query, Next links at bottom of ticket page | ticket system | 0.13dev | next-dev-1.1.x | enhancement | normal | reopened | 2009-03-17T19:27:21+01:00 | 2012-06-23T20:08:03+02:00 | When you're viewing a ticket after selecting it from some report/query, there are usually three links at the top of the page saying (roughly): * Previous ticket * Back to Query * Next ticket Is there some way to have these links repeated at the bottom of the page? When updating tickets, most of the work happens at the bottom of the page and it's a pain to keep scrolling to the bottom to do the work, then to the top to click "Next ticket" then back to the bottom again... I tried looking around for some HTML templates that I can edit to achieve this but I got as far as finding that the changes I need to make are probably in ticket/web_ui.py before calling it a day. Can I request this feature be added? Also, if there is a quick hack I can make to my existing (trac 0.11.3) install, I'm all ears... Ta. | srevill@… | ||
| 2616 | Show ticket submission time in Change History | ticket system | 0.9.3 | next-major-releases | enhancement | minor | jonas | reopened | 2006-01-16T20:52:30+01:00 | 2009-04-09T17:52:48+02:00 | It would be very useful if it were easier to figure out the exact date and time of a ticket's submission. Currently it's only shown as e.g. "three months ago" at the detailed ticket view instead of "2005-10-12 15:18". All modifications are shown with the exact second it happened, but not the original creation.[[BR]] I suggest the time of creation is added to the Change History of the ticket view. | johan.levin-atsign-lorensbergs.com | |
| 3734 | Provide Possibility to 'freeze' a Milestone | ticket system | devel | next-major-releases | enhancement | minor | jonas | reopened | 2006-09-16T02:04:54+02:00 | 2010-09-10T14:56:06+02:00 | It should be possibly to flag a milestone as 'freezed', thus no new tickets can be filed. see #3730 for an example-conflict. | ilias@… | |
| 5663 | Suggestions for Ticket Reports | ticket system | next-major-releases | enhancement | minor | nkantrowitz | new | 2007-07-05T21:10:08+02:00 | 2011-05-11T02:15:45+02:00 | One nice feature of the ticketing system at http://versionone.com/ is the ability to edit ''Ticket Properties'' fields in the table view itself, i.e. via dropdowns right there, without having to open each individual ticket. I know this feature would help me. Another idea which would help me is to load at least part of the ''Description'' field (even in a plain text version) onto the report page and then show it to me in a popup when I rollover the ticket. This would also help me, as the ''short summary'' is often not enough to recall the full details. Thanks. | fredthejonester@… | ||
| 7558 | New TracQuery match operator for "contains the word" would be useful | ticket system | 0.11.1 | next-major-releases | enhancement | minor | new | 2008-08-24T04:52:14+02:00 | 2010-10-31T02:35:26+01:00 | In a number of situations, it's useful to be able to search field values that ''contain a certain word'', not just a certain string (as `~=` does). The distinction is essentially a word boundary regex versus an all-inclusive regex. That is, I'd like to be able search like this: {{{ .*\bmyvalue\b.* }}} where `\b` is a "word boundary" as defined by [http://www.pcre.org/pcre.txt the PCRE standards]. Right now, using `~=`, I can only search like this: {{{ .*myvalue.* }}} The most pressing use case for such a facility (at least for my projects) is support for [http://marc.info/?l=trac&m=121936459010029&w=2 "subticket keywords", an extremely flexible technique of associating one ticket with another] by using the TracLinks conventions in the keyword field. For example, to associate a new ticket as a "subticket" of ticket:13, I place `#13` in its keyword field. Currently, this can later be extracted with a TracQuery such as `[[TracQuery(keywords~=#13)]]` however this incorrectly matches `#130`, `#131`, and so on. Thus, a word boundary match operator was [http://marc.info/?l=trac&m=121941561920166&w=2 suggested by Remy Blank later in the same thread]. At first blush, it seems that the TracQuery "mini language" is actually [source:trunk/trac/ticket/query.py@7484:439-444#L437 implemented with simple ANSI SQL-based wildcards], which makes implementing word boundary matches non-trivial. I'd imagine one might have to wrap a call to [source:trunk/trac/ticket/query.py@7484:254-311#L254 Query.execute] that catches the results of a `~=` query and then filters these results further (possibly with a [Wikipedia:Decorator_pattern decorator]?). | meitarm@… | ||
| 8677 | Ability to follow/unfollow a ticket | ticket system | none | next-major-releases | enhancement | minor | new | 2009-09-16T09:05:59+02:00 | 2011-06-07T17:51:05+02:00 | It would be great to be able to start following (receive notifications to email) or stop following any ticket you are watching in one click. This would work for logged in users only of course. | Alexey Timanovsky <timanovsky@…> | ||
| 548 | [Patch] Support for subcomponents | ticket system | devel | next-major-releases | enhancement | normal | jonas | reopened | 2004-06-15T04:44:22+02:00 | 2013-01-27T22:12:21+01:00 | I'd like to request the addition of a subcomponent field. This would be useful for breaking large component pieces into smaller subsets. In particular, the project I'm working on includes a core engine and several plug-in style projects. It makes sense to keep it all in the same svn repository as well as the same trac db. However, with the addition of a subcomponet (or feature or something like that), the granularity of tracking for the plug-in projects would be much better. | acarter24@… | |
| 1395 | Text box for duplicate when a bug is a duplicate | ticket system | devel | next-major-releases | enhancement | normal | reopened | 2005-04-03T13:22:08+02:00 | 2010-05-02T11:33:37+02:00 | There should be a form item for writing the bug number when you mark a ticket as a duplicate. Developers are lazy, they tend to forget stuff, etc. The original bug should get a notice that given bug was marked a dupe of it | ludde | ||
| 2467 | Link user name in reports to custom query showing that user's open tickets | ticket system | 0.9.2 | next-major-releases | enhancement | normal | jonas | new | 2005-12-09T16:46:10+01:00 | 2007-03-08T22:57:04+01:00 | It would be nice if the usernames in the report view linked to custom queries showing active tickets belonging to that user. | earle at downlode dot org | |
| 2497 | Change custom query with group to also have a table of contents for group | ticket system | 0.9.2 | next-major-releases | enhancement | normal | jonas | new | 2005-12-16T19:28:33+01:00 | 2007-04-02T11:26:20+02:00 | If group results option is selected in a custom query it would be nice if the results starts off with a table of contents (TOC) with links to the coresponding table. For example if group by components is selected then list of components should be listed with links to the individual component ticket tables. It may also be good to list the number of tickets that are new, assigned, reopened, and closed for each component in the TOC. | anonymous | |
| 3153 | Include tickets without milestone in iCal | ticket system | 0.9.5 | next-major-releases | enhancement | normal | mgood | new | 2006-05-15T16:53:34+02:00 | 2010-12-07T18:45:10+01:00 | Currently if you wish to download your tickets for a specific project in Ical format that can be read using Mac's Ical (which is what I use). Often I write tickets with no specific milestone on gamedev.acm.cs.rpi.edu and I would like them in the same format as all my other tickets. My request is that the feature enabling me to download milestones to Ical be implimented on the ticket system. | bowenk@… | |
| 3255 | Context-sensitive new ticket prefill | ticket system | none | next-major-releases | enhancement | normal | cboos | reopened | 2006-06-13T00:27:35+02:00 | 2012-06-23T20:30:05+02:00 | I'd like to extend the idea behind a `worksforme`-ed #3253 as follows: it'd be nice to enter a ticket quickly based on the conditions I'm ''looking at'' right now. Example: I create a query for __owner__ ''X'' and __milestone__ ''Y'' using TracQuery. I review the results and decide to add to the workload of ''X'' and create one more task. It'd be great to simply be able to click on a link that says __Create new ticket in this view__ (not a good wording) or something like that. Similarly, and that's what #3253 was proposing, it'd be nice to create a ticket right from the milestone's page that is assigned to this milestone. Or create a ticket assigned to this milestone and a particular component by clicking one of the `[`now imaginary`]` knobs next to one of the __sort by ''component''__ progress bars on the right of the milestone's view. Or by clicking somewhere in the query that results from clicking on this progress bar... You get the idea. Moreover, I actually would prefer the standard __New Ticket__ action to be ''context-sensitive'' as I describe above and always prefill ticket fields for me based on what is in the current page's view. To extend this beyond milestones and queries, when I'm looking at a Wiki page or a commit log or a source code item, and I click __New Ticket__, I'd be glad to see that there's a [wiki:TracLinks TracLink-ified] reference to that object. Maybe that's one of the ideas TracObjectModelProposal is trying to accommodate, but it would need help from Trac on how to ''deduce'' some relations between Trac objects, in this case to help fill out a ticket more quickly. | s.lipnevich@… | |
| 4374 | Custom Tickets Select Box Auto-generation | ticket system | 0.10.2 | next-major-releases | enhancement | normal | jonas | new | 2006-12-11T16:36:37+01:00 | 2010-09-10T11:37:48+02:00 | It would be nice if instead of specifying all the available options for a select box like: option1|option2|option3... in trac.ini, which could run into hundreds, if instead you could specify some kind of query so that this list is automatically generated from the database and keeps up to date. For example, if you had 'is associated with customer' as a select box and the customers are generated from a 'Customers' table in the database. e.g. 'select name from Customer where active=1' so that only customers who are still active (assuming this list changes quite often) are shown in the list. Apologies for the poor example. At the moment I have written a script that reads trac.ini and modifies this manually but it is far from ideal as it only runs once a day so the data isnt always up-to-date | a.rodger@… | |
| 6525 | Disable Submit Ticket Button | ticket system | next-major-releases | enhancement | normal | jonas | new | 2007-12-19T16:02:01+01:00 | 2012-09-13T08:31:44+02:00 | It would be a nice idea to disable the ''Submit ticket'' button until the ''Preview'' button has been clicked. This is similar to editing wikipedia pages and may prevent to many errors in tickets. | anonymous | ||
| 8314 | Dynamic Default Values | ticket system | 0.11-stable | next-major-releases | enhancement | normal | new | 2009-05-22T22:30:53+02:00 | 2010-06-09T11:49:08+02:00 | In the config file, we have options to provide default values for multiple fields. It appears that these can only be string literals though. Is it possible, or easy to implement, a dynamic default value. More specific: The way I have permissions set-up, there are several groups. Each user belongs to one of these groups, and has no other permissions set. I want this group to be the default value for a field, so that we can later sort them by what group/company these tickets originated from. thanks | anonymous | ||
| 8681 | Allow adding usernames to a ticket CC list | ticket system | 0.11.4 | next-major-releases | enhancement | normal | new | 2009-09-22T00:27:26+02:00 | 2012-07-26T20:43:50+02:00 | Allow adding usernames to a ticket CC list instead of e-mail addresses for users which can only select checkbox to add themselves to the CC list (and thus cannot control content). For our setup it would be enough to just add a project-wide configuration switch which would tell Trac whether to prefer usernames or e-mail addresses. | Mitar | ||
| 9445 | Adding new action | ticket system | 0.11 | next-major-releases | enhancement | normal | new | 2010-06-17T13:33:45+02:00 | 2010-06-17T14:15:28+02:00 | I need to give action permission to create/edit component to particular user, without giving TICKET_ADMIN action permission. Means how can I add following permission COMPONENT_ADMIN, COMPONENT_CREATE, COMPONENT_DELETE, COMPONENT_MODIFY. | anonymous | ||
| 7617 | Various ticket fields don't like leading or trailing / | ticket system | 0.11.1 | next-minor-0.12.x | defect | minor | rblank | new | 2008-09-10T23:53:29+02:00 | 2011-09-17T17:03:35+02:00 | As an example, create a milestone where the name either starts or ends with a `/`. It will be visible in the roadmap, but clicking on the link will lead to an error, saying that the milestone cannot be found. The same problem applies to other enumerated fields like components, priorities or versions, when edited in the admin module. The problem is due to the roadmap module creating links to milestones using `req.href.milestone(milestone_name)`, and `href` stripping leading and trailing slashes at [source:branches/0.11-stable/trac/web/href.py@7493:147#L147 this location]. The same analysis applies to the admin module. I'm not sure if the solution is to build the milestone and admin links differently, or to remove the automatic stripping in `Href`. Opinions welcome. | rblank | |
| 7874 | Changing component makes owner "none" while owner should be empty | ticket system | 0.11.1 | next-minor-0.12.x | defect | minor | new | 2008-12-09T11:22:58+01:00 | 2010-05-03T22:13:53+02:00 | I have a set of tickets of type "defect" When an action "add comment" is performed, the ticket is disowned (owner is empty), and status becomes new. The ticket shows up in "new defects", this is exactly as expected. When I change the component of a "defect" ticket, the owner becomes "None" (seen when listing all tickets), the ticket itself shows "new defect". But when the owner is "None" in stead of empty, the ticket does not show up in the "new defects list", while the ticket is a new defect. so: 1) changing the component of "defect" tickets makes it's owner "None" while it should be empty. 2) lisitng "new defect" does not list the new defects with owner "None", only the ones with an empty owner field 3) the "None" owner is seen in the "list all tickets", but when showing http://trac/xx/ticket/<number>, the "owned by" field of a ticket owned by "None" is empty | linuxificator@… | ||
| 9457 | Unsubmitted comments lost after attaching files | ticket system | 0.11.6 | unscheduled | enhancement | minor | new | 2010-06-23T18:04:02+02:00 | 2010-09-30T09:48:22+02:00 | While modifying assigned tickets of mine, I've noticed that if I add comments and then go to attach a file, when I selected the "Back to Ticket#" button at the top of the page, the attachment is saved but my un-submitted comments are erased. Trac should save all modifications in memory until the changes are submitted. | andrew.c.martin@… | ||
| 642 | RSS feed with all events for the tickets in a report | ticket system | 0.7.1 | unscheduled | enhancement | normal | jonas | new | 2004-07-22T00:13:54+02:00 | 2010-09-10T14:47:51+02:00 | To be able to track all changes of the tickets in the for example My Tickets report. | anonymous | |
| 5866 | [patch] Workflow tweak: handle "not-state" transition specifications | ticket system | devel | unscheduled | enhancement | normal | jonas | new | 2007-08-13T15:27:47+02:00 | 2011-03-16T17:43:01+01:00 | I found myself wanting things like this in my [ticket-workflow]: {{{ reassign = * -> * reassign.operations = set_owner,leave_status reassign.permissions = TICKET_MODIFY needinfo = * -> needinfo needinfo.name = need info needinfo.operations = set_owner needinfo.permissions = TICKET_MODIFY }}} ...but this would create two action options for a ticket in the "needinfo" state: "reassign and leave as needinfo", and "assign to new owner and leave as needinfo" ...which are of course the same thing. I wanted to be able to do this instead: {{{ needinfo = *,!needinfo -> needinfo needinfo.name = need info needinfo.operations = set_owner needinfo.permissions = TICKET_MODIFY }}} This would indicate that the "needinfo" state was a valid next state from every other state ''except'' "needinfo". To make this work, make the following tweak to /trac/ticket/default_workflow.py (line 161): {{{ if oldstates == ['*'] or status in oldstates: }}} ...becomes... {{{ if ('*' in oldstates or status in oldstates) and ("!%s"%status not in oldstates): }}} I haven't tested this extensively, and even though it should be backwards-compatible... use with extra initial scrutiny. | Morris | |
| 4636 | Component field sort order doesn't use locale | ticket system | 0.10.3 | next-major-releases | defect | minor | jonas | new | 2007-02-01T11:03:46+01:00 | 2012-04-03T20:36:41+02:00 | The items listed in the ticket drop-down menu for '''Component''' are sorted alphabeticaly. However, this alphabetical sorting '''doesn't use the locale''' setting, an item as ''épargne'' will be at the bottom of the list, instead of being between the items ''crédit'' and ''guichet'' for example. | antoine.delvaux@… | |
| 1069 | query by example (e.g. when creating a new ticket, check for similar tickets) | ticket system | 0.8 | next-major-releases | enhancement | normal | cboos | new | 2004-12-17T15:46:06+01:00 | 2010-09-10T09:01:20+02:00 | There could be some ways to reduce the amount of ''duplicate'' tickets getting created. The simplest way would be to advertise doing a search: E.g (any better english is welcome, of course): === Create New Ticket === ''Have you checked that the issue you want to report was not already raised before? If not, please '''Search''' for existing tickets describing your problem before creating a new one.'' Your email or username: ... ---- A more sophisticated way would be to do a search (in the tickets) based on the content of the ''Short summary'' field and the ''Keywords'' field, when the reporter ''Preview''s his new ticket. The result of the search would also appear on the ticket preview page. From that point, the reporter could choose either to go on with the creation of his new ticket (maybe clarifying what distinguishes it from other, similar tickets), or to contribute to existing similar tickets if some are found and relevant for him. | cboos@… | |
| 1514 | Mantis conversion script | ticket system | next-major-releases | enhancement | normal | cboos | new | 2005-05-06T20:17:11+02:00 | 2010-09-10T09:07:24+02:00 | A script to convert from Mantis(http://www.mantisbt.org/) to Trac would be super-cool! | Paul Baranowski <paul@…> | ||
| 3006 | Want to be able to merge tickets | ticket system | none | next-major-releases | enhancement | normal | cboos | new | 2006-04-09T22:50:38+02:00 | 2011-05-31T21:44:53+02:00 | Rather than marking ticket A as closed and a duplicate of ticket B, it should be possible to mark ticket A as a duplicate of another ''without'' closing it; then when B is closed, A is closed as well, and the resolution message appended to both. | dcrosta | |
| 10352 | Docs do not reflect difference in wiki processing between custom text and textarea fields | ticket system | 0.12.2 | next-minor-0.12.x | defect | minor | new | 2011-09-13T19:01:30+02:00 | 2011-09-13T22:04:15+02:00 | In http://trac.edgewall.org/wiki/TracTicketsCustomFields it is stated that both type=text and type=textarea fields can be set to format=wiki. This is true, but the contents of the two fields are processed differently. Specifically, macros aren't expanded in type=text fields even if they only generate one line of text. The choice to have these two fields behave differently seems to be a conscious choice, following the comments and commits from ticket:1791. This is not consistent with the behavior of built-in fields. Typing a macro into the keywords field will cause the macro to be expanded. I don't really have a problem with the current behavior, but for consistency's sake, either custom type=text fields should behave the same as built-in fields when format=wiki '''or''' the [http://trac.edgewall.org/wiki/TracTicketsCustomFields custom field docs] should be modified to explain that type=text custom fields don't get full wiki processing that built-in fields and custom type=textarea fields get. | jj33@… |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment