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@…