...
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.
...
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.
...