Details
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
Field | Original Value | New Value |
---|---|---|
Fix Version/s | 3.0.0.b3 [ 10207 ] | |
Fix Version/s | 3.0.0.b2 [ 10206 ] |
Fix Version/s | 3.0.0.b4 [ 10208 ] | |
Fix Version/s | 3.0.0.b3 [ 10207 ] |
Fix Version/s | 3.0.0.b5 [ 10209 ] | |
Fix Version/s | 3.0.0.b4 [ 10208 ] |
Fix Version/s | 3.0.0.b6 [ 10210 ] | |
Fix Version/s | 3.0.0.b5 [ 10209 ] |
Fix Version/s | 3.0.0.b7 [ 10211 ] | |
Fix Version/s | 3.0.0.b6 [ 10210 ] |
Fix Version/s | 3.1.0 [ 10001 ] | |
Fix Version/s | 3.0.0.b7 [ 10211 ] | |
Priority | Minor [ 4 ] | Major [ 3 ] |
Sprint | Sprint 1 [ 1 ] |
Fix Version/s | 3.2.0 [ 10002 ] | |
Fix Version/s | 3.1.0 [ 10001 ] |
Rank | Ranked higher |
Fix Version/s | 3.3.0 [ 10100 ] | |
Fix Version/s | 3.2.0 [ 10002 ] |
Security | Private [ 10000 ] |
Fix Version/s | 3.3.0-b2 [ 10507 ] | |
Fix Version/s | 3.3.0-b1 [ 10100 ] |
Fix Version/s | 3.4.0 [ 10400 ] | |
Fix Version/s | 3.3.0-b2 [ 10507 ] |
Fix Version/s | 3.5.0 [ 10401 ] | |
Fix Version/s | 3.4.0 [ 10400 ] |
Fix Version/s | 3.5.0-b2 [ 10701 ] | |
Fix Version/s | 3.5.0-b1 [ 10401 ] |
Fix Version/s | 4.0.0 [ 10603 ] | |
Fix Version/s | 3.5.0-b2 [ 10701 ] |
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. |
Fix Version/s | 4.0.0 [ 10603 ] |
Rank | Ranked higher |
Rank | Ranked higher |
Rank | Ranked higher |
Rank | Ranked higher |
Rank | Ranked higher |
Rank | Ranked higher |
Rank | Ranked lower |
Rank | Ranked lower |
Assignee | Tyson Phillips [ tyson ] |
Fix Version/s | 5.4.0-b1 [ 11719 ] |
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 ] |
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. |
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 ] |