lcreid / outages Goto Github PK

E-mail users who have requested notification about a CI.

This could be an observer on the outages entity, but we have to think about the combinatorics.

This would be really messy for the calendar view, but not so bad for other views.

Might need to start tracking users for preference info.

In the simple version, you just attach a watch to a CI and that's it. There might be a use case for watches not attached to a CI, but rather oon some other criteria, e.g. all during the working day. This could get arbitrarily silly.

There would be a significant use case for filtering by time range: between certain hours, and with work days.

So I might want to see Citrix outages during my working hours. Or Jira at any time, because I'm a lead.

Showing /home/reid/outages/app/views/outages/show.html.erb where line #8 raised:

undefined method `parse' for nil:NilClass

To reproduce, enter a new outage without having set a time zone, e.g. using the one found by the JavaScript.

Need to do a stylesheet to make it look good and to make the theme a bit distinctive from a standard Bootstrap theme.

Name, start time, stop time, time zone. Add other attributes as we add features.

Ideally this is a grid. If we're going to use React (we are, aren't we?), then http://griddlegriddle.github.io/Griddle/.

May need a user to track time zone. Or maybe it can be done with cookies.

Need to track the user's choice of time zones, and override browser detection if the user has specified something. Would also be nice to just put a reminder on screen if the selected time zone is not the browser's time zone -- but think through the use cases before going too far with this.

There's a use case for teams or groups of people getting the same watches, and having them assigned by default, or by someone else.

It would be cool if we can get the groups from a directory service. Note that if we get the group from a directory, we have to do it every time, so that the group list is up to date. See e.g. https://github.com/ajrkerr/active_directory. Or just use ruby-ldap.

The part of this that's not trivial is that CIs run on other CIs or contain other CIs. Part of the trick is the language, as I think the representation is the same. This is a many-to-many relationship.

A software component runs on a server. It may run on multiple servers, which we may or may not choose to represent as a CI representing the cluster.

A system includes a bunch of CIs. An environment includes a bunch of systems.

Down the line we may subclass the CI, and give different types of CI different intelligence. That should be another feature.