Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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.

SplatUpdates no longer available

We're sorry, but the SplatUpdates channel is no longer available.

Feel free to remove this channel from your layout by using the X control in the upper right corner of this channel. On (SOME_DATE) this channel will be automatically removed from all layouts.

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.

Dropping the error message

So dropping the framework behavior of displaying an error message when a deleted channel is in the user's layout doesn't drop the ability for deployers to provide that user experience when desired. But it would add the ability to not tease users about channels they can't have anymore.

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 its static message replacement.

Deleting channel SplatUpdates

Are you sure you want to delete SplatUpdates?

(warning) There are 47 end user composed layout fragments and 3 centrally managed layout fragments referencing this channel. How would you like uPortal to handle references to this channel?

(x) drop references to this channel from layouts (including end user composed layouts and centrally managed layouts).
( ) replace references to this channel with references to another channel (you will choose the channel on the next screen)

(Yes, delete the channel) (No, do not delete the channel)

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

Deleting channel *SplatUpdates*

Are you sure you want to delete SplatUpdates?

No end user managed layouts and no centrally managed layouts reference this channel.

(Yes, delete the channel) (No, do not delete the channel)

  • No labels