New incident system

[karelkryda]

Description

Fixes: #1056, #908, #862

This commit includes a new incident creation and management system:

• Removed the ability to create incidents through the status page
• Added the ability to create incidents (publish updates, close and reopen incidents) via the dashboard
• Added the ability to manually force a status override on the status page when creating an incident
• Added a list of all current incidents above the overall status
• Added incident history under the list of monitors (on the status page) (last 5 incidents)
• Added history of all incidents broken down by year and month
• Added the ability to view incident information from the status page (including the incident timeline)

Type of change

Please delete any options that are not relevant.

• User interface (UI)
• New feature (non-breaking change which adds functionality)

Checklist

• [x] My code follows the style guidelines of this project
• [x] I ran ESLint and other linters for modified files
• [x] I have performed a self-review of my own code and tested it
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] My changes generate no new warnings
• [ ] My code needed automated testing. I have added them (this is optional task)

Screenshots (if any)

[Jeve-Stobs]

This looks amazing. Just tested and if this can get approved for the next minor update, it will really improve the current status page. What a great addition!

[karelkryda]

@Jeve-Stobs thank you 😊

[yun00001]

Will like this to be added into next update! this is so good!

[mathiskir]

Wow! That would be incredibly useful!

[MedPlex98]

Is there any update? 👀 The function would be for us the direct switch to UptimeKuma, as it would be really essential and we love UptimeKuma :3

[trdwll]

Please. lol. This would be amazing.

[notdatabase]

YES please. This would finally be why at work we can switch away from Statuspage/Cachet.

[mathiskir]

Hey, I just tested it and I have some ideas for improvements:

• different colors for status of incidents (started, update, resolved)
• mark affected monitors by a maintenance somehow, so that it's clearer for end users (with an icon??) But besides that, it's great!

[finnie2006]

I am really waiting for this, this is a game changer, and this feature will also be nice for companies etc @louislam

[finnie2006]

but it is actually outdated already and pretty far off the master branch

[karelkryda]

but it is actually outdated already and pretty far off the master branch

It is true that with each new commit to the master branch, this pull request moves away from the current code, but I hope it will be merged soon.

[finnie2006]

i think you should try to keep it a bit up to date, i dont think he will merge it if its outdated

[karelkryda]

i think you should try to keep it a bit up to date, i dont think he will merge it if its outdated

Unfortunately, I do not currently have the opportunity to do this and update this pull request with the master branch.

I'm busy right now, and this action requires a lot of code comparison and additional testing to see if everything still works.

[karelkryda]

I would love for @louislam to resolve the issues before merge this pull request.

I've tried to resolve conflicts now, but it's not something I do every day and I don't know much about it. In the end, this created absolute chaos, and I doubt it would ever work again 😁.

Maybe it will be resolved soon and it will be merged.

Sorry 😔

[louislam]

I would love for @louislam to resolve the issues before merge this pull request.

I've tried to resolve conflicts now, but it's not something I do every day and I don't know much about it. In the end, this created absolute chaos, and I doubt it would ever work again 😁.

Maybe it will be resolved soon and it will be merged.

Thanks, to save your time, I suggest that it could be resolved later because I think pull requests like #1083 and #1415 will be merged before this PR.

[karelkryda]

Thanks, to save your time, I suggest that it could be resolved later, because I think pull requests like #1083 and #1415 will be merged before this pr.

I understand. I will be happy if you would take care of resolving the conflicts or help me with them, because I really don't know how to do it 🤦🏻‍♂️.

[louislam]

Would try to help later. Might need some works, as I remember this pr is created before multiple status pages support.

[mathiskir]

• different colors for status of incidents (started, update, resolved)
• mark affected monitors by a maintenance somehow, so that it's clearer for end users (with an icon??)

I think these two things would be really nice to have and don't require much of work. Could you maybe implement it before merging it, or what do you think about these two features?

[karelkryda]

mark affected monitors by a maintenance somehow, so that it's clearer for end users (with an icon??)

I planned to do this, but I forgot 😁

different colors for status of incidents (started, update, resolved)

Do you mean the colors on the timeline? It should theoretically be possible there.

Incidents are color-coded according to priority (type).

[mathiskir]

Do you mean the colors on the timeline? It should theoretically be possible there.

yes on the page you can see at the screenshot above

[LukeD1994]

I tested merging this manually myself, with build 1.14.0-beta1. I did it in a very hacky way, it doesn't fully function because I haven't (yet) gone through and edited the PR code to make it work with the multiple status pages features (I don't need multiple pages), all in all a great addition. :)

[gaby]

@karelkryda Could you rebase this with master? There's a lot of conflicts right now

[karelkryda]

@karelkryda Could you rebase this with master? There's a lot of conflicts right now

We talked about it, look up a little bit.

[gaby]

@karelkryda No worries, I didn't read the whole thread. I was trying to merge this on my fork and failed miserably. There's a massive conflict in StatusPage.vue because of https://github.com/louislam/uptime-kuma/pull/1083 and https://github.com/louislam/uptime-kuma/pull/1415

[karelkryda]

@karelkryda No worries, I didn't read the whole thread. I was trying to merge this on my fork and failed miserably. There's a massive conflict in StatusPage.vue because of https://github.com/louislam/uptime-kuma/pull/1083 and https://github.com/louislam/uptime-kuma/pull/1415

Yeah, that's why I'll need help before merge 😕

[mathiskir]

@louislam could you maybe help @karelkryda with these massive merge conflicts so this can maybe be a thing in 1.16 or 1.17? Or are there any big pull requests that aren't merged yet?

[louislam]

@louislam could you maybe help @karelkryda with these massive merge conflicts so this can maybe be a thing in 1.16 or 1.17? Or are there any big pull requests that aren't merged yet?

I just have a quick look of source code. I am afraid that it won't be merged shortly.

1. As this pr created before multiple status pages, a lot of logic and ui/ux of this pr may need to be redesigned. For example, I think "create incident" button and incident management should be moved back to status page instead of dashboard, which won't be so easy.

2. I believe the database schema/relations need to be changed too.

3. There are some breaking changes like changing the url from /dashbaord/:id to /dashboard/monitor/:id, which I maybe cannot accept that, because bookmarked monitor urls will become 404.

4. I think all existing function names or route names should not be modified.

[mathiskir]

So @karelkryda has a lot of work to do

[karelkryda]

1. As this pr created before multiple status pages, a lot of logic and ui/ux of this pr may need to be redesigned. For example, I think "create incident" button and incident management should be moved back to status page instead of dashboard, which won't be so easy.

Personally, I think it's better for incidents to be created directly in the dashboard. It's definitely more convenient (at least in my opinion). Theoretically, it would not be a problem to add the option to select on which status pages the incident is displayed (or to display it on all status pages on which the affected monitor is displayed).

2. I believe the database schema/relations need to be changed too.

If we decided to choose the option of selecting the status pages on which the incident will appear, it would be necessary.

3. There are some breaking changes like changing the url from /dashbaord/:id to /dashboard/monitor/:id, which I maybe cannot accept that, because bookmarked monitor urls will become 404.

Regarding this step, my goal was to make the URL address make sense. With the ability to schedule maintenance, create incidents and monitors in the future, it would make more sense for the URL to match. Theoretically, it would be possible to add a redirect condition to the router, right? That is, /dashboard/:id would be redirected to /dashboard/monitor/:id. Again, it depends on the agreement....

4. I think all existing function names or route names should not be modified.

[karelkryda]

So @karelkryda has a lot of work to do

Unfortunately, it seems that it will be necessary to start from scratch, which makes me a little sorry and annoying at the same time.

I'm currently taking my final exams at school and therefore I can't work on this PR. When I'm done after the exams, I'd look at it and try to redo this PR.

[louislam]

I will also come back to this pr later, I am planning to merge older big pull requests such as #1119 or smaller pull requests first.

[finnie2006]

This pr really should be a standard feature of uptime monitroring software

[karelkryda]

@louislam Should I prepare this PR for milestone 1.17.0?

[louislam]

I will go for the maintenance pr first, it should be in 1.18.0.

[karelkryda]

I will go for the maintenance pr first, it should be in 1.18.0.

Okay, please let me know and I'll prepare the PR. It is useless to do this now that there will be a lot of commits up to version 1.18.0.

[Nuckerr]

So any updates for this?

[heiko-ma]

Will this PR be included in 1.18.0? This is the only missing feature which prevents us from migrating from cachet to uptime kuma.

[karelkryda]

Will this PR be included in 1.18.0? This is the only missing feature which prevents us from migrating from cachet to uptime kuma.

that's a good question. In fact, my next (maintenance planning) PR still hasn't been completed and has been postponed.

[reigio]

This incident system is most important feature missing that keeps me form using Uptime-kuma. Any organisation interested in their systems uptime is in need for good incident handling. Please consider moving it up in the new features list. Maintenance planning would be nice too.