Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-897

Custom field default values aren't applied issues created by email

    • Icon: Bug Bug
    • Resolution: Resolved Locally
    • Icon: Low Low
    • None
    • 2.0.2
    • Email - Incoming

      When an issue is submitted by email to the Service Desk mail handler, the default value is not applied to the issue for select lists.

      Steps to reproduce:

      1. Create a custom field called "contact type" that is a select list
      2. Add values of "helpdesk", "email", and "other"
      3. Set default value to be "email"
      4. Submit request by email
      5. View issue and note that custom field value is not the default of "email"

      Expected results:
      The value for "contact type" is email.

      Actual results
      It seems to pick the last value entered in the list of options.

          Form Name

            [JSDSERVER-897] Custom field default values aren't applied issues created by email

            Hi Damon,

            Thanks for the clarification.

            Yes, the field appears to be behaving as expected. In order to address your specific situation, the issue property should be suitable (in place of the custom field) as it can be used in JQL filters / reports / etc for separating issues created from the portal and issues created by email.

            Hope this helps

            Matt

            Matthew McMahon (Inactive) added a comment - Hi Damon, Thanks for the clarification. Yes, the field appears to be behaving as expected. In order to address your specific situation, the issue property should be suitable (in place of the custom field) as it can be used in JQL filters / reports / etc for separating issues created from the portal and issues created by email. Hope this helps Matt

            Hi Matt,

            This bug is indeed JSD-1356 and not related to the issue property searching. I have to revise my previous comment. I DO have the field listed on the customer portal as a hidden field with a default value. How I was hoping it would work is that if someone submits a request through the portal the hidden field value I specified would be used. And then if someone submitted a request through email, it would use the default value for the custom field.

            Given what I said above, do you think it's worthwhile to put in a support ticket? It seems to be behaving how it's supposed to, but doesn't address my unique situation.

            In other news, I've tried and been able to successfully use the issue property to create filters / reports based on the channel, so that was a big win.

            Damon Morda added a comment - Hi Matt, This bug is indeed JSD-1356 and not related to the issue property searching. I have to revise my previous comment. I DO have the field listed on the customer portal as a hidden field with a default value. How I was hoping it would work is that if someone submits a request through the portal the hidden field value I specified would be used. And then if someone submitted a request through email, it would use the default value for the custom field. Given what I said above, do you think it's worthwhile to put in a support ticket? It seems to be behaving how it's supposed to, but doesn't address my unique situation. In other news, I've tried and been able to successfully use the issue property to create filters / reports based on the channel, so that was a big win.

            Hi Damon,

            Is this the bug related to https://jira.atlassian.com/browse/JSD-1356 or the issue property searching?

            Both should now be fixed, however for the custom fields, if the field is added to the Request Type and hidden then you should be asked to select a value that will always be used. Whereas if the field has not been added to the Request Type then it should be using the default value set in JIRA.

            Both of these scenarios should be the same for creating a ticket in the portal or email.

            May I ask if you have had success with using the issue property to create filters / reports based on whether a ticket was created in the portal or email channel?

            At this stage, I think it might be a good idea to create a support ticket at https://support.atlassian.com if the issue persists, and that way we can provide you with support specific to your circumstances and with higher security.

            The credentials should be the same as for this site (https://jira.atlassian.com).

            Thanks
            Matt

            Matthew McMahon (Inactive) added a comment - - edited Hi Damon, Is this the bug related to https://jira.atlassian.com/browse/JSD-1356 or the issue property searching? Both should now be fixed, however for the custom fields, if the field is added to the Request Type and hidden then you should be asked to select a value that will always be used. Whereas if the field has not been added to the Request Type then it should be using the default value set in JIRA. Both of these scenarios should be the same for creating a ticket in the portal or email. May I ask if you have had success with using the issue property to create filters / reports based on whether a ticket was created in the portal or email channel? At this stage, I think it might be a good idea to create a support ticket at https://support.atlassian.com if the issue persists, and that way we can provide you with support specific to your circumstances and with higher security. The credentials should be the same as for this site ( https://jira.atlassian.com ). Thanks Matt

            Hi Matt,

            I've tested the new release (2.3.2) and the bug still appears to be there, at least for my use case. Not sure if it matters, but I don't have the custom field viewable on the customer portal, it's a field only used for tracking purposes and not exposed to the customer.

            Is there something I might be doing wrong?

            Damon Morda added a comment - Hi Matt, I've tested the new release (2.3.2) and the bug still appears to be there, at least for my use case. Not sure if it matters, but I don't have the custom field viewable on the customer portal, it's a field only used for tracking purposes and not exposed to the customer. Is there something I might be doing wrong?

            Hi Matt,

            Thanks for the clarification, we look forward to the new release.

            Damon Morda added a comment - Hi Matt, Thanks for the clarification, we look forward to the new release.

            Hi Damon,

            Sorry for the confusion, I have investigated and discovered that there is a bug around this functionality.

            It has been fixed, and will be in the next Service Desk release. However only new issues created with this version will be searchable.

            Regards
            Matt

            Matthew McMahon (Inactive) added a comment - Hi Damon, Sorry for the confusion, I have investigated and discovered that there is a bug around this functionality. It has been fixed, and will be in the next Service Desk release. However only new issues created with this version will be searchable. Regards Matt

            Hi Matt,

            That solution looks fantastic, we'd love to be able to search on issue properties. However, it doesn't seem to work in my current version of JIRA/JSD. I'm running JIRA 6.3.10 and JSD 2.1.1. Do I need a newer version?

            Damon Morda added a comment - Hi Matt, That solution looks fantastic, we'd love to be able to search on issue properties. However, it doesn't seem to work in my current version of JIRA/JSD. I'm running JIRA 6.3.10 and JSD 2.1.1. Do I need a newer version?

            Hi Damon,

            Thanks for your response.

            Yes, as you mentioned, if the field is hidden on the Customer Portal, when the incoming email is processed by Service Desk it will use the default that was configured for the portal.

            The Channel value does provide this information, as you have also discovered. In order to use this for reports or filters, it will be necessary to go into advanced mode for your queries, and try adding something like the following to your statements.

            issue.property["request.channel.type"].value = "email" // potentially also try simpler form of request-channel-type = email
            issue.property["request.channel.type"].value = "portal" // potentially also try simpler form of request-channel-type = portal
            

            Hope this helps solve your issue, but please let me know if it does not or there are any other problems

            And based on your updated description I will mark this issue as resolved.

            Regards
            Matt

            Matthew McMahon (Inactive) added a comment - Hi Damon, Thanks for your response. Yes, as you mentioned, if the field is hidden on the Customer Portal, when the incoming email is processed by Service Desk it will use the default that was configured for the portal. The Channel value does provide this information, as you have also discovered. In order to use this for reports or filters, it will be necessary to go into advanced mode for your queries, and try adding something like the following to your statements. issue.property["request.channel.type"].value = "email" // potentially also try simpler form of request-channel-type = email issue.property["request.channel.type"].value = "portal" // potentially also try simpler form of request-channel-type = portal Hope this helps solve your issue, but please let me know if it does not or there are any other problems And based on your updated description I will mark this issue as resolved. Regards Matt

            Hi Matt,

            I believe our issue is different. In our case, we want to be able to determine if a request was submitted by email, through the customer portal, or as a result of a phone call where the help desk staff created it on behalf of another customer. We have a custom field called "Contact Type".

            1. Submitted through customer portal - When the user submits it through the customer portal, that field is automatically set to "helpdesk" to indicate the user submitted it through the web portal.
            2. Submitted through email - When a user submits it through email, it was being assigned the "helpdesk" value even though in JIRA we had the default value set to "email".
            3. Created manually - When we create it manually using the create button, we would set that field to "other" to indicate a user came to the help desk physically or called it in.

            So what was confusing was why it was setting the value to "helpdesk" when in JIRA, we had the default value set to "email". Through discussion, I think what we learned is that when it's processed by the Service Desk mail handler it's going to set the value to the what we configured it to set it as in the customer portal, rather than in the JIRA default value.

            So we wanted to the option to set the values depending on which way it came in. Turns out, there is now a "channel" value in recent versions of Service Desk, but we can't seem to figure out how to get at that value to create filters, reports, etc.

            Damon Morda added a comment - Hi Matt, I believe our issue is different. In our case, we want to be able to determine if a request was submitted by email, through the customer portal, or as a result of a phone call where the help desk staff created it on behalf of another customer. We have a custom field called "Contact Type". Submitted through customer portal - When the user submits it through the customer portal, that field is automatically set to "helpdesk" to indicate the user submitted it through the web portal. Submitted through email - When a user submits it through email, it was being assigned the "helpdesk" value even though in JIRA we had the default value set to "email". Created manually - When we create it manually using the create button, we would set that field to "other" to indicate a user came to the help desk physically or called it in. So what was confusing was why it was setting the value to "helpdesk" when in JIRA, we had the default value set to "email". Through discussion, I think what we learned is that when it's processed by the Service Desk mail handler it's going to set the value to the what we configured it to set it as in the customer portal, rather than in the JIRA default value. So we wanted to the option to set the values depending on which way it came in. Turns out, there is now a "channel" value in recent versions of Service Desk, but we can't seem to figure out how to get at that value to create filters, reports, etc.

            Hi dgm

            I have been able to reproduce a symptom similar to what you describe in the case where a custom field (select list for example) is added as a visible & optional field to a Service Desk request type.

            In this scenario, submitting an issue through email fails to attach any value to this field.

            If you are able to reply and confirm that this is the issue you describe, that would be great. However if this is not the same issue, it would be beneficial if you could please describe the steps to reproduce again.

            Regards
            Matt
            Service Desk developer

            Matthew McMahon (Inactive) added a comment - Hi dgm I have been able to reproduce a symptom similar to what you describe in the case where a custom field (select list for example) is added as a visible & optional field to a Service Desk request type. In this scenario, submitting an issue through email fails to attach any value to this field. If you are able to reply and confirm that this is the issue you describe, that would be great. However if this is not the same issue, it would be beneficial if you could please describe the steps to reproduce again. Regards Matt Service Desk developer

              mmcmahon Matthew McMahon (Inactive)
              664f0d27baf2 Damon Morda
              Affected customers:
              0 This affects my team
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: