Skip to end of metadata
Go to start of metadata

The Skin Editor Permissions screen allows theme developers to restrict certain functionality to specific user groups.


Setting Permissions

To set a permission enter the group name in the appropriate field.

You can use * for wildcard selections.


@spaceadmin-* = any group that begins with 'spaceadmin-'

For multiple groups use commas to separate.

@spaceadmin-*, @staff-*

Skin Selection Restrictions

Default: Any Space Administrator and Site Administrators

This permission allows you to restrict who can select this skin in the Select Skin to users (who must also be Space Administrators) in specific user groups.

Site Administrators will always be able to select the skin regardless of the settings of this permission.

It is still possible for Space Administrators and even normal users to bypass this privilege by using the use-skin macro, however they will not be able to set it as the default skin for their space.

Example Usage

The most common requirement for this permission is if you have a skin that's uses your company design, but don't want to restrict where that design can be used.

Skin Editing Restrictions

Default: Anyone who can access the skin manager

By default, any registered Confluence user can access the Skin Editor, however Site Administrators can restrict access to the skin Manager to people in specific user groups using the options on the Editor Permissions screen (a highly recommended task).

Theme developers can further restrict access to specific skins by restricting editing to a specific user group.

For example, let's say the following groups existed:

Theme Designers

Senior Managers

Bob, Jane, Mark


If you restricted editing to just the "Senior Mangers" group, then only Jane would be able to edit your skin. Bob and Mark, although able to edit other skins in the skin Manager, would not be able to edit your skin.

Site Administrators can always edit all skins, regardless of any editing restrictions you set.

People can still make child skins based on your skin and then edit those child skins. If you want to prevent this, restrict who can create child skins to the same user groups as those that can edit your skin.

Example Usage

In large wikis, there may be a large group of people who can edit skins and there are many cases where key skins (eg. master templates or important company skins) need to be restricted to a smaller group of editors.

When you restrict editing of your skin, you are also restricting who can change the privileges on your skin.

Panel Editing Restrictions

Default: Anyone who can edit the skin

This permission allows you to restrict who can view and edit the content of panels in the skin (see Panel Content).

Site Administrators can always view and edit panel content, regardless of any editing restrictions you set.

The panel content is still transmitted to the browser when the skin is opened in the Skin Editor so anyone with sufficient knowledge could find a way to view the panel content, although they could not make changes to it.

Example Usage

The most common scenarios for restricting who can edit panel content are:

  • The panel contains complex code and you don't want anyone to break it
  • The code in the panel contains information you would rather other people not see.

If you're restricting access because of the latter, you need to rethink your strategy! View the answer to the question below.

Prevent anyone from viewing panel content

There are several ways to reliably prevent anyone from viewing your panel content:

  • Create a User Macro in the AtlassianConfluence Administration Console - these macros can only be viewed and edited by Site Administrators.
  • Use a Portal or Widget (requires Community Bubbles plugin) which again requires Site Administration privileges to view and edit
  • Create a Java plugin which contains a macro that fulfils your requirements.

Child Skin Restrictions

Default: Anyone who can access the skin Manager

This privilege allows you to restrict who can create child skins based on your skin to users in specific user groups.

With restrictions in place, anyone who cannot create child skins will see a warning message if they try and create a child skin.

Site Administrators will always be able to create child skins, regardless of the permissions.

For someone to be able to create child skins in the first place, they must already have access to the Skin Editor in which case they could also edit your skin to remove this permission. To prevent this, restrict edit privileges to the same groups that you are allowing to create child skins.

Example Usage

This permission allows you to prevent a child skin, which may look identical to your skin, from overriding various settings and permissions in your skin.


You will need to click the 'Save' button to apply any changes made in the 'Permissions' screen.

Hints and Tips

If you restrict which user groups can select the skin, consider adding a note to the skin description to let Space Administrators know who to contact if they need to join that group.


What are the 'Use Default' links?

See Skin Hierarchy

See Also

  • Editor Permissions - Site Administrators can set global permissions such as who can use the skin Manager
  • Skin Locking - This locks the Theme Builder skin for a space, preventing the Space Administrator from using the Select Skin
  • No labels