Treat Maintenance and Issues as different event types

[bjshively]

Feature Request/Description

TLDR: Separate API requests for maintenance and incident events. Treat them as two separate event classes.

This is perhaps a bit general and might be something there are differing opinions on, but to me it is unintuitive that maintenance would be considered a type of incident. I think there should be two distinct URLs that return incidents and maintenance events separately (and perhaps if necessary or for backwards compatibility, a 3rd URL that returns both event types as [site]/api/v1/incidents does currently.)

My reasoning is this.. Maintenance isn't necessarily a "bad thing." There is a big difference between scheduled downtime and unexpected service interruption. If I told the leads in my org that there were 10 incidents this month, they might panic. However, if I told them that we had 9 scheduled maintenance activities and one brief outage incident, that sounds a lot less dire. From a reporting perspective, it makes sense to separate these two categories of data.

I'd love to hear any thoughts (including/especially disagreement) on this. I combed through the issue backlog and I do see a lot of enhancements coming up for scheduled maintenance, etc. but I didn't see this particular issue addressed. Apologies if I just missed it!

Actual behaviour

Incidents and maintenance are essentially treated as one object type.

Steps to reproduce

API calls, etc.

[jbrooksuk]

Yeah, maintenance is something I'd like to refactor. I keep kicking myself that I didn't make it a separate entity because it makes things like recurring maintenance more cumbersome to implement now.

If you'd like to give this a go, then please do! :)

[bjshively]

This is probably a tad beyond my current skill level, but I'm interested in contributing. I'll get myself up to speed on Laravel and go from there. Will check back in if I feel comfortable "claiming" this.

[jbrooksuk]

👍

[jbrooksuk]

Before we go any further with this, scheduled maintenance must become its own entity.

[bjshively]

To make sure I understand the general approach (VERY high level).. This would require something like the following, right?

1. Create a Maintenance model (very similar to the existing Incident model) and table
2. Everywhere incidents + maintenance are referenced, decouple and add references for new Maintenance object type specifically. Things like, writing/reading maintenance to and from the new table, etc.
3. (optional but seems useful/logical) Write a migration to copy previous maintenance-type incidents to Maintenance table and delete the records from the incident table

Basically look for everywhere there is "Incident" code and make corresponding "Maintenance" code, with some small exceptions..

[jbrooksuk]

Yeah, this would need:

• Removing of maintenance code from the current dashboard incident controllers/commands
• Maintenance model.
• Relevant maintenance commands, handlers and events (see the ./app/Bus directory)
• A new presenter for the Maintenance model
• Updating of the dashboard to handle maintenance

[jbrooksuk]

I'd be happy to help you through this if you'd like to take it?

[bjshively]

Alright.. I am a little scared (this is my first OSS contribution, ha.) But I'll bite. Will give this a shot.

[jbrooksuk]

Awesome! If you need anything, you can email me at james@alt-three.com — sorry if it takes a little time to get back to you, I'm doing a lot of things outside of code at the moment :)

[jbrooksuk]

Done!

Although, one thing I need to add is components, but this will be done as part of the new design as it'll help to clear up some code.