Requests from Individual Campuses:
1. At CU Boulder we would really like AD/LDAP failover to function within Confluence (dynamic failover). As it is now, on patch Tuesdays we have to manually shut down Confluence and restart it to failover to another Domain Controller. There are feature requests in for this at Atlassian.
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 nightmare 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. 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.
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.
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.
X. Currently no way to review who has watches set on a space.
Improved LDAP Integration: It would also be useful to have more control over which AD groups can be used for authorization. The use of a single prefix is easy to implement with a search filter but is not overly flexible. Also, the current implementation only allows changes to the LDAP search filters by editing a config file and restarting Confluence. It would be preferable to be able to make changes to this configuration from the administration page.
Single Sign-On: We currently authenticate Confluence users against our campus AD. It would be nice to have single-sign-on (SSO) functionality using SPENGO / GSSAPI over HTTPS for authentication. Computers in an Active Directory environment could automatically authenticate the user when any wiki page is viewed or perhaps when the "login" button is clicked (to allow a space admin the ability to logout to check anonymous access to the space.)
Guest Accounts: A feature that would allow an authenticated user to grant other non-UIUC affiliated users access to files via emailing a "ticket" to them, one should be able to share either entire spaces or specific pages for collaborative purposes.
Other
Named Page Template Links: Our project management team has a large collection of page templates. They would like to add "create page from template" links in wiki pages, bypassing the need to navigate to the space List Templates page. Copying the "create page from template" links from the template list page is risky, since the TemplateID may change. Named, self updating "create from template" links (similar to internal Confluence page links) would solve their problem.
Multiple Personal Spaces: Some of our users have requested multiple personal spaces. Giving the end user this option would be useful, and would ease admin space creation requests.
MIT talks about needing a student disclaimer for content that would expire after a student leaves, but they don't want to handle that with professors and office secretaries, etc. Why not have the ability to add a disclaimer to any page before anyone edits: "I give up my rights to this and join the Borg and am happy with this as long as the grass grows and wind blows" In other words, let the wiki handle content permissions and build that into the system itself."