Extending the status page after EOF

[snkaupe]

Right now, it is only possible to create, edit and delete incidents (as well as their impacts and updates) via the web UI. We wanted to extend this to all entities the status API server handles, but ran out of time.

If one where to take up this task, they'd need to perform a number of tasks:

• The Bearer token during the authorization step is currently only set on the IncidentService. This would likely need to be extended to all entity services, or one would need to find a way to set this header globally. The corresponding code handling this matter can be found in ngOnInit of the login page.
• The EditBarButtonsComponent handles the "Save/Delete/Discard" buttons at the top of the incident detail view. This component currently calls a function the surrounding page can set that receives one string argument when any of the buttons are clicked, like "save" in case of the "Save Changes" button. Either way, the EditModeis always being switched. In case of errors or the user cancelling the deletion of an incident, this can lead to the loss of any changes so far unsaved. It would be better if the component would receive a return value from the called method that determines whether or not the EditMode can be switched to viewing.
• Further generalized components or helper classes could probably be extracted from the IncidentDetailViewComponent, such as the running of validity checks and the handling of the error state.
• The main page would need some way to access the different types of entities. Components are simple (click on their name in the component list), but for everything else (phases, severity values, etc.), we'd probably need a kind of menu. Bootstrap might help here.

Aside from this task, there are a number of other things that could be taken care of:

• Bootstrap might be useful in general. Apparently, there is also a theming component that might make this task easier/cleaner.
• Speaking about theming/branding: there is no documentation on how to achieve theming right now. Basically, the idea is to take the top-level styles.css and use the CSS variables contained therein to determine your page's color scheme and rounded borders. This could probably be improved.
• Likewise, the imprint and cookie policy pages currently do not support exchanging their contents without somebody changing their very components. If any further cookie functionality is wanted, the appropriate cookie warnings/usage selection dialogs also need to be added.
• Dialogs: The dialogs used by the incident detail view share a number of common features, which could probably be extracted into an interface or superclass, if possible.
• Error reporting could be centralized into something like a MessageService, which uses a consolidated set of reporting mechanisms (console log, Toastr, whatever). This should be available as soon as possible in application initialization, so that other services (like the DataService, which is currently only printing errors to console) can make use of it.