id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc,branch,changelog,apichanges,internalchanges 2464,Conditional fields in tickets,johan.regnell@…,Christian Boos,"Not necessarily all possible fields should be presented to the user. There could be preconditions attached to fields, for checking if they're applicable at all and for checking if the current user can actually set/modify them. Then, as an advanced case, instead of being an all or nothing situation, the possible content of one field could be dependent on the ticket state: see #1299, #2752 and [#comment:13]. === Use cases === ==== Ability to have different ticket fields for different ticket types ==== ''(original one)'' When using quite different types of tickets (bug-report, requirement, etc), there is a need for different fields depending on the ticket type. This might add just the flexibility required for complying with existing development processes. Great feature in particular when support for master and child tickets is planned, trac could be more of a requirements management system beyond the issue database approach. See also duplicates: #4028, #4643 ==== Abilty to have different ticket fields for different ticket components ==== As for ticket types, but for components. See #2752 ==== Hide the ''Keywords:'' field ==== See #3281 ==== Hide some fields for new tickets ==== See #1580. This could be achieved quite simply by putting the ticket `id` in the condition. ",enhancement,new,normal,next-major-0.1X,ticket system,0.9.2,major,,tracobject tickettype conditional custom field,hw@… erikand@… sam@… mark.dodgson@… dartar@… ryan@… hans.westerveen@… colin.white@… mmitar@… itamarost@… admiralnemo@… ryano@… sam.halliday@… martin.wagner@…,,,,