Feature Requests for OpenACS.org's XoWiki

Overview: 

Most of the Feature Request are complete.  THANK YOU GUSTAF AND DAVE! I am adding a few minor enhancement requests and removing the completed requests.

Participants:

Some comments to the requests from Gustaf Neumann

Comments and responses by Robert Taylor

Feature Requests:

1.  DELETING DOCUMENTS - Normal users should not have DELETE privileges, but administrators should.  As an administrator I don't see a DELETE option in the menu in the top right hand of ever page.  Perhaps DELETE should go between NEW PAGE and INDEX items.

    Added delete button on the view page. mostly useful, when the default listing of all entries is replaced by a tailored index page
 

2.  HIERARCHICAL CATEGORIES - Left hand menu needs to properly show SUBCATEGORY WITHING SUBCATEGORY in a hierarchical relationship.  Clearly one thing we will have to take into consideration is hierarchy layout and spacing issues - do we preload all categories or do we just preload a preset number of levels down and then dynamically load the rest below a certain threshold. Dave mentioned the ui component has to be coded up to handle that type of layout.

     Hierarchical display of categories added to the version in CVS head. Spacing is a matter of style-sheets.  

3.  XINHA SUPERPOWERS - Xinha is one amazing editor, and just looking at their page it's still  not complete.  I think we need to look at stripping some of the features out of our Xinha install on XoWiki.  This should probably be based around generating a STYLE GUIDE for the wiki and basing our Xinha hacking on that.  Dave mentioned it is possible to take away Xinha features fairly easily so we will look at that further.

 xinha is configured via plugins (see http://xinha.gogo.co.nz/xinha-nightly/examples/full_example.html). xowiki uses per default the following settings, which are some standard options plus the OacsFs plugin contributed by Günter Ernst and me.  The standard behavior  can be modified by the settings of the WikiForm (in xowiki-procs) for the whole installation. a per-instance setting will follow in the future

4.  ADMINISTRATION SECTION - If you select the "WOIKI" item in the location area on the page (OpenACS Home : xowiki : New XoWiki Page) the link seems to alternate between the INDEX page and ADMIN page although it seems a bit random.  I think this is probably a bug, but it should be changed to the following:

a) Selecting XOWIKI in the location of the page should always go to INDEX just like the item "INDEX" the the wiki page UI does. 

b) For administrator we should add and item ADMIN to the wiki page admin menu so that the administrator can go to the admin section and work on templates, delete documents, etc.

 can't reproduce a. xowiki in the breadcrums and index both point to oacs.orig/xowiki, so they should return same values. in earlier versions  there was a caching bug, which is - i think - gone since end of Feb.

concerning permissions etc. currently, xowiki uses a simple permission system: it checks write permissions on the folder, these write permissions are used distinguishing admins and readers. future versions should have a much richer permission system, where one can use alternatively different permissions policies based on per page permissions (this is however, much more expensive and will use much less caching). for now, do you folks want in addition to the new delete entry also an admin button in case a user has write permissions on the folder?

5.  PRINT PAGE - All users should have an item in the wiki page menu (for every wiki page) labeled "PRINT".  This action would refresh the page content and / or bring up a popup with the content of the page in a printer friendly format without various user interface components.

6.  IMPORT / EXPORT DIR TREE - The ability to import/export a directory tree of XoWiki documents has use for OpenACS.org and arguably as a general XoWiki feature. In the case of OpenACS, exporting would allow these /xowiki pages to be saved into static pages so that they can be read independently of OpenACS.org and independent of having a local running OpenACS system.

Problem example: OpenACS moves documentation to XoWiki. Documentation is no-longer available as static pages on local machine(s). Users/admins become dependent on reading docs from OpenACS.org or spidering the pages using wget etc.. of course most likely during the busiest times that OpenACS is being accessed ;) etc. etc.

7.  PAGE REVISION (AS TIMESTAMP) - Exporting files (request 6) would bring about questions of comparing file exports (at least on a page by page basis). Having a page revision displayed on each page as a timestamp would help to reduce any ambiguity as to which statically exported page is more current --regardless of export technique (wget, XoWiki export feature etc.)

 

 

Bugs

• xowiki is not visible in IE. Must be a CSS issue. Has someone an idea why this happens?
  • no kidding?!  doesn't work in i.e. will post bug
  • fixed. this was an unclosed script tag in the  xowiki installation on opeancs.org
• For some reason I always get a popup window: "Error reading Language-File (/resources/acs-templating/xinha-nightly/plugins/OacsFs/lang/de.js) - Syntax Error: missing ; before statement"
  • must be something on oacs.org, does not show-up on other installations. i have developed the plugin, and do not have the mentioned file.
• The CodeMatrix includes need a little clean up: left alignment and top valignment for each heading
  • must be done by someone at oacs.org or vinod. most probable some CSS fiddling.

Display

• Page language: Wouldn't it be more readable and less technical if we would not display the language shortcut "en:" or other before each link to a wiki page?
  • one can use arbitrary labels in a reference between square brackets.
• The category tree on the left breaks long names which is ok but the next line should have more left margins in order to start right after the dot. Another solution would be to cut off the tail of long names
  • CSS fiddling. should be done by someone with CSS knowledge and  taste. uses currently the original settings  https://openacs.org/resources/acs-templating/mktree.css from http://www.mattkruse.com/javascript/mktree/documentation.html|mktree

Further Features

• support for NOTIFICATIONS for xowiki so that you are notified if a page was added or changed
• List view for category nodes that displays all children on the right when you click on it.
  • don't understand. you mean, without expanding the current page?
• Display the name of the person who edited the page in "Latest Page edits (ADP portlets/categories-recent {name {Recent Entries by Categories} max_entries 30)

Packages

• Any chance that we ca define a sub type PackagePage that automatically provides the info, bug-tracker and code metric includes?
• Some kind of traffic lights that shows green, yellow or red depending on the maturity of the package, db support
• More categorization for packages: Core, Non-Core is too technical, no?
• When clicking on a category it would be great if the list of all packages within the category are displayed as APM does on upgrade/installation time.
  • sounds like a different or additional category tree