Implemented features are documented on FeatureList.
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).
- 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.
- Line endings get messed up.
- Quit having jsessionid for no good reason (i.e. when cookies are available) - perhaps due to invalid cookie path because of weird URL rewrites? lynx complains about cookie for '/reviki...'. Probably need to be cleverer here.
Macros outputing wiki markup no longer get rendered properly (at all?).
- Upload of attachment to e.g. ConfigHeader fails if page isn't properly created first.
- 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
- Better history UI for large number of edits.
Nuke 'old' locks and/or allow "svn unlockforce" somehow.--
- Document / expand if necessary the macro plugin API.
- Improve documentation of syntax (perhaps a TextFormattingRules page or something so as to not clutter the cheatsheet).
- Sort out a bug tracker.
(these suggestions have not yet been committed to and are of varying sanity and likelihood).
- Indented paragraphs for question / response and similar.
- 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.
- Split CSS into reviki base and custom user stuff so upgrade isn't painful.
- 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.
- Different page types, e.g. XML with stylesheet.
- Editing sections of a page.
- 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.
- 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.
- 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.
- Non-URL escaped interwiki links (%r?), for e.g. trunk:docs/readme.txt.
- 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.
- Support other (HTTPS, 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
- 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 '/').