Details
New Feature
Major
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
Paul Phillips
created issue -
Paul Phillips
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 3.0.0.b3 [ 10207 ] | |
| Fix Version/s | 3.0.0.b2 [ 10206 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.0.0.b4 [ 10208 ] | |
| Fix Version/s | 3.0.0.b3 [ 10207 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.0.0.b5 [ 10209 ] | |
| Fix Version/s | 3.0.0.b4 [ 10208 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.0.0.b6 [ 10210 ] | |
| Fix Version/s | 3.0.0.b5 [ 10209 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.0.0.b7 [ 10211 ] | |
| Fix Version/s | 3.0.0.b6 [ 10210 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.1.0 [ 10001 ] | |
| Fix Version/s | 3.0.0.b7 [ 10211 ] | |
| Priority | Minor [ 4 ] | Major [ 3 ] |
Paul Phillips
made changes -
| Sprint | Sprint 1 [ 1 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.2.0 [ 10002 ] | |
| Fix Version/s | 3.1.0 [ 10001 ] |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Fix Version/s | 3.3.0 [ 10100 ] | |
| Fix Version/s | 3.2.0 [ 10002 ] |
Paul Phillips
made changes -
| Security | Private [ 10000 ] |
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.
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. 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.
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. 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.
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. 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.
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. 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.
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. 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.).
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.). Paul Phillips
made changes -
| Fix Version/s | 3.3.0-b2 [ 10507 ] | |
| Fix Version/s | 3.3.0-b1 [ 10100 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.4.0 [ 10400 ] | |
| Fix Version/s | 3.3.0-b2 [ 10507 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.5.0 [ 10401 ] | |
| Fix Version/s | 3.4.0 [ 10400 ] |
Paul Phillips
made changes -
| Fix Version/s | 3.5.0-b2 [ 10701 ] | |
| Fix Version/s | 3.5.0-b1 [ 10401 ] |
Paul Phillips
made changes -
| Fix Version/s | 4.0.0 [ 10603 ] | |
| Fix Version/s | 3.5.0-b2 [ 10701 ] |
Paul Phillips
made changes -
| 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. |
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. |
Paul Phillips
made changes -
| Fix Version/s | 4.0.0 [ 10603 ] |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked higher |
Paul Phillips
made changes -
| Rank | Ranked lower |
Paul Phillips
made changes -
| Rank | Ranked lower |
Paul Phillips
made changes -
| Assignee | Tyson Phillips [ tyson ] |
Paul Phillips
made changes -
| Fix Version/s | 5.4.0-b1 [ 11719 ] |
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.
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. Paul Phillips
made changes -
| 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. |
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. 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) 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. |
| Rank | Ranked higher |
| Rank | Ranked higher |
| Rank | Ranked lower |
| Sprint | 3.1 [ 1 ] | 3.1, 5.4.0 Sprint 1 [ 1, 148 ] |
| Rank | Ranked lower |
| Sprint | 3.1, 5.4.0 Sprint 1 [ 1, 148 ] | 3.1, 5.4.0 Sprint 2 [ 1, 149 ] |
| Rank | Ranked higher |
| Story Points | 13 |
| Assignee | Abdy Franco [ abdy ] |
Paul Phillips
made changes -
| 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. 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) 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. |
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) 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. |
Paul Phillips
made changes -
| 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) 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. |
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. |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Remaining Estimate | 0 minutes [ 0 ] | |
| Time Spent | 1 hour, 28 minutes [ 5280 ] | |
| Worklog Id | 15570 [ 15570 ] |
| Time Spent | 1 hour, 28 minutes [ 5280 ] | 2 hours, 9 minutes [ 7740 ] |
| Worklog Id | 15574 [ 15574 ] |
| Time Spent | 2 hours, 9 minutes [ 7740 ] | 1 day, 1 hour, 53 minutes [ 35580 ] |
| Worklog Id | 15575 [ 15575 ] |
| Time Spent | 1 day, 1 hour, 53 minutes [ 35580 ] | 2 days, 1 hour, 46 minutes [ 63960 ] |
| Worklog Id | 15576 [ 15576 ] |
| Time Spent | 2 days, 1 hour, 46 minutes [ 63960 ] | 3 days, 1 hour, 42 minutes [ 92520 ] |
| Worklog Id | 15577 [ 15577 ] |
| Time Spent | 3 days, 1 hour, 42 minutes [ 92520 ] | 4 days, 1 hour, 37 minutes [ 121020 ] |
| Worklog Id | 15578 [ 15578 ] |
| Time Spent | 4 days, 1 hour, 37 minutes [ 121020 ] | 1 week, 1 hour, 31 minutes [ 149460 ] |
| Worklog Id | 15579 [ 15579 ] |
| Time Spent | 1 week, 1 hour, 31 minutes [ 149460 ] | 1 week, 1 day, 2 hours, 46 minutes [ 182760 ] |
| Worklog Id | 15580 [ 15580 ] |
| Time Spent | 1 week, 1 day, 2 hours, 46 minutes [ 182760 ] | 1 week, 2 days, 4 hours, 39 minutes [ 218340 ] |
| Worklog Id | 15584 [ 15584 ] |
| Sprint | 3.1, 5.4.0 Sprint 2 [ 1, 149 ] | 3.1, 5.4.0 Sprint 2, 5.4.0 Sprint 3 [ 1, 149, 152 ] |
| Rank | Ranked higher |
| Time Spent | 1 week, 2 days, 4 hours, 39 minutes [ 218340 ] | 1 week, 3 days, 6 hours, 33 minutes [ 253980 ] |
| Worklog Id | 15587 [ 15587 ] |
| Time Spent | 1 week, 3 days, 6 hours, 33 minutes [ 253980 ] | 2 weeks, 36 minutes [ 290160 ] |
| Worklog Id | 15589 [ 15589 ] |
| Time Spent | 2 weeks, 36 minutes [ 290160 ] | 2 weeks, 5 hours, 53 minutes [ 309180 ] |
| Worklog Id | 15590 [ 15590 ] |
| Status | In Progress [ 3 ] | In Review [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Time Spent | 2 weeks, 5 hours, 53 minutes [ 309180 ] | 2 weeks, 6 hours, 21 minutes [ 310860 ] |
| Worklog Id | 15596 [ 15596 ] |
| Time Spent | 2 weeks, 6 hours, 21 minutes [ 310860 ] | 2 weeks, 1 day [ 316800 ] |
| Worklog Id | 15601 [ 15601 ] |
| Time Spent | 2 weeks, 1 day [ 316800 ] | 2 weeks, 1 day, 4 hours, 55 minutes [ 334500 ] |
| Worklog Id | 15605 [ 15605 ] |
| Status | In Review [ 5 ] | Closed [ 6 ] |
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.