Loading...
 

another patch on aulawiki.1.6.2 for tikiwiki.2.2 + a new workspaces

Status
Closed
Subject
another patch on aulawiki.1.6.2 for tikiwiki.2.2 + a new workspaces
Category
  • Patch
Feature
Workspace
Resolution status
Out of Date
Submitted by
pingus
Lastmod by
Marc Laporte
Rating
(0)
Description

These are more patches on aulawiki.1.6.2 posted by xavi

  • Versions 1.6.2x are intended just to make aulawiki work on tikiwiki

2.2, the way it worked before.

  • Versions 1.6.3x -1.6.4 were transition step.
  • Versions 1.6.5x -1.7.x has put back capability to add groups to the

workspace (not only users), and see all child's groups, starting from
the topmost a user can admin, when adding perms to single workspace
resources.
This was be done by adding some new functions to workspaceslib.php:

- get_includable_child_workspaces_groups : will get all groups in WS and child workspaces, starting from the uppermost on which one has admin objectperm down, purged by veryfing a list of includable groups to avoid loop inclusion.
- user_can_admin_workspace_or_upper(), an alias of
get_topmost_workspace_Iadmin(): will get up in the workspace path and
return an upmost parent workspace one can admin, thus gives him admin
capability on the ws and children, or false.
And in lib/workspaces/userslib.php, function group_can_include_group() will check if the group we are trying to include can be included.

with these functions a RolePerm with tiki_p_admin_workspace has
view of all child workspaces and their groups down from the
topmost one he can admin, no matter in which of these he is actually
(current workspace), and be able to add groups and assign perms to
groups within all these ones (only) without need of of having
tiki_p_admin_workspaces also on any child ws.

To the intermediate objectperm tiki_p_create_workspace_resour has been given as a gift the possibility to add single users, not groups, to the workspace predefined groups. On the other hand he can grant objectperms to his resources choosing among any group that belongs to his 'workspace-level'(brothers workspaces) + his parent's (dad, see what I am doing!)

This behaviour is easily changeable in the code, as the ability to do things is stated at the top, where (object)permissions on the workspace are tested once and translated into variables used throughout the code.

In practice:
=====

  • 'tiki_p_admin_workspaces' as an objectperm on a WS (got

from the RolePerms template for that type of Workspace) is de-facto a
local Workspace administrator. He can do everything (create new sub workspaces, add groups, change perms) except define new
workspace types and roles, and he sees only groups starting from the
topmost workspace he can admin to the bottom.

  • tiki_p_create_workspace_resour, as objectperm on a WS (got from the

RolePerms template for that type of Workspace), can manage objectperms
of his ws resources (excluded the ws object itself) choosing among
a tree of groups that starts at his parent's level (dad, see what I am doing), includes 'brother workspaces' (on the same level, child of the same parent), down to bottom. He is a resource manager. For adding users/groups to the ws, he can only add single users by typing the name, no groups. But if his ws has an admin group, he could add himself there. So tipically workspaces either have a ws_admin role OR a ws_resource manager role. On the other hand, a top, empty (no resources) workspace, with only an ws_admin role, would grant administration to all childs.

  • For global tiki_p_admin_workspace nothing changes, although he is now prevented from including groups that include the includer, something that would put the entire site down.


For a user that has the approriate objectperms from the roles template
to the workspace (tiki_p_admin_workspace or, with less possibilities,
tiki_p_create_ws_resour, for the workspace object), everything can be
done starting from the resources module that has extra links to create child ws, add users/groups, and assign perms to resources.

The resouces module will show/hide Buttons and icons next to each
resource accordingly to what can be done by the actual type of user.


Most of the modifications happened in :

- tiki-workspaces_objectpermissions.ptp + templates
- modules/mod-workspaces_users_groups.php + templates
- lib/workspaceslib.php (new functions only)
- lib/users.php (new functions only)

With respect to the connection workspaces-categories, nothing should be changed. All categories related code is still there and used as before.


New permission scheme 1.7.0:

Copy to clipboard
1.6.2 ------------------------------------------------------------------------ perm allows as allows as name group perm objectperm ------------------------------------------------------------------------ view_ws - -view the ws create_resour - -create resour onws admin_ws do all on any ws -add group/user to ws 1.7.x ----------------------------------------------------------------------- perm allows as allows as name group perm objectperm ------------------------------------------------------------------------ view_ws - -view the ws create_resour - (1) -create resour on ws (de facto admin resour) -change perms on ws resources (excluded the ws itself) choosing from the father ws groups and childs (father+brothers-to-bottom) (3) -add single users(not groups) to ws predefined groups admin_ws -do all on any ws(2) -create child workspaces for any ws from the topmost ws he has admin rights -change perms on ws object itself & resources & child-ws objects and resources choosing from the topmost ws groups he has admin rights -add any groups to any ws choosing from the topmost ws groups he has admin rights -create child workspaces to any ws from the topmost ws he has admin rights notes: (1) this slot is free! Can't we use it to allow the creation of an 'organic workspace' of some predefined type with himself as tiki_p_create_resour objectperm on it? (2) as he can add the 'admins' group, and add users to it, he is defacto a tiki_p_admin. maybe he should only be able to add 'workspaces groups'? This would make him different from a tiki_p_admin_groups and tiki_p_admin. see comments and examples of different possiblties in mod-workspaces_users_groups.php (3) see comments and examples of different possiblties in tiki-workspaces_objectpermissions.php --------------------------------------------------------------------- TODO: there's quite a lot I think, especially in the interface, making it nicer and more intuitive. -Add confirmation steps for various deletion actions -Deletion of workspace does not delete its objects (should it?) -test it really hard -understand first, and maybe integrate, the working of 'Private Zones' and 'user Workspace types' (isuserWS and userws filed in table).

LATEST NOTE:
Version 1.7.x has been committed to svn trunk.
You can now download the up-to-date version (not in mods format though) from:
https://tikiwiki.svn.sourceforge.net/svnroot/tikiwiki/mods/trunk/features/aulawiki/
The mod in the repository does not provide a working example of these new features, it has the usual Teacher/Student Roles. One has to define roles with 'tiki_p_admin_workspace' and 'tiki_p_create_workspace_resour' to see this in action

Priority
25
Demonstrate Bug (Tiki 19+)
Please demonstrate your bug on show2.tiki.org
 About show2.tiki.org

To help developers solve the bug, we kindly request that you demonstrate your bug on a show2.tiki.org instance. To start, simply select a version and click on "Create show2.tiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show2.tiki.org.

Version: Create show2.tiki.org instance
Demonstrate Bug (older Tiki versions)
Please demonstrate your bug on show.tikiwiki.org
 About show.tikiwiki.org

To help developers solve the bug, we kindly request that you demonstrate your bug on a show.tikiwiki.org instance. To start, simply select a version and click on "Create show.tikiwiki.org instance". Once the instance is ready (in a minute or two), as indicated in the status window below, you can then access that instance, login (the initial admin username/password is "admin") and configure the Tiki to demonstrate your bug. Priority will be given to bugs that have been demonstrated on show.tikiwiki.org.

Version: Create show.tikiwiki.org instance
Ticket ID
2297
Created
Monday 09 February, 2009 22:29:24 GMT-0000
by Unknown
LastModif
Monday 10 June, 2013 01:52:31 GMT-0000

Attachments

 filenamecreatedhitscommentversionfiletype 
workspaces-1.6.2b.tgz 26 Feb 09 19:33 GMT-0000162
README-1.6.2b.txt 26 Feb 09 19:35 GMT-0000260
changelog-1.7.0.txt 27 Mar 09 10:39 GMT-0000240
README-newperms-1.7.0 27 Mar 09 10:41 GMT-0000195
README-newperms-1.7.0 28 Mar 09 07:32 GMT-0000198
aulawiki-1.7.0b_svn_Rev-17656.tgz 31 Mar 09 05:15 GMT-0000254svn rev 17657


Keywords

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

Accessibility (WAI & 508)
Accounting
Administration
Ajax
Articles & Submissions
Backlinks
Banner
Batch
BigBlueButton audio/video/chat/screensharing
Blog
Bookmark
Browser Compatibility
Calendar
Category
Chat
Comment
Communication Center
Consistency
Contacts Address book
Contact us
Content template
Contribution
Cookie
Copyright
Credits
Custom Home (and Group Home Page)
Database MySQL - MyISAM
Database MySQL - InnoDB
Date and Time
Debugger Console
Diagram
Directory (of hyperlinks)
Documentation link from Tiki to doc.tiki.org (Help System)
Docs
DogFood
Draw -superseded by Diagram
Dynamic Content
Preferences
Dynamic Variable
External Authentication
FAQ
Featured links
Feeds (RSS)
File Gallery
Forum
Friendship Network (Community)
Gantt
Group
Groupmail
Help
History
Hotword
HTML Page
i18n (Multilingual, l10n, Babelfish)
Image Gallery
Import-Export
Install
Integrator
Interoperability
Inter-User Messages
InterTiki
jQuery
Kaltura video management
Kanban
Karma
Live Support
Logs (system & action)
Lost edit protection
Mail-in
Map
Menu
Meta Tag
Missing features
Visual Mapping
Mobile
Mods
Modules
MultiTiki
MyTiki
Newsletter
Notepad
OS independence (Non-Linux, Windows/IIS, Mac, BSD)
Organic Groups (Self-managed Teams)
Packages
Payment
PDF
Performance Speed / Load / Compression / Cache
Permission
Poll
Profiles
Quiz
Rating
Realname
Report
Revision Approval
Scheduler
Score
Search engine optimization (SEO)
Search
Security
Semantic links
Share
Shopping Cart
Shoutbox
Site Identity
Slideshow
Smarty Template
Social Networking
Spam protection (Anti-bot CATPCHA)
Spellcheck
Spreadsheet
Staging and Approval
Stats
Survey
Syntax Highlighter (Codemirror)
Tablesorter
Tags
Task
Tell a Friend
Terms and Conditions
Theme
TikiTests
Federated Timesheets
Token Access
Toolbar (Quicktags)
Tours
Trackers
TRIM
User Administration
User Files
User Menu
Watch
Webmail and Groupmail
WebServices
Wiki History, page rename, etc
Wiki plugins extends basic syntax
Wiki syntax text area, parser, etc
Wiki structure (book and table of content)
Workspace and perspectives
WYSIWTSN
WYSIWYCA
WYSIWYG
XMLRPC
XMPP




Useful Tools