Open william-sy opened 4 years ago
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.
What do you think?
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:
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
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)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
There is a high potential for feature creep here :)
Indeed 😄
Also trying to make it as generic as possible.
[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?
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.
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.
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 theack
commanddo 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 thedescription
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