When Channels are Deleted

About this page

This page is for describing desired uPortal behavior when channels are deleted. It is a child of the Layout UI page because the primary discussion is of what the end user experience should be (error messages or fail more quietly), tho the page also discusses implementation.

Deleting channels

Current behavior

It appears that if a channel has been deleted but it is still in the user's layout, an error message is displayed.

Desired behavior

If we decide to decommission a channel at some point in the future, we would like it if it was removed from users' layouts or at least not displayed in the form of an error message.

Better error messages

In many cases a portal administrator would want to incrementally decomission a channel. If in that process a deployer desires that the channel be replaced for a time with a static message.

There are a couple ways to implement providing such a user experience. One way, the currently implemented way, is to use the CError framework which will replace missing channels with a generic error message indicating that the channel is no longer availalble.

An alternative, more powerful way is that of changing the channel definition to describe a channel that provides the desired user experience. From the perspective of the uPortal framework, there is no error. This could be implemented with a CWebProxy pointed at static HTML, say. This approach requires more work for each channel deletion, but offers benefits in supporting providing a very specific, supportive UI helping the user through channel EOL.

Dropping the error message

Some deployers may want to simply make a channel disappear. This might be because the static "Sorry, your channel's gone" message has been going on long enough, or it may be because the desired user experience is one of a "here today, gone tomorrow" approach – the sooner the channel disappears completely the sooner the users can forget about it. Maybe the channel functionality has been subsumed into another channel that has been injected nearby on the layout.

There are two ways to accomplish this. First, when an administrator deletes a channel, uPortal should find and remove references to that channel to maintain referential integrity of the domain model. Layouts shouldn't reference channels that don't exist anymore.

Second, when a layout manager tries to render a channel that doesn't exist, it should fail quietly, or at least be configurable to do so. This is required even if cleanup at channel delete time is implemented, since some layout sources may not support the callback telling them that a channel is no longer available. So, bad channel references shouldn't happen, but when they do happen the layout rendering pipeline should quietly drop the missing channels. Quietly doesn't necessarily mean silently. Perhaps a web browser's handling of bad JavaScript is a decent metaphor. When rendering a layout with recoverable problems such as references to bad channels, uPortal might insert into the header something like

There were errors displaying this page.

Such an advisory, or the ability to opt into warning messages for missing channels, wouldn't be appropriate for every user, but might be a worthwhile feature to help administrators debug layouts via the UI. And it goes without saying that handling of recoverable problems like missing channels would be logged.

Administratively

Ideally, channel deletion would find and drop all references to the channel in user layouts, to maintain referential integrity in the uPortal data model (no layouts reference non-existing channels). Even more ideally, it would have an ability for a deployer to replace the references with references to a different channel, thereby easing failing over a doomed channel to a replacement message as described above. These enhancements would reduce the incidence of layouts referencing deleted channels.

And of course, if there are no references to the channel, uPortal should reassure the administrator of this:

Implementation

Dropping referencs to channels at the time of channel deletion could be implemented by a callback to the LayoutManagers to advise them that a channel has disappeared. Supporting Layout manager implementations would update their layout definitions to no longer use the deleted channel, replacing it with another channel if so advised.