Opened 12 years ago
Closed 7 years ago
#10811 closed enhancement (duplicate)
Admin editor/page for "select" Custom Fields
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | |
Severity: | normal | Keywords: | custom fields |
Cc: | osimons, Steffen Hoffmann, Ryan J Ollos | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I would love to see an editor in the admin section, similar to milestone/component/priority, for custom fields which are marked "select".
Currently, the admin has to place the list of selectable options into the trac.ini and there is no additional data that can be associated to individual entries beyond "label" (and the ordering).
It would be brilliant to be able to associate extra information to a custom field entry, such as a start/end date. For example, I have created a "workpackage" field and I'd like to be able to add a start/end date to entries, very much like is currently possible for "Milestone"s.
In addition, if a user creates a "Milestone" (e.g. calling it "Deliver") then a page appears at "/milestone/Deliver". It would be good if custom fields produced similar pages, which could be edited with wiki syntax and based on a PageTemplate of the field's name (automatically selected if the page doesn't exist yet, but the field entry does). Obviously, one could expect many query macros to appear here and the ParameterisedPageTemplates plugin would be useful to many people wishing to customise the pages further.
Attachments (0)
Change History (9)
comment:1 by , 12 years ago
Cc: | added |
---|
comment:2 by , 12 years ago
Thanks for the info and link!
I have thought about using milestones, but they just don't make sense. I want the tools I use to reflect the practices (rather than the other way around) and a work package is a fundamental part of the projects I run - a work package could span several milestones. I'm admittedly, not exclusively running software development projects.
I'm likely to get involved with plugin development, so maybe I could do this as part of a very personalised plugin to get me started.
follow-ups: 4 8 comment:3 by , 12 years ago
How about this minor request: if a custom field is marked as "select" and there are no entries, then don't show it in new tickets.
comment:4 by , 12 years ago
Replying to anonymous:
How about this minor request: if a custom field is marked as "select" and there are no entries, then don't show it in new tickets.
+1, if this is not already the current behavior (did not test that yet). This would reflect the same behavior as known for standard ticket fields like component, milestone, severity or version.
I suggest to adjusted this ticket's description to reflect that, because I'm with osimons about the current state of the request: Anything (else) is just too specific to hope for an implementation sooner or later, if ever.
comment:5 by , 12 years ago
Cc: | added |
---|
comment:6 by , 12 years ago
Milestone: | → next-major-releases |
---|
comment:7 by , 11 years ago
Cc: | added |
---|
comment:8 by , 7 years ago
comment:9 by , 7 years ago
Milestone: | next-major-releases |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
Duplicate of #11469. The ICustomFieldTypeProvider
discussed in that ticket may be relevant to implementing "workpackage" in a plugin.
I've made a Custom Field Admin plugin, it provides the ability to edit any aspect of custom fields supported by default Trac. It provides an intuitive front-end to updating the config
[ticket-custom]
section.trac-hacks.org is currently down, but I have a Mercurial mirror of my plugin here: https://bitbucket.org/osimons/trac-customfieldadmin
Your request to make custom fields behave like milestones is something completely different, and something that will require major changes to the Trac ticket system. I find it unlikely that the current custom fields system will evolve to anything like your 'super-field' need.
However if 'workpackage' is how you seem to structure your work, the natural question is why not just use Milestones instead? If your release versions or whatever are more light weight, you can just use a basic custom field for this marker? Using milestones as sprints is quite common, and by also including inline ticket queries in Milestone description you can provide quite advanced information about status and progress for any 'workpackage'.