Add ticket system support

[william-sy]

Hi,

I was playing with this bot and wonderd if it was possible to add a 'ticket' command in the ack style. or as a extra question to the ack command do you want a ticket?

It would be great to call a python script with a name like send_ticket.py with arguments: host service state

the first argument would be the subject
the second and third arguments would be the description like:
f"Service: {var1} State: {var2}"

With that we can send it towards Fresh service. We don't want Icinga to do this as it would just be creating too many tickets.

Help would be appreciated. Or if it could become a feature out of the box would just be superb!
I can imagine adding every ticket sollotion in the world would be too much to ask but this way users could implement it really easy themselfs in the send_ticket.py and setting a ini value to enable this feature

[bb-Ricardo]

Hi,

thank you for the FR.

How about calling an URL instead with a custom payload. There could be placeholders which will be substituted with the actual content once this action is called.

• lets call it event handler
• performs post actions on URLs (to be defined in config file)
• custom payload in json format (to be defined in config file)
• can use predefined placeholders (user name, host name, service description, status, status output, ...)
• assign handler to action
• define question to ask user if handler should be started

What do you think?

[william-sy]

Hi,

No problem, Sounds like that is a way more robust way to do things.
Any python script would basically call a URL with JSON Anyway.

Currently we have a script do the following:

• Set title of the ticket
• Set the body of the ticket
• Set the department the ticket should go to (network / sys / app)

From here the plot thickens for fresh service, But the remaining items can be set in a JSON in the config:

ticket_auth = {
       'api_key': keyhere,
       'api_password'': password
       'api_url' : https//jira/freshservice/trello/etc
}
ticket_data = {
        'description': d_desc,
        'subject': d_subj,
# custom fields ETC
}
ticket_department = {
       'ops': 1102568 
       'net': 5631236 
       # some easy short names to be translated into the 
       # actual requirement for a project / department for fresh service this is a INT ID
}

Then use requests to send it and print out if the ticket was a succes. There is a high potential for feature creep here :)

A configurable layout of the ticket would be awesome:
subject = f"{state} - {hostname} - {service}
decription = f"The host: {hostname} has a problem with {service} since {timestamp} and is in state: {state}"
This way you can swap things around if need be for SOC, NEN, Audits or Preference.

In terms of a question

• The command: ticket comes to mind (basically the same flow as ack without the end date and could ask at the end would you like to ack this problem? (then you would need a and date / comment question)
• After a ack when the bot says: Successfully acknowledged Service problem! it could be expanded in would you like a ticket?

basically so you don't have to ack and ticket for the same item(s) twice (people are lazy).

A other FR that comes to mind:
We have the bot in a shared channel with all lot of people who probably muted this channel, and sometimes you want to @ a person and you will get the response I didn't understand the command I would love a ignore character if a line starts with @ or # the line is not ment for the bot this would save some responses of the bot during a short convo about the problem like # I have acked the problem working on it or @here, working on it

[bb-Ricardo]

There is a high potential for feature creep here :)

Indeed 😄

Also trying to make it as generic as possible.

• ticket_auth and ticket_data could be combined into one json structure.
• additional questions about department and whatever could be generically added

[eventhandler_questions:ticket]
question_1: select department to handle issue
possible_answwers_1: ops (1102568), net (5631236)

Another possibility would be to add another little flask service on the same machine between the bot and and your ticket backend. This would remove complexity within the bot and you could add whatever you like in the handler in between.

different systems have different auth methods for example.

what do you think?

[william-sy]

Yes I can imagine that there are tons and tons of ticketing systems out there.
And getting it to be generic is a good goal.

• They could be very well be in the same JSON to reduce complexity.
• I think this is a great way to show the options you have: possible_answwers_1: ops (1102568), net (5631236) for this question. It will make is super easy for the user that has to ack this problem in the middle of the night.

That is why I thought of calling a script, and the user provides the script, But over all looking at jira / fresh service / trello they use the same method of API keys. So that would be the "generic" standard as most modern applications use that, Else it is user name / password but that is getting less and less used for these big companies. you could make the user supply the auth=api_auth_values, saving you to think about that.

    api_token = '{{ freshservice_api_token }}'
    api_password = 'BLANK'
    headers = {'Content-Type': 'application/json'}
    api_auth_values = (api_token, api_password)

I don't have an opinion about the extra flask server. Other than system recourses. That said it should not be a problem these days but it is nice to keep it as minimal as possible.