Differences from version 4 to 9



@@ -1,4 +1,4 @@

-^This page is intended as a feedback tool for wiki progammers from wiki admins and end users. Please add/edit/remove as you please. The actual features and upgrades currently planned for the next major release are viewable at ((new for R2)).
+^This page is intended as a feedback tool for wiki progammers from wiki admins and end users. Please add/edit/remove as you please. The actual features and upgrades currently planned for the next major release are viewable at ((new for R2)). New feature discussions are happing at ((ReleaseThree))
 
 Different wikis have different uses. This version of the Ultimate wiki CMS is based on a ((wiki as groupware)) perspective.
 ^

@@ -31,33 +31,51 @@

 **robust object permission management (can set perms for individual objects)
 **watch feature (notify by email)
 
-!!Group Category and Object Permissions system.
+!!Group, and Category Permissions system.
+The permissions structure inherited from tikiwiki was fairly robust, and by tikiwiki 1.9.2 a fully customizable group ''and'' category permissions regime emerged. This beats mediawiki and most other wikis because it allows for multiple private areas assigned to any number of groups (who may or may not have the same general permissions).
+
+
+!!!Basic logical structure
 *Category is a set of any objects (including modules)
+**objects can have many categories assigned/nonexclusive
+**categories are organized in heirarchies.
 *Group is a set of any users.
+**users can be assigned to many groups/nonexclusive
+**groups are organized in heirarchies (permission sets can include other groups)
+
 !!!Group Permission Sets
-*Default 4 or 5 level Group Heirarchy, editable
+*__General Permissions___ have a default 4 or 5 level group heirarchy, which is editable. (so all new installs have a ready to go basic heirarchy)
 **anonymous - can alter little or none.
 **registered - standard user perms
 **editor - power user perms
 **admin - system wide perms
 **god - create and define admins
-*Batch import and export by group.
-*users may give permissions they have to other users
+*__Batch Import and Export__ by group.
+*__Allow delegation and promotion__ users may give permissions they have to other users. Delegate means permission is granted conditionally by a senior user and can be removed by same person (who may be implicitly/explicity responsible for their delegates). Promote is a "permanent" upping of perms (which can of course be removed by admins).
 
 !!!Category Permission Structure.
 
-Permission Structure
-1. Can Y do X for this module (based on group)?
-2. Can Y do X for this object (based on category)?
+__Category Permission Structure__
+The trinity of permissions checks
+1. Can user of group Y do X for this module ?
+2. Can user of group Y do X for this category ?
 3. Are there any object specific exceptions for Y on X? (i.e. password required each time)
 
-iow category overrides module and object overrides category and module.
+__The more local the permission, the more dominant__ category overrides module and object overrides category and module. This is good because it enables the fastest application of all permissions by administrators.
 
-*There are three kinds of categories
-**tag category - a label only
-**tag + perm category (user viewable category with defined permission set)
+__Three kinds of categories__
+Categories can be used in two ways:
+*tags for sorting and structure
+*perms for access control
+
+Sometimes you want only one of these functions, sometimes both. If the category is a tag, you probably want it displayed (ok maybe there are some display-categories-to-group possiblities)
+don't want to display a category, just have it turned on to provide access control. In this way, there are three ways categories can be used.
+
+*a "tag" - which is a label only
+*a "tag + perm category (user viewable category with defined permission set)
 **perms only category (non user viewable category with defined permission set)
-*objects may inherit permissions from object they were created from.
+
+__Objects should inherit permissions__ from object they were created from. (is their any reason why this should not be default behavior)
 
 !!!Categories from namespaces:
 pagename begins with or includes string x is automatically assigned to category y.

@@ -160,6 +178,10 @@

 *exact match goes directly, rather than to list.
 *page names only, with option to search body.
 *a real search engine that ranks by relevance.
+*limit search by date of last modification - After and Before parameters
+*limit search by date of creation - After and Before parameters
+*limit search by Category - allow multiple categories
+*limit search by Tag - allow multiple tags
 !!!Navigation
 Support four types of wiki navigation
 *knowledgebase, organized by tagging, wiki hubs, or naming conventions (consistent NC = easy intra wiki navigation)

@@ -170,15 +192,18 @@

 **drop down menus
 
 !!Admin Features
-Mass revert (for spambots)
+*Mass revert (for spambots)
+*Editable error messages (all messages generated from a wiki page, essentially.)
 
 !!Documentation
-!!!the hardcore "wiki people, Eat your own dogfood" method.
-*project site contains knowledgebase including all relevant terms.
-*visitors as a question only on the relevant page and in edit comment window.
-*developers get changelog as rss. and answer only by editing pages
+!!!the hardcore "wiki people, eat your own dogfood" method.
+*project site contains knowledge base including:
+**__a page for every page__ - for each and every admin/config screen there should be a page in the documentation, named after the url, which explains all the options.
+**pages which define and explain all commonly used terms and concepts, like what is a "category" in bitweaver.
+*__no help by forums, nor by chat, nor by email__. Those seeking help need to be trained to help everyone, and save everyone's time by only asking questions in the documentation wiki itself.
+**developers get the recent changes / changelog of the documentation as an rss. and answer only by editing pages
 *shut down all forums and listserves
 *don't answer questions by email or irc.
 __End result__ a somewhat messy but highly comprehensive and up to date documentation.
 !!!category: travelling documentation
-all stable parts of the knowledge base should be included in the startup wiki DB.
+all stable parts of the knowledge base should be categorized as such, included in a structure which publishes to PDF, and included in the startup wiki DB.
Page History
Date/CommentUserIPVersion
13 Aug 2011 (13:50 UTC)
Added to Search gunction - limit by dates, category, tag
Richard Be-Involved211.30.210.69
Current • Source
mlpvolt207.112.51.2328
View • Compare • Difference • Source
mlpvolt207.112.51.2327
View • Compare • Difference • Source
mlpvolt72.60.206.2136
View • Compare • Difference • Source
mlpvolt72.60.206.2135
View • Compare • Difference • Source
mlpvolt72.60.206.2134
View • Compare • Difference • Source
mlpvolt69.195.4.523
View • Compare • Difference • Source
mlpvolt69.195.4.522
View • Compare • Difference • Source
mlpvolt69.195.4.521
View • Compare • Difference • Source