Page History

Authentication and Authorization

1. A course based at Brown includes students registered at Brown, as well as 14 students registered at a university in France. The brown-based instructor is able to compose an ldap-based group that includes the local students as well as the 14 french students (who access the brown-based services using their Federated credentials). The instructor is then able to grant this group write access to a space within Confluence. The local students use their brown credentials to access this space; the french students use their "local" credentials, and the Shibboleth software, to access this space.

2. A collaborative development effort at Cornell includes staff members from Indiana University as well. The JIRA project housing the development issues resides at Cornell and both universities leverage Shibboleth for institutional-specific SSO, giving them access to the same JIRA project. Integration with Shibboleth happens in one spot in Crowd, and JIRA hooks into Crowd. (hypothetical)

3. We want to authenticate Confluence users with our current intra-campus Web SSO system, but use ldap-based groups and user objects to manage permissions within Confluence. Currently, to do this, we would need to write a custom plugin. 

4. UW-Madison.  We have a group that is mostly campus people.  There are also ad hoc external members.  We need the campus people to authenticate via our Web Single Sign On solution.  The ad hoc external members need to authenticate using internal (confluence) user accounts.  To expand this:  we need to be able to have members of a group have different authentication methods (some may be internal application authentication, some campus SSO and some via Shibboleth). 

5.  UW-Madison.  We have a tool that manages groups across multiple collaboration tools.  We also have a Course Management System that needs to push groups and group changes into Confluence.   The initial request will also need to establish spaces and request pages in Confluence.  We need to be able to push space and page creation commands, rights and groups from a variety of tools directly into Confluence.  (This might exist via the API currently)

Managing Permissions 

1. Allow a configuration where the server administrator can shut off the space administrators' ability to turn on anonymous edit.  We don't allow that at our institution and don't want to let an instructor override our policy.  (Brown - PL)

2. At MIT we would like to have the ability to, in an otherwise restricted space or page (no anonymous access), provide the ability for a person to choose to post/edit/comment/upload anonymously. A class is currently using Confluence to construct a collaborative poem, and the instructor suggests that anonymity would change the dynamic of how students edit. E.g. Sally might be hesitant to wipe out her best friend Tom's latest contribution knowing it's his. This functionality could be useful in other contexts (e.g. suggestion box) as well.

3. UW-Madison.  We have have a group that has a space which is tightly controlled (our Systems Engineering group).   They need to be able to open up one or more pages for public viewing even though the space itself is not publicly viewable.

4. UW-Madison.  A variation on the above.  Our Middleware group would like to issue "tickets" that allow access to a page for the recipient(s) of the ticket and/or period of time.  This is similar to the Xythos' tickets.

Provisioning into Confluence

1. We provide instructors with a web-based tool to manage the applications that support their their course. From this tool, they are able to manage fifteen different applications and services that their course might use; "manage" includes clicking a button to indicate "I want my course to be able to use this application; do the appropriate initialization". In the case of Confluence, this tool wants to 1) create a new space within  Confluence for the course, and 2) assign the appropriate permissions to this space.

2. UW-Madison.  We have a tool that manages groups across multiple collaboration tools.  We also have a Course Management System that needs to push groups and group changes into Confluence.   The initial request will also need to establish spaces and request pages in Confluence.  We need to be able to push space and page creation commands, rights and groups from a variety of tools directly into Confluence.  (This might exist via the API currently)

The Decentralized Environment

1. The dashboard on our server is getting almost unusable due to so many spaces being visible.  It is worse after a user logs in as then they all show.  What we really need is a way to organize these.  I envision an AJAX organization system where the server admin can categorize each space into one or more of these categories which would show on the dashboard and do an AJAX show/hide as the user clicks on the category name.  (Brown - PL)

2. Created Feature Request CONF-9711 for allowing space stats, like a Google Analytics.  The options that we've been given are to either increase logging through log4j, add Google Analytics in the Custom HTML area of the server or set it up for individual spaces in the Layout section under Space Admin.  The problem with each is:
Logging:our log files are already huge.  Adding the logging that would be needed for site analysis would require rotation at least hourly to keep them usable
Custom HTML: this sets one Google Analytics account for the entire server.  Whoever has access to that one Google account sees data for every space
Layout: This is great in that it is the closest to what we want.  We can set a Google Analytics account for one space, however it can only be set up by the global server admin.  When you have hundreds of spaces, this isn't reasonable.  Plus it is not upgrade proof.  It would need to be re-done with each upgrade.  Lastly, if you're running your server over SSL, you get a dialog box on every page because the Analytics code is non-SSL'd.  (Brown - PL)

Operational Issues 

1. Currently, we can not restore an exported space from a newer major version to an older major version.  And a new major version was just released (2.6.0).  So if I export some of my old spaces in my 2.5.3 server, then upgrade to 2.6.x or beyond, I can no longer import my old exported spaces.  We need this backward compatibility.  (Brown - PL)

2. At MIT, some instructors may wish to have their wiki space span semesters. This poses potential problems with regard to student privacy since a student in the Spring 2008 incarnation of the course may see identifiable postings of students in the  Spring 2007  class.  We could have students sign a disclaimer up front, but this would be difficult to do and pretty much of a nightmare6 to track. Another solution would be to have a rule that can be invoked at the space or page level and that says something like 'for postings (and attachments and comments) prior to date x, if the current user is not the user associated with the posting (or attachment or comment) and is not a space admin, substitute a generic identifier (e.g. 'Student 1') rather than the name associated with the poster'. We wouldn't want to modify the database, just the display.

3. Along those lines, for semester-bound spaces, an easy way to programatically  archive a list of spaces at the end of the term would be useful.

4. Several satellite instances of Confluence have been installed at Cornell and a current exercise is underway to migrate content from the satellite instances in departments, to the centrally scaled enterprise instance. Currently, migration between instances is somewhat manual although there seems to be standards patterns of data mapping that need to get addressed in the migration, such that a helper plugin could ease the burden of this work.

5. UW-Madison - we need to be able to grant a "domain-like space" to a large group (like the Library).  We need to able to grant a user or set of users admin rights over that "domain-like space".  They can they create new sub-spaces and manage groups and permissions under the domain-like space.  They should not have other application administration privileges.  

6.  UW-Madison - a smaller variation of the above.  We need to be able to allow a user to manage the membership in one or more groups.  They should not have full space or application administrative rites. 

7.  UW-Madison - Any anonymous post require an anti-spam bot authentication step (like a Captcha). 

8.  UW-Madison - We needed split our instances of Jira and Confluence.  We would like maintain the features that you get from a joined Jira and Confluence install even though we have split the installation and user and group management.  (I've heard the request though I don't know what the details are or what broke - J Phelps). 

9. UW-Madison.  We use the wiki to document many of our operational procedures.  Some of these spaces/pages are for emergency operations.  We need to be able to automatically export set spaces and pages to a flat html space for read only access in an emergency.  

10. It would be useful to be able to put the entire Confluence instance (all spaces, public and private) into a read-only state for occasions where we might want to redirect, for safety, to a backup server/db. For instance, when database maintenance / upgrade / migration is being done.