TodoList - from r912 to r913

Implemented features are documented on FeatureList.

== Pre-1.0 todos
The 1.0 release is focused on the use of reviki for a small, trusted, team of users.

The motivation for the inclusion of features / enhancements below is to get a sense of //completeness// - obvious features should be there - and trouble-free operation (arguably being unable to break a lock through the web UI is a bug).

Bugs:
* --History for a page will includes entries for unrelated pages if there were commits spanning multiple pages (e.g. initial import).--
* --Page name in history should link to relevant revision.--
* --Revision number in title is head, should be last edit revision. Done in r637.--
* --Auto-focus search box is annoying for long pages. Done in r642.--
* History / RecentChanges etc go blank if moving SVN locations (within a repo). This will probably be awkward to fix due to using an SVNRepository based at the data URL so anything above that gets ignored.
* Dates need translating to local time.
* Line endings get messed up.
* Quit having jsessionid for no good reason (i.e. when cookies are available).
* --Error parsing links with URL after the text (should be invalid, must not barf!). Done in r903.--

Features:
* Store svn log data so we don't svn log from time zero on start-up. This gets slow though I've only got to the point of impracticality with the wiki/svn I run automated tests against.
* Bring attachments up to same standard of functionality as regular pages
** Delete
** Better history UI for large number of edits.
** --Add attachment link to page when uploading attachment. Pick image link based on extension list, otherwise regular link.--
** ---Set svn:mime-type using config page for extensions map. Currently we use the autodetect algorithm (just gives app/octet or text) which is very likely to get it wrong for PDFs.--
* Nuke 'old' locks and/or allow "svn unlock --force" somehow
* RefactorRename.
* --favicon, use the same for opensearch.--
* Document / expand if necessary the macro plugin API.

Misc:
* Improve documentation of syntax (perhaps a TextFormattingRules page or something so as to not clutter the cheatsheet).
* Sort out a bug tracker.
* --Arrange for automated build/test on reviki.org.-- (given up on test due to memory constraints, builds at NightlyBuilds).

== Future
(these suggestions have not yet been committed to and are of varying sanity and likelihood).

* Rendering
** Indented paragraphs for question / response and similar.
** AutomaticTableOfContents
** Anchors for headings
** Be less c2:UgLy (or, erm, find someone who has patience with CSS and get a decent basic layout).
** Spreadsheet-like functions for tables
** Checkboxes for TodoLists.
** Footnote support.
** Link email addresses.

* Editing
** Sub-pages / some notion of hierarchy.
** Cope with locks being pulled out from under us somehow (i.e. make sure we don't lose data).
** Prettier handling of CreateNewClash.
** WYSIWYG
** Different page types, e.g. XML with stylesheet.
** Editing sections of a page.

* Search
** Limit search results to pages discoverable from a given page (or possibly within a certain number of jumps from a given page).
** Improve google-suggest-style search to allow page name prefixes, not just wiki name parts.

* RecentChanges / History
** Use a date format with day name (short). Optionally do ThunderbirdMailClient 'today', 'yesterday' type formatting.
** Properly rendered diffs.
** DiffViewNavigation
** CollapseSameUserEditsInRecentChanges
** Recent changes should allow edit starting from old copy as a way of reverting
** SVN blame/praise/annotate. Interesting to see if we can (cheaply) avoid doing it line-wise.
** If user name is WikiWord then link to name page from RecentChanges etc.
** rel="nofollow" on non-content links... a search engine ought not to be looking at non-existant pages or pages that will have meta noindex. Currenly we just add noindex meta tag to all pages accessed with a query string as an easy hack to stop search engines going through all the history and diffs.
** Email notifications of page edits.
** RecentChanges with ?showMinorEdits should be linked somewhere.

* Linking
** Links to specific revisions.... could just use URL (relative works most of the time) but maybe FooBar@124 would be useful.
** Link completion
** View of wiki at past revision - this works for specific pages with revision query string param (revision=$number) but probably want it in the path instead so can navigate whole wiki, e.g. http://...reviki/revision123/pages/Foo. Backlinks would still be for trunk though.

* Dynamic content
** More work on the XmlQueryLanguageMacrosForIntegration plugin.
** ...more ideas to come.

* CMS/Blog-like features
** Blog style pages where we add a file to a directory each time an edit is made. Distinguish page types by property on file/dir.
** Ability to hide edit controls etc.
** Branching / staging. Either individual pages or entire wiki. Anything that requires merge is awkward though...
** Ability to choose the menu for a given page. Menus are pages (as for the current ConfigSideBar).
** Shift from JSP to templates we could store as wiki pages. Perhaps. Would be great for customization but not so good when it comes time to upgrade. Something other than JSP would be easier to test too.

* Security / authentication
** Cope with untrusted users with edit rights
** Secure ConfigPlugins (arbitrary code upload!)
** Disable / sanitize raw HTML.
** Ability to restrict edits of a list of topics to a list of users... not sure how general to go here...
** Work with anonymous users (currently fail to lock pages and confusingly display empty string in place of usernames when reporting on anonymous commits).
** Allow security / users distinct from those provided by SVN.
** Form based authentication.

* Deployment
** Support other (non-HTTP) repository types.
** Ability to automatically set up a local file based repository.
** Improved mechanism for authenticated public deployments without using a proxy to add security. This means preventing changing of the ConfigSVNLocation and the adding of new wikis. This is currently done using the read-only status of the config file.
** openid support

* Misc
** Accessibility, starting with keyboard shortcuts for buttons, search box and RecentChanges, if possible.
** Pretty error pages.
** Rendering issues: review Creole functional tests and RenderingBugs.
** Investigate encoding issues.
** Configurable FrontPage (i.e. use some other page for '/').