Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-5186

Space Channels - insane idea or inspired idea?


    • Icon: Suggestion Suggestion
    • Resolution: Timed out
    • None
    • None
    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      The idea behind space channels is relatively simple in terms of concept, but probably quite a lot of work in terms of implementation.

      Labels allow us to easily tag content, effectively categorising it. However, it seems there is still one component missing that would tie up lots of loose ends such as:

      • Namespaces
      • Spaces within spaces (eg. for dealing with permissions across blocks of content in a space)
      • Permissions (see above)
      • etc.

      NOTE: I know that what follows could essentially be done with multiple spaces, however there are many times when it's not practical or desirable to do so, hence the channels idea.

      The channels idea works as follows:

      1. A space admin can create one or more channels (there would likely be a default channel for all content).

      2. For each channel, the space admin can select what privileges are assigned to groups/users/anon for that channel - eg. who can edit content in that channel.

      3. Ideally, the space admin should also be able to define what macros/templates can be used within a channel. Being able to have an email archive per channel would also be highly useful.

      A default channel would be used to deal with old content - eg. when you upgrade to the version of Confluence that has channels, everything gets put in to the default channel for each space (pages, templates, mail archive, space permissions). Due to this default channel, you'd instantly then be able to define what macros can be used in a space.

      Now, let's say you want a team (user group) to be able to edit one section of a space and not another - simply create a new channel and assign the privs, etc.

      Pages would then have a channel drop-down (a page can only be in one channel). You would obviously need a "Change channel" permission somewhere. Any pages created that are attached to a parent page would automatically inherit the parent page's channel - for most users (who cannot "change channel") they would be none the wiser as the option would not be available (the applicable channel would merely be displayed as text) = keeps things simple for them. So, from an editing point of view, there's not too much work involved.

      You would not be able to move pages outside of a given channel - someone with "change channel" priv would have to do that for you = nice container allowing orgnaisations to contain content for a given channel within that channel.

      As mentioned earlier, each channel could have it's own mail archive and templates. The mail archive is particularly interesting as you would then have the ability for teams to work side by side in a space, each with their own archive.

      Templates should be able to be in all channels, one channel or several channels - eg. if you want to share a common template with all channels in a space.

      You could search by channel. You could export a channel (eg. to Word = great for documentation, etc). You could get an RSS feed for the channel.

      Being able to set permissions and what macros can be used in a channel means that different groups with different experience and privileges/needs can be more effectively "boxed in" within a space.


            barconati BillA
            gfraser@adaptavist.com Guy Fraser [Adaptavist.com]
            6 Vote for this issue
            10 Start watching this issue