Tiki Core Components

Note: Core services do not offer any user interface — just API. All user interface managed by corresponding extension... or some core extension — it is extension like all others.

Extensions Management

• Scan for new/removed extensions
• Maintain extensions table — i.e. sync DB table and actualy present files
• Execute extension installation/uninstallation routinues
  • Install can include DB operations (adding new entries to existing or create new tables)
  • Also TEM can install/uninstall packaged extension (what format?)
    • [+] This will helps to implement online updates
    • Updates can be automatic 😊
    • RPM sounds good... but windows users fail to handle it 😑(
  • Maybe some consistency checking? I.e. detect broken installation of extension package or core files and warn user.
  • Even more crazy: check signature (package or individual files) — for high secured Tiki sites
• API for extensions
  • get list of installed/enabled extensions
  • is_installed('extension') / is_enabled("extension")
• There is no other way except core API for one extension to get (and work with) instance of another
• List of capabilities of extensions, like functions that give extensions to the system for the use of other sections
• Prerequisites (things that have to be installed to make it work, i.e. other extensions)
• Conflicting extensions/capabilities (something that would be nice to avoid, but probably is not possible, i.e. 2 extensions that give the same capability but in a different way, or use the same table/field in a exclusive way)
• smth else?

Objects and Permissions Management

• Every extension may 'register' new object type it work with (can produce)
• Tiki Core Objects — can't be unregistered (existed even if no extensions installed)
  • [+] User — represent one user in Tiki system
    • [+] ID
    • name
    • smth else...
  • Group —
    • [+] ID
    • name
    • members
    • smth else...
  • More core objects
    • [+] Role — assign user to 'role' equ to grant permissions (assigned to role) to him, removing user from role will revoke permissions.
    • Container — container for other objects
    • File collection
    • Texts collection (maybe with attributes saying something how to interpret it, like it contains html tags or it contain wiki tags)
    • Thread (for ordered/hierarchical content, links to father/childs/next object)
    • smth more??
• Every object in system belongs to some category (possible more than one). By default it is equal to Root (Top) and maybe reassigned by admin later.
• All Tiki objects belongs to ))GlobalObjectsTree((
  • There is special containers in this tree
    • Users/Groups — core objects represent users and goups. Assigning permissions to whole container mean that user granted rights to manage other users or gorups.
    • Installed Extensions — list all installed extensions here. Grant permissions mean that user can manage (configure) some extension (or all of them if container permissions applied)
    • Categorized Objects — application objects (like wiki pages, articles, FAQs, etc.) and categories. This is a categories tree in nowdays Tiki.
• Permissions can be granted on Root of GOT or any other node/leaf of this tree
• Permissions can be granted to user or group (role, smth else?)
• Permissions given on some container will be inherited by all containers and objects below
• Permissions can be revoked on some low level even if upper level grant such permisions... So we r talking about effective permissions != assigned.
• Maintain ACLs as internal run-time data structures
• Evaluate user permissions on given object
  • [+] Yes need walk through categories tree!
• API for extensions
  • manage user/group permissions on objects or categories ...)/revoke(...
  • check user permissions (is_granted(...)), evaluate permissions
  • list of permissions with description
  • extend core rights with extension's addon
  • object_type (user/group) and object_id (maybe name will be enough) should be passed as arguments to all permission functions, so API can be used for 'effective permissions' evaluation (i.e. w/o relogin admin can check what permissions granted to another user/group — of couse if admin interface will allow this 😊
• API for user management
  • create/delete users
  • enum users
  • get/set user info (core attributes like name, smth else...)
  • get/set user preferences — map key => value
    • [+] this will allow any extension to store preferences for user in unified way — via core API
    • even if extension installed and then uninstalled next time installed it appear for user with configured preferences (see also below about mass update)
    • i.e. this like users $HOME (or HKCU for windoze users 😊
• API for goup management
  • create/delete gorups
  • list groups
  • add/remove/list members
  • get/set group info (core attributes)
• Work with core objects and permissions from extension should be possible only through API so future changes (even rewrite) of PM subsystem possible, with unchanged external API interface of couse.
• More effective instead of permissions is to use rights...
  • [+] Possible values for right can be combination of letters r, w, a (instead of just y/n) with meaning
    • r = readonly access for user
    • w = user can write/change given object
    • a = user can admin this obejct (i.e. can manage access to this object of other users or/and set properties)
  • For example 'Wiki' extension can register in core tiki_wiki_page right. So user can be granted 'read', 'write' (or both) rights to some wiki page. Adding 'a' (access control) will allow him to grant 'r'/'w'/'a' rights to other users... In terms of permissions to do this need tiki_wiki_page_view/tiki_wiki_page_edit/tiki_wiki_page_admin
  • ... so all of above will reduce count of permissions and unify all user-object relations to read/write/admin
• ... and take Tiki to another level of <del>permissions</del> rights management 😊
  • [+] ... yet another cool level of control right filters — i.e. it is possible to filter rights on container/object.
    • Suppose some user have 'w' on some category (this mean on all objects and other categories below). Apply filter mean wheather or not inherited rights effective on object where filter configured — i.e. which rights can be inherited to levels below this.
• Mass user operations
  • Admin (user with 'a' on users container) can set/change properties of more than one user at one operation...
  • ... so admin can assign any property to user(s)... from module in interface to change theme...
  • Is it reasonable to talk about 'policies' (like Windowz policies) applied to user?

Core Abstractions

DB Layer

• Handle queries to configured DB and return results to PHP
  • DB abstraction team plz append more details here 😊

Extension

• Every custom extension should inherit from ))TikiExtension(( class
• Can have install/uninstall procedures
• Can be enabled/disabled
• Can provide entries to dynamic menu
• Can draw extension configuration page when required, load and save configuration data
• Can draw 'module' (yes it is module box in nowdays Tiki) — it can be the only that extension do 😊 — then ))TikiExtensioncalledTikiModule((
• Can provide API for other extensions
• Can use API of other extensions (get another extensions instance before via core API)
• 'Core' Extensions — builtin extensions
  • [+] Admin interface — extension to draw configuration pages of other extensions
    • require that if extension need to have configuration page it should provide method to draw configuration form by request, load and store results
  • Main Menu extension — build dynamic Tiki application menu from enabled extensions. I.e. if Wiki extension enabled it can add some menu items in global menu system... like: list pages, last changes, & etc.
    • require method which is return menu entries to add to dynamic menu
  • Workplace Layout and Theme control

Design notes

• Of couse OO used to implement all core services
• Class TikiCore contain no code! It is just facade class for core components (like EM, OPM, DBL, ...) which is of couse classes too...

Future ideas

Not Tiki Core related...

• Smart (intellectual) environment 😊
  • [+] just some ideas:
    • ... there is no need to show login box when user already logged in
    • ... modules can be up/down automaticaly depending on user 'hits' (i.e. most usable on top)
    • ... there is not needed to show changes_from_last_login more than N times after login (resonable default 3-5) — usualy this info interested just after login
    • ... messages count (module) interested only if new/unread messages waiting in inbox
    • ... appilcation menu can dynamicaly reorder items in to popup 'most usable items on top'
  • ... looks like 'modules' can be shown using banner engine technologies with wide range of targeting 😊
• Wiki pages
  • [+] Wiki parser should be rewritten using FSM (need to build FSM before and then update it if neccessary)
  • yet another page view mode using <del>/<ins> HTML tags to highight changes after previous version
  • auto glossary generation/referencing
    • page/category/site wide
    • collect terms automaticaly
  • auto quote
  • auto align/indent
  • — i.e. superscript number in text and explanation on page bottom
• smth else... don't remember all my ideas 😑

See also

TikiDesintegration