Service Desk ticket opened via email but fields aren't populated via @commands
We have an internal application sending an email to a queue on our kbox. A ticket gets opened but the 4 fields we’re trying to populate via @COMMAND= do not populate as expected. If I forward the same email, with the 4 commands at the top of the body of the email, a ticket is opened with the appropriate fields populated.
How can I troubleshoot this from the kbox side?
On another note - why are the NO 'Question Topics' regarding Help Desk, SQL, Ticket Rules, etc. . .
Answers (2)
A mangled email is an email that is coming into the helpdesk as a ticket comment where the entry is mangled with special characters and HTML tags or cut off before the end of the email This is caused because kbox helpdesk supports plain-text email using unicode characters. Any email coming from sources that do not provide a plain-text copy of that email can cause emails that are mangled. Also any email using charsets that are not Unicode compatible will be translated incorrectly and could cause truncation of the message or different characters to appear. You will have to do one or both of the following: • Change your mail client to send in Unicode characters (consult your email program's documentation) • Change your mail client or mail server to convert SMTP bound email to include a plain text copy.
It's likely that the user submitting that ticket does not have permissions to set those fields. This does not mean they have to be an owner, but the default permissions are "Owners Only" on most fields.
Change the permissions for each queue by clicking on helpdesk->configuration->queues->[queuename]->ticket fields and layout
Comments:
-
Thanks for the quick reply Gerald.
The Submitters to this queue are restricted by label. The account created for the application has the label assigned to it. Since the ticket is being opened via email and it list the 'application user account' as the Submitter I'm at a loss as to why the @commands aren't populating the fields. I'm trying to set the DUE_DATE, SUBMITTER, CUSTOM_3 and CUSTOM_4 fields. CUSTOM_3 is a blank text field that should except anything I send and the CUSTOM_4 data matches 1 of 3 choices for the Single Select values. - jmarotto 11 years ago -
As a follow up. . .I double checked the Permissions for those fields and found them to be set User Modify. I changed them to User Create because I'm not sure of the differences between the two. Will do some testing now. - jmarotto 11 years ago
-
User Create - Lets the user chose an option but then can not go back and change it
User Modify - Lets the user go back into a ticket and change a field if they picked the wrong category, custom field...etc
I don't know about the custom fields working in that manner but if GillySpy indicates it should then I would go by his word. - nshah 11 years ago
We had 6 tickets opened during the application's overnite run. The four fields didn't populate again.
The queue has Submitters, Approvers and Owners restricted by label, and Accept email from unknown users - not enabled.
The user account created for the application is in the appropriate label and is assigned as the submitter upon receipt of the email. The fields we're trying to set have permissions of User Create.
After setting my Role and the labels on my account to match those of the 'application user' I can send the same commands in an email to the queue and the fields are populated correctly. This leads me back to - there is something about the email being sent the KBOX doesn't like/understand. If I contact KACE support will they be able to look to see what is being received by the KBOX?
Comments:
-
This issue has been resolved. The web-service application, generating the email sent to the kbox, was sending a format not compatible with the device. - jmarotto 11 years ago