Calendar > Performing specific steps allows invalid tool config to be saved, which breaks the tool from rendering

There's a button when viewing the calendar, "Set as Default View", which when clicked runs the following:

	/** Set current calendar view as tool default
	 **/
	public void doDefaultview( RunData rundata, Context context )
	{
		CalendarActionState state = (CalendarActionState)getState(context, rundata, CalendarActionState.class);
		SessionState sstate = ((JetspeedRunData) rundata).getPortletSessionState(((JetspeedRunData) rundata).getJs_peid());
		String view = state.getState();
		Placement placement = ToolManager.getCurrentPlacement();
		placement.getPlacementConfig().setProperty( PORTLET_CONFIG_DEFAULT_VIEW, view );
		saveOptions();
	}

This code assumes that the value stored in state.getState() corresponds to one of the 5 viewing options in the drop down: day, week, month, year, or list.

However somewhere along the lines the code starts using this variable for a lot of other stuff, namely which interface you're currently on. So other things like "description", "delete", "iCalEx", "revise", and "new" end up being put into this variable.

This introduces a situation where you can perform an edge case of some very specific actions (exact steps not yet identified) that will leave the value of "description" in this field after the main calendar view is rendered. This UI has the button to set as default view, and if the user clicks on it without changing the value in the drop down, the above code will run and promptly save "description" as the default view.

So the next time the tool is viewed, it asks Velocity for the tool config, it sees that the default view for this site has been set to "description", and it tries to render the "Description" UI to display all the properties of an event. Well, the problem is the tool was never designed to do this (nor does it really make sense to do so), and the tool doesn't have a specific event loaded. The result is some nulls get passed around when trying to render the view and eventually it results in an uncaught exception and we see the error message and stack trace as illustrated in attached screenshot.