As the manager or contributor to a Confluence "Space" there are several topics you should be familiar with.
There are four levels of permissions that can be applied to a space as a default configuration:
- Anonymous - anyone in the world can see the content (commons will be visable from off site)
- Confluence-Users - anyone logged into commons
- all-lbnl-users - anyone from Berkeley Lab who is logged in to commons
- Individuals - permissions assigned to specific individual accounts.
In the future, staff at other institutions will be able to log in and contribute to the content on this site. These users will be confluence-users and not all-lbnl-users.
This will be accomplished by implementing a new Federated identify management system that allows us to trust partner institutions (when someone attempts to log into commons and they are from a partner institution, we redirect their authentication action to their own identify provider. Once successfully authenticated, commons receives an assertion that the action was successful and they are given access to the spaces that allow privileges to any authenticated user (or in some cases specific permissions for the specific person).
Ideally, spaces like FAQ's will remain viewable to anonymous users. Wiki's are most effective when the majority of the information is available to a wider audience. We also recommend providing view permission to "all-lbnl-users" to most of the content on the site.
Note: the Space administrator identifies a set of permissions that act as the default for the space. Any page within the space will have those permissions or they can be further restricted to a subset of individuals who can view or edit. It is not possible to grant more rights than the space default.
Inheritance Issues (provided by Mitch Deacon of the IT Help Desk)
The results of our test show that editing permissions are not inherited from parent to child, regardless of whether the child is created after the permissions or not.
To check both scenarios, I took an existing parent and child page and then added restrictive editing permissions to the parent: the child page was still "editable."
Then I added a new child to the same parent, which still had the restrictive editing permissions: once again, the new child page was still "editable."
Art and I also checked viewing restrictions.
These are inherited from Parent to Child. This was the case both before and after the parent permissions were created.
In our test, I restricted the viewing permissions of an existing parent page to Carlos.
Art was unable to see the parent, and thus could not see the child.
Next I created a new child page to see if it inherited the restricted permissions. Again, Art could not see it, because he could not see the parent.
Based on these tests, it appears that the documentation on the Confluence site is accurate.
Themebuilder versus default theme: We hope to make available some different themes based on software contributed to the vendor. However, we have seen some problems that suggest waiting for a future release is best for now.
References (e.g. links) to your content
If you want to email someone the link to a page there are two ways to accomplish this:
- go to the page you want to share, copy the URL in your browser, and copy it into an email (bad)
- go to the tools menu>info and copy the tiny link from there. (good)
The second alternative is the best method because the link you find will work no matter where the page is located. In confluence it is easy to move a page from one place to another - and the "hard" link in the first option will break.