• TKM on TikiWidget
• TKM Proposed Framework: Mods
• TKM Proposed Framework: Tracker Macros
• TrackerField UI Revamp

Workflow

It seems that the workflow feature will likely be abandoned in its current incarnation in 3.0. This will open the door for a complete rewrite, which is probably a good thing.

• TKM Workflow 2.0 Design Notes

Wishlist

• Trackers
  • Reporting

This would include pulling the current CVS export into a reporting module, adding a key to the date range based on a specific date field. Additional features would include generating graphical reports in a wiki-page style for export to PDF, and facilitating graph generation to be added to wiki pages plugin-style.

• Diary

Add a diary option to each tracker, logging EVERY change made to the tracker in the tracker's comments. Good way of providing an audit trail.

• Tracker Search

Not like the keyword search, but instead a search based within the specific fields of a tracker. ie. Search for tracker ID 567, or country field like ca% (brings up all countries starting with "ca").

• Tracker dashboard

• TikiPatch

A conceptual Admin-only feature that would allow a site admin to a) detect if there are patches available, and b) if there are, download all patches to become current. This would require an automated script to generate patch files (like patch2_0_1.tgz) as part of the release process. Patches would only work for the same version of Tiki you are running. So if you have 2.0, then only 2.0.x patches are available. If you want to get the 2.1 patches, you need to upgrade to 2.1 which is a separate process. The patch feature would make it easier for admins to keep their sites secure and bug-free.

Patch file generation would consist of ONLY the files that changed from the previous patch to the current patch. So if you were two patches out of date, the patch feature would go and download the two patches you need. It would then unpack, analyze, and backup all necessary files for the patch operation, then replace them with the first patch. Then it would analyze, and backup any files just patched (if necessary) into the old patch version's directory, and replace with the next patch, and so on until all files are current.

Would provide a status interface as well. Runs under the assumption that no database changes are necessary and only changes are in scripts to patch security holes and/or fix bugs.

Possibility of automating this somehow? Should be fairly easy to accommodate database updates as well if it becomes necessary.

• Improved site stats page (utilize a dashboard)

• AdminUI Dashboard

• Sister-wiki archival of data to another wiki where information is available, but with less processing resources

• Windows/MAC Java desktop mini-app that interfaces with a Tiki server to allow drag and drop to/from file galleries and desktop, as well as pop-up alerts based on watches so you don't have to have the browser up all the time

(See TKM on TikiWidget)

• When uploading images to a wiki page or attaching files to a wiki page, use a hidden System file gallery.

Hierarchy might look like:

1. System
   1. Trackers
      1. Item 1
      2. Item 2
   2. Wiki
      1. WikiPage A
      2. WikiPage B

Where all of the above are actual file galleries, and any image that you add to the page, automatically gets added to the appropriate file gallery. So if you attach an image to WikiPage A, if a gallery doesn't exist for it, Tiki will create one, and store the image in that gallery. When the page comes up, it'll automatically reference the image in that gallery.

Hitlist

• What I'm Working On
  • Tracker reporting
  • Upgrading our corporate site to 2.0
• My Short-term TO-DO List
  • Improved tracker reporting
• Tracker diary
  • Locking of trackers (read-only)
  • Tracker archiving (instead of delete, make historical archive)