Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.0.0.b1
    • Fix Version/s: 5.4.0-b1
    • 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 should 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.

      1/5/22 additional thoughts

      Break the New/Edit Department form into 2 tabs. Existing content goes into the "General" tab. Add a new tab called "Custom Fields"
      Under the "Custom Fields" tab, custom fields can be created and sorted. Custom fields will then appear when creating a ticket within the department for both clients and staff, unless the field visibility is staff only.

      Label (Field name that is displayed)
      Description (Field description that is displayed above the field, if provided)
      Name (The internal name for the field, perhaps auto-generate this based on the label, as all lower-case, no spaces)
      Visibility: (Drop down: Client and Staff, Staff Only. Staff will always be able to see fields, clients will only be able to see if this is set to "Client and Staff". If "Client can Add" is NOT checked, staff could add the data, after which the client could see it.)
      Type (Field type dropdown, copy from Configurable Options)
      Client can Add (Checkbox, client can see the field and submit)
      Encrypted? (checkbox, encrypt submitted data if checked. Data will then ONLY be visible to staff, clients will see a message that "This data is encrypted and cannot be displayed" or similar)
      Delete Encrypted Field Data on Ticket-Close? (Show if Encrypted is checked. If a ticket is closed, the encrypted field data can be optionally deleted on close. It will then no longer be viewable by staff)

      This tab should show a drag-n-drop table of existing fields to sort them, with options to edit and delete, and a [+] button to add a new option. By default there will be no fields, so a form with a message that no fields exist would be shown, and a button in the upper right to create a new field.

      We may want to pass custom field data to email templates but not show by default in the emails. Fields that are set to encrypted would not be decrypted for the email so if they were included they would appear as simply the raw encrypted data and be undecipherable.

      Custom fields would appear below the drag-n-drop file upload and the "Open Ticket" or "Update Ticket" button, essentially last, in the order displayed.

      If a field is deleted, we may want to delete all the data for the field, advising the user that this is what will happen and that if they prefer to just not use the field anymore but keep the data they can change the visibility. When editing a field, if it has been used, do not allow the field "Name" to be changed, as this will probably be used as a key for fetching the field data when viewing the ticket.

        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.).
        Hide
        admin Paul Phillips added a comment -

        I bumped this into 5.4.0-b1, we should review and discuss. This is being requested more and more and is something we actually need ourselves.

        Show
        admin Paul Phillips added a comment - I bumped this into 5.4.0-b1, we should review and discuss. This is being requested more and more and is something we actually need ourselves.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:
              Fix Release Date:
              13/Apr/22

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 2 weeks, 1 day, 4 hours, 55 minutes
              2w 1d 4h 55m

                Agile