resultadosdigitais / hellper Goto Github PK

Cleanup

What should be cleaned up or changed:
The communication, both in the incident's channel and in the HELLPER_PRODUCT_CHANNEL_ID channel, don't have the Incident ID (unless the opening communication)

Incident opening communication:

Incident resolution communication:

Incident closing communication:

Provide any links for context:

Cleanup

What should be cleaned up or changed:
The change of the timezone in the update date dialog is not clear for the user.

The first field (timezone), do not dynamically update the other fields

Provide any links for context:

Subject of the issue

We currently have a check that validates whether the hash is the same. If so, he disregards the message. We need to verify that it is possible through configuration to prevent the bot from receiving its messages.

Feature Description

Have a specific command to add in the timeline a status.

Expected behaviour

Be clear to the user when he sends a status to the timeline.

Alternatives

Alternatives are welcome!

Subject of the issue

We identified that when trying to send the command privately to the bot with a user other than the owner of the bot, the same can not reply on the channel saying that it does not exist.

This problem occurs because of the oauth token used in the operation. A bot in the slack has 2 types of oauth token and all are needed for the correct operation of the bot. We need to identify the correct mechanism for using these tokens.

Now we don't have a process when the same incident occurs again or when two incidents have the same root cause.

The main question is, we do the same postmortem? How to control and metrify this using the Hellper?

Feature Description

The Root Cause field is currently in the open text format, so is not possible to extract assertive metrics. Changing to a list of root causes options, that could be done.

Problem

Today we cannot extract assertive metrics related to the incident's Root Cause.

Expected behaviour

As Root Cause is an important characteristic of an incident, we want to extract metrics of them, to better focus our efforts to reduce the impact of those root causes.

Alternatives

Alternatives are welcome.

Cleanup

CRITICAL ISSUE: This issue blocks any new Hellper app on Slack from working!

What should be cleaned up or changed:

Some methods and permissions there we use directly and through the package slack-go are deprecated since January 7.

On June 10 new apps will not be allowed to use them, so new Hellper applications won't work.

On November 25 these methods will stop working.

Update: The new due date for these methods stops working is February 24th, 2021

Provide any links for context:
https://api.slack.com/changelog/2020-01-deprecating-antecedents-to-the-conversations-api?utm_medium=email&utm_source=newsletter&utm_campaign=fy21-Q205-changelog

Subject of the issue

Describe your issue here.

Steps to reproduce

Tell us how to reproduce this issue. Please provide a working and simplified example.

Expected behaviour

What should happen?

Actual behaviour

What happens instead?

Possible Solution

What are the alternative solutions? Please describe what else you have considered?

Feature Description

When closing the incident channel through the command @bot-name close, the channel participants should receive the incident timeline.

When an incident channel has no pinned messages, the reminder searches for the last pinned message and not find it, it logs a Last Pin error and does not ask for the incident status.

jsonPayload: {
  app_name: "hellper"   
  channelID: "C015Q8L61A8"   
  error: "Lista está vazia"   
  level: "error"   
  log_type: "stdout"   
  message: "command/reminder.requestStatus LastPin error"   
  pod_name: "hellper-7f4cc474d7-89pvh"   
  raw: "{"level":"error","time":"2020-06-24T14:34:03.990Z","message":"command/reminder.requestStatus LastPin error","channelID":"C015Q8L61A8","error":"Lista está vazia","stack":"hellper/internal/log/zap.(*zapLoggerDelegate).Check\n\t/app/internal/log/zap/zap.go:32\nhellper/internal/log/zap.logger.log\n\t/app/internal/log/zap/zap.go:79\nhellper/internal/log/zap.logger.Error\n\t/app/internal/log/zap/zap.go:98\nhellper/internal/commands.requestStatus.func1\n\t/app/internal/commands/reminder.go:66\nhellper/internal/job.NewTrackable.func1\n\t/app/internal/job/job.go:26"}

Cleanup

What should be cleaned up or changed:
We should not break the execution of the reminder with this error, we should keep asking for a status message.

Provide any links for context:

Cleanup

What should be cleaned up or changed:
We need to change our Slack Authentication to the new Signing Secret process. Basically we need to store this secret on an environment variable and compare it with the received request.
I think we should create an Authentication package, that every request must call before their router.

Provide any links for context: https://api.slack.com/authentication/verifying-requests-from-slack

Feature Description

The Hellper Bot could have more alerts, to ensure the date's filling, incident's closening, postmortem, etc... If needed, it could even send a @ channel.

Problem

Some incidents were not closed properly, had missing dates values or had the postmortem done many days after the incident occurred.

Expected behaviour

We need a way to remind the incident commander to fill in the incident's dates, close the incident and also do the postmortem as soon as possible.

Documentation Feedback

We have the need to let the Google Docs documentation better documented, as anyone could do it from zero.

Affected documentation page: docs/CONFIGURING-GOOGLE.md

When an incident is opened we call the slack-go.JoinConversation, but this is no longer necessary.

Cleanup

What should be cleaned up or changed:
Remove JoinConversation call on open_incident command (internal/commands/open.go)

Provide any links for context:

Subject of the issue

The owner of the bot, the one who reinstalled it, is the one that is archiving the incident channel in Slack.

Steps to reproduce

Using the command /hellper_close in any incident.

Expected behaviour

We have two options, that should be discussed:

• The bot user archives the channel
  OR
• The user that called the close command archives the channel

Actual behaviour

The owner of the bot is archiving the channel.

Possible Solution

We need to revise the scopes of our Oauth in the Slack App, one of them should permit the bot to archive a channel as itself, or as the user that called him.

Subject of the issue

As our timeline is the pinned messages in the incident channel, when a pinned message has a @ here or @ channel in it, when the Hellper sends the timeline, he also sends this slack command.

Steps to reproduce

1. Send a message with a @ here on it
2. Pin this message
3. Call the Hellper command /hellper_status

Expected behaviour

The Hellper should print the message, but without the @ here, our scaping this command.

Actual behaviour

The Hellper sends a @ here in the channel.

Possible Solution

O Hellper sem dúvidas é uma ferramenta fantástica e nos ajuda (e muito) no pior dos momentos: incidentes.

A ideia aqui é discutir o que falta (Features/ Acomplamento com a RD/Documentação/ Outros) para disponibilizamos essa ferramenta como open source.

Um bom exemplo de uma ferramenta é o Dispatch da Netflix.
O resultado dessa issue é um Roadmap pra a nossa V1 Open Source

Subject of the issue

We have the field Incident Title, but don't have it in any communication at the channels.

Steps to reproduce

Create a New Incident;
Put a Incident Title;

Expected behaviour

when the incident is open, the incident tite should be in the incident channel communication

Actual behaviour

We have this field saved in the database, but never used

Possible Solution

Put Incident title in every communication

Feature Description

When an incident with the severity of 1 or 0 occurs, we need to add some directors in the channel manually.
We could do this automatically through Hellper.

Problem

Add manually some directors in some incidents.

Expected behaviour

Every people that should always be in the incident, whatever is the type of incident, could be included in the channel automatically.

Alternatives

Alternatives are welcome!

Documentation Feedback

Create a gif with the usage of the Hellper in Slack.

Affected documentation page: README.md

Cleanup

What should be cleaned up or changed:
When we update the incident's date with a timezone other than the UTC, we are using the hardcoded timezone with the name Custom/Location.

Provide any links for context:

Cleanup

What should be cleaned up or changed:
The mode that we use to get user info (Slack Dialog) is currently outmoded.

We should upgrade to Slack Modal.

Provide any links for context: Slack Modal

Subject of the issue

When an incident is opened, we insert the channel name in the title column in the Postgres.

This is wrong, there is the Incident Title and the Incident Channel Name.

We need the Incident Title in the database when an incident is closed. So we can create the PostMortem doc with the proper title.

Steps to reproduce

1. Open an incident with /hellper_incident
2. Check the postmortem document
3. Check the incident on Postgres

Expected behaviour

• The opening form should ask for an Incident Title, not only a Channel Name.
• The title column should be filled with this Title
• The title in the postmortem document should have this Title, not the Channel Name.

Actual behaviour

We use the Channel Name from the opening form for everything, the title column, the `channel_name column and the postmortem title.

Possible Solution

Create a new field on the opening form called Title, and use this value to save in the title column. And after that use this column to fill the postmortem title.

Feature Description

Add an option in the modal of the /hellper_incident command so that an incident is opened silently.

A silent incident is characterized by having a private channel and not notifying the main channel of incident when it opens.

Problem

There are some incidents that the entire organization should not be to know, for example, security incidents. That said, in such cases it is necessary to carry out the entire process of opening the incident manually, including its insertion in the databases.

Documentation Feedback

We need to document the use of our Slacks commands, and also improve the configuration documentation. Maybe draw the entire flow and showing where each command fits itself.

Affected documentation page: docs/CONFIGURING-SLACK.md

Subject of the issue

/hellper_status mention the user group when the pinned message has a mention of this kind

Steps to reproduce

1. Send a message mentioning a user group on it
2. Pin this message
3. Call the Hellper command /hellper_status

Expected behavior

The Hellper should print the message, but without the mention.

Actual behavior

The Hellper mentions the group again in the channel.

Possible Solution

Cleanup

What should be cleaned up or changed:
Hellper doesn't have consistency in language. The majority of communication is in English, but somethings reference "pt-br", like the env:

The main language for the application must be English.

Cleanup

What should be cleaned up or changed:
We need to write tests for the Hellper commands. Available commands:

 close     Close the incident
 help      Show this help
 list      List all available commands
 list-all  List all active incidents
 ping      Test bot connectivity
 start     Create a new incident
 state     Get incident state and timeline

Provide any links for context:

Subject of the issue

The owner of the bot, the one who reinstalled it, is the one that is opening the incident channel in Slack.

Steps to reproduce

Using the command /hellper_incident in any incident.

Expected behaviour

We have two options, that should be discussed:

• The bot user opens the channel
  OR
• The user that called the close command opens the channel

Actual behaviour

The owner of the bot is opening the channel.

Possible Solution

We need to revise the scopes of our Oauth in the Slack App, one of them should permit the bot to open a channel as itself or as the user that called him.

Subject of the issue

When an incident is opened, the impact is filled with a 0 in the database.

Steps to reproduce

1. Open a new incident
2. Check the incident impact in the Postgres

Expected behaviour

The impact should not be filled with anything, so the impact in the database, after created, should be null

Actual behaviour

The incident impact is 0 when the incident is created in the Postgres.

Possible Solution

Subject of the issue

The product selected in the opening form is not being shown in the incident opening communication.

Steps to reproduce

1. Open an incident with the command /hellper_incident
2. Check opening communication on the created channel

Expected behaviour

We should inform on the opening communication witch product is being affected by the incident:

Actual behaviour

Nothing is being shown under Product:

Cleanup

What should be cleaned up or changed:
On February 24, 2021 the Events API from Slack will be updated.
We need to check if anything would impact the Hellper bot.

Provide any links for context:
https://api.slack.com/changelog/2020-09-15-events-api-truncate-authed-users