Help Needed : Dynamically Displaying Type-Specific Fields in a Centralized Ticket Doctype

ERPNext
1

Hello Frappe Community,

I’m currently building a Ticketing System in Frappe and I’d appreciate your advice on the best architectural approach for handling type-specific fields. Here’s the scenario:

  • I have a main “Ticket” doctype that stores general information common to all tickets:

    • Fields: subject, description, priority, ticket_type, status, workflow_state, customer, SLA deadlines, etc.
    • The Ticket doctype also manages global workflows and SLAs.

  • However, each ticket_type represents a different category of ticket with its own unique fields and logic. For example, “Account Opening Verification” might have fields like email_check, address_check, dob_check, while “Call Verification for Segment Activation” could have segment_check, call_attempts, etc.

What I Want to Achieve:

  • When the user creates or edits a Ticket and selects a ticket_type, I want the form to dynamically display (and allow editing of) the fields that are specific to that type.
  • These type-specific fields should be stored in a maintainable way, ideally without having to add all possible fields for all ticket types into the main Ticket doctype itself (which would cause bloat and complexity).
  • I’d like a modular solution: easily add or change ticket types and their fields without constantly altering the main Ticket doctype schema.
  • Validations and workflow transitions (on the main Ticket doctype) should be able to reference these type-specific fields as needed.
  • The ultimate goal is a clean, scalable, and user-friendly form that adapts based on the selected ticket_type.

Approaches I’m Considering:

  1. Separate Linked Doctypes per Ticket Type:

    • For each ticket_type, create its own doctype holding just the fields relevant to that category.
    • On selecting a ticket_type in Ticket, fetch or create the linked doc for that type and display its fields on the Ticket form using a client script (e.g., via an HTML field or a child table).

  2. One Ticket Type child Doctype:

    • A Ticket Type doctype that stores metadata about which fields should appear for that type.
    • When ticket_type is chosen, dynamically render these fields from child table.
    • Possibly store values in a child table, in the main Ticket record.

  3. Show/Hide Fields in the Main Ticket Doctype:

    • A simpler but less modular approach where all fields are placed in the main Ticket doctype and shown or hidden based on ticket_type.
    • Less desirable as I have many ticket types and this would quickly become unmanageable.

Questions:

  • Has anyone implemented a similar pattern and can recommend a robust approach?
  • Are there best practices or known patterns in Frappe for dynamically rendering and managing type-specific fields that are not initially part of the main doctype?
  • Should I lean towards a JSON/child table approach, or a separate linked doctype for each ticket type, and why?
  • How might I best integrate these dynamically displayed fields into workflow validations and SLA logic?

Any insights, examples, or pointers to existing solutions would be greatly appreciated. I want to ensure that the final solution is both maintainable for developers and intuitive for end-users.

Thank you in advance for your suggestions!