Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue with requiring category on ticket close #11

Closed
cplante opened this issue Nov 2, 2016 · 12 comments
Closed

Issue with requiring category on ticket close #11

cplante opened this issue Nov 2, 2016 · 12 comments
Assignees
Labels
Milestone

Comments

@cplante
Copy link

cplante commented Nov 2, 2016

I’ve been working today to resolve an issue with requiring a category on ticket close. We are using the app Help Desk PowerPack.

Current Settings in Help Desk PowerPack:
Required on Close: Category
Required on: Close, Close as Duplicate

Current Custom Attributes:
Comma is listed first which gives us a blank field in the drop down of category.

When creating a ‘New Ticket’ this works with no issues. If I attempt to close the ticket I get the popup that requires a category to be assigned. This is what we want.

The problem is when sending emails to create tickets to helpdesk@ourdomain.com. The new tickets come in as unspecified but we can close without assigning a category and do not receive the popup. In order to receive the popup that the ticket must have a category I have to select the blank field under the category to trigger the correct response.

Our end goal is to prevent any tickets to be closed without a custom category assigned.

@michaelmaw michaelmaw self-assigned this Jan 2, 2017
@michaelmaw
Copy link
Owner

Sorry for the delayed response - my account was not sending me email notifications from GitHub for some reason.

HDPP should recognize "Unspecified" as an blank value. When you create a ticket using "New Ticket" does it show a value other than "Unspecified" for the Category field?

@efarand
Copy link

efarand commented Mar 16, 2017

Hi Michael,

I'm having the exact same problem that cplante described. If we create a new ticket from the Spiceworks interface using "New Ticket", the category shows up as "Unspecified" and everything works fine (people can't close the tickets without a category). However, if the ticket is created by sending an e-mail, the category also shows as "Unspecified" but we are able to close the ticket even though we didn't specify the category (still shows as "unspecified").

The problem starting happening after we upgraded to a newer version of Spiceworks and also upgraded to a newer version of HDPP at the same time.

@michaelmaw
Copy link
Owner

@efarand How are you closing the ticket? Are you closing it by click "Close" in the Help Desk, or by send an email with the ticket command "#close"?

@efarand
Copy link

efarand commented Mar 16, 2017

Closing it by clicking the "Close" button in the Help Desk.

@cplante
Copy link
Author

cplante commented Mar 16, 2017 via email

@michaelmaw
Copy link
Owner

Interesting. I'm not seeing that issue on my end with email tickets. Technically, there should be no difference in the GUI between an "emailed" ticket and a ticket created in the app from a coding perspective.

If you click the "Category" dropdown field on a ticket, do you actually have an option called "Unspecified"? You shouldn't - it should just be a blank option and then SW would fill in "Unspecified" as the value once you select it.

@efarand
Copy link

efarand commented Mar 20, 2017

In the drop down field, there is no "Unspecified" category. There is only a blank option at the top. The other strange thing is that for those tickets that were created by e-mail and that we are allowed to close even if it says "Unspecified" in the Category field, if I go and manually change the category and chose the Blank field at the top, then after doing that, it starts working and I can't close the ticket anymore (which is what we want). So, for some reason, when the ticket is created by the e-mail, there's something that doesn't work quite right in the category assignment.

As a reference, we use Microsoft Exchange as our email server but in the incoming email setting for Spiceworks we use the IMAP option instead of Exchange . This is something we had to do because of formatting bugs in Spiceworks when using Exchange. Don't know if this is the reason why you're having different results than me in your tests. I'll try and do a couple tests on a test server here by rolling back to a previous version of HDPP and see if the problem appears with the older version and some tests using Exchange incoming mail instead of IMAP. I'll let you know the results.

@cplante
Copy link
Author

cplante commented Mar 20, 2017 via email

@efarand
Copy link

efarand commented Mar 20, 2017

Okay, after a whole bunch of testing, here are the results I came up with.

If I roll back to previous versions of the HDPP plugin, it starts working again on version 3.1 . Version 3.2, 3.3 and 3.4 have the problem but 3.1 works. Something must have changed between 3.1 and 3.2 that created this particular bug.

After a whole bunch of other tests, I decided to look at what is happening in the Spiceworks database itself. As mentioned before, whether I create the ticket by e-mail or from the Spiceworks interface, when I look at the Category field in Spiceworks, both of them say "Unspecified" but one of them I can close and the other I can't close.

When I opened the Spiceworks database with a SQLite browser I noticed that even though they both say "Unspecified" when viewing the tickets in Spiceworks, in the database itself, under the Category field, one of them says "Unspecified" and for the other, the field is blank.

The ticket that was created from the Spiceworks interface shows up as blank in the database and the ticket that was created by e-mail shows up as Unspecified even though we have no category called "Unspecified" in our list of Categories. Is it possible that version 3.1 of the plugin accepted both a blank field and "Unspecified" and starting with version 3.2 only a blank field is accepted?

You also mentioned that you couldn't replicate the problem on your end. What version of Spiceworks are you running? It's possible that this was a change in behaviour in Spiceworks itself. For your info, I'm running 7.5.00098.

@michaelmaw
Copy link
Owner

@efarand This info is extremely helpful. Thanks for taking the time to test this and look into your database. I believe I know the issue now, and will test on my end so that this bug can be fixed in the next release (which I hope to have released soon).

@efarand
Copy link

efarand commented Mar 21, 2017

Not a problem! It's the least I can do since you've got a great plug-in that adds some much needed features to Spiceworks. Thank you for your work and looking forward to that new release!

@michaelmaw michaelmaw added this to the v3.5 Release milestone Mar 21, 2017
@michaelmaw michaelmaw added the bug label Mar 21, 2017
@michaelmaw
Copy link
Owner

Issue fixed in 663b098

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants