Details

    • Type: New Feature
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0.0.b1
    • Fix Version/s: None
    • Component/s: Plugins
    • Labels:
      None

      Description

      Add custom fields on a per-department basis. Custom fields appear when creating new tickets and may request misc information. Fields may be required, and may need to be stored encrypted.

      Along with encryption, we may want to have a checkbox that says "Delete this data when ticket is closed?".. so for something like sensitive encrypted passwords, the data can be deleted automatically when the ticket is closed.

        Activity

        Hide
        admin Paul Phillips added a comment -

        A lot of people request, and Blesta 2.x supported a drop down where the affected service could be selected.

        Not everyone will want this, so I think it makes sense to add this via a custom field. One of the custom field options when selecting field type (dropdown, checkbox, etc) could be "Service Dropdown", which will automatically render a dropdown with the clients services listed with the label provided for the custom field.

        Show
        admin Paul Phillips added a comment - A lot of people request, and Blesta 2.x supported a drop down where the affected service could be selected. Not everyone will want this, so I think it makes sense to add this via a custom field. One of the custom field options when selecting field type (dropdown, checkbox, etc) could be "Service Dropdown", which will automatically render a dropdown with the clients services listed with the label provided for the custom field.
        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        The support manager already contains a service field in the database for a ticket to reference, which currently is not used. I don't see the point in having that as a custom field as well.

        Show
        tyson Tyson Phillips (Inactive) added a comment - The support manager already contains a service field in the database for a ticket to reference, which currently is not used. I don't see the point in having that as a custom field as well.
        Hide
        admin Paul Phillips added a comment -

        The custom field allows admins to add it to the department, so that it's not hard-coded and always displayed when some people do not want it to appear.

        Show
        admin Paul Phillips added a comment - The custom field allows admins to add it to the department, so that it's not hard-coded and always displayed when some people do not want it to appear.
        Hide
        cody Cody Phillips (Inactive) added a comment -

        I think it's important that the service ID field not be treated as a custom field in the backend. It's so much more efficient being an actual field.

        I think when creating/editing a custom field, the option to choose service (as a type of field) could just use the service_id field already in existence in the database.

        Show
        cody Cody Phillips (Inactive) added a comment - I think it's important that the service ID field not be treated as a custom field in the backend. It's so much more efficient being an actual field. I think when creating/editing a custom field, the option to choose service (as a type of field) could just use the service_id field already in existence in the database.
        Hide
        admin Paul Phillips added a comment -

        I don't care how it works on the back-end, I just don't want the service dropdown to appear unless it's been added by staff to the department. In terms of the UI, it makes sense for this to occur under custom fields.

        Show
        admin Paul Phillips added a comment - I don't care how it works on the back-end, I just don't want the service dropdown to appear unless it's been added by staff to the department. In terms of the UI, it makes sense for this to occur under custom fields.
        Hide
        tyson Tyson Phillips (Inactive) added a comment -

        That sounds doable. How should the services be listed? Where on the ticket? Some modules may not set a label for a service, so it may be difficult for someone to differentiate multiple services of the same type in the drop-down, like universal module products.

        I assume the custom fields will be editable by admin (and maybe client?) when editing the ticket? What other settings should exist to manage the fields, if any? e.g. universal module products

        So far,

        • Label
        • Name (backend key, basically)
        • Input type (text, checkbox, drop-down, etc.)
        • Required
        • Encrypt
        • Values

        Assigning a service would be a special custom field named "service_id", cannot be encrypted (or encryption is ignored), and must be a drop-down.

        Show
        tyson Tyson Phillips (Inactive) added a comment - That sounds doable. How should the services be listed? Where on the ticket? Some modules may not set a label for a service, so it may be difficult for someone to differentiate multiple services of the same type in the drop-down, like universal module products. I assume the custom fields will be editable by admin (and maybe client?) when editing the ticket? What other settings should exist to manage the fields, if any? e.g. universal module products So far, Label Name (backend key, basically) Input type (text, checkbox, drop-down, etc.) Required Encrypt Values Assigning a service would be a special custom field named "service_id", cannot be encrypted (or encryption is ignored), and must be a drop-down.
        Hide
        cody Cody Phillips (Inactive) added a comment -

        Assigning a service would be a special custom field named "service_id", cannot be encrypted (or encryption is ignored), and must be a drop-down.

        I think it makes sense to make the input type "service". Then the user simply selects "service" and the Plugin auto populates it as a select menu, appropriately named, with all of the client's non-canceled services.

        Of course, when viewing a ticket the service select menu would need to also contain the selected service even if it was canceled (as we may be digging through an old ticket but still want to see that reference.).

        Show
        cody Cody Phillips (Inactive) added a comment - Assigning a service would be a special custom field named "service_id", cannot be encrypted (or encryption is ignored), and must be a drop-down. I think it makes sense to make the input type "service". Then the user simply selects "service" and the Plugin auto populates it as a select menu, appropriately named, with all of the client's non-canceled services. Of course, when viewing a ticket the service select menu would need to also contain the selected service even if it was canceled (as we may be digging through an old ticket but still want to see that reference.).

          People

          • Assignee:
            Unassigned
            Reporter:
            admin Paul Phillips
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Agile