- Add a table with information (ItemId, fieldId, ChangeDate, old Value, who) will be enough to cover the major needs
- Search on this table who modified this field - Value of this field
-> on sylvieg todo list - other volunteer welcome
- Develop a module to obtain easily a list of fieldId/Field Name for a tracker - to simplify TRACKER configuration
-> on sylvieg todo list - other volunteer welcome
- Need to reduce the user of user selector field to a list of the users of a set of groups
- Regular expression on a text or textarea field to validate the content of a field
-> on sylvieg todo list - other volunteer welcome
- in trackerlist list field, when creating an item, be able to go back
on sylvieg list - except other volunteer
lph? Kerrnel?
Trackers needs to be rewritten - for maintenability and performance. a tracker Entreprise feature that will replace. Seems that nobody is ready to finance the redesign. Seems that the actual will have to be more clean - plus redesign on a daily basis
Tikiwiki's permission is very powerful and flexible, but there are many internal issues with it. At this time, the code is not built to be testable and is very prone to breaking. Because it handles the content ACL, failure in this library can cause serious trouble. The implementation is also very slow and requires a very large amount of queries to execute, especially when filtering lists.
From the user perspective, the current implementation of category permission is counter intuitive. On categories, only view, edit and admin permissions are available. These permissions are aggregates of lower level permissions. Fine grained permissions using the same names as in the rest of Tikiwiki to improve consistency and increase flexibility.
A complete rewrite is required to solve these issue. The objective of the rewrite are:
- Preserve current functions as a compatibility layer
- Build an extensible, testable and comprehensive layer to permission access
- Improve the support for category permissions
- Serve as a decent basis to build workspaces on
People involved:
A workspace is a view of the content adapted to a working group. The typical use case of this feature is for large corporate use in which multiple projects require collaboration at the same time. Multiple employees can be granted access to the project to work on it, while others would have a different permission set, or no permissions at all. There are also potential uses in the educational context to manage classrooms.
Workspaces are a long time missing feature in tikiwiki. While it is almost possible to use tikiwiki for such a purpose at this time, doing it is complex and error prone. It requires understanding the category permissions or to deal with a large quantity of object permissions. Using multiple instances of tikiwiki is often an easier solution.
AulaWiki existed as a mod for a long time, but the lack of integration in the core prevented large adoption and dogfooding by the community. Over the years of changes in the core, the mod is no longer compatible. Also, with the new features introduced in tikiwiki since the original introduction of AulaWiki, the current implementation is unlikely to be the best design.
Use Case
ACME Company has 5 employees and 3 concurrent projects. The company uses a matrix organization to manage the projects.
- Bob is the accountant / finance person. He does not take active part in the project, but needs to keep track of the progress to handle the budgets.
- Alfred is a senior developer. He works on the complex projects and acts as a coach for other developers.
- Marc is the product manager. He handles the general direction of the platform.
- Sophie and Matt are developers.
Depending on the project, each of them is assigned a role which they have to accomplish. The roles are the following:
- F - Finance and budget, review and comment
- P - Programmer, active development
- A - Architect, review and comment
- D - Designer, active development, review, comment
| Project \ People | Bob | Alfred | Marc | Sophie | Matt
|
| Project 1 | F | A | D | P | P
|
| Project 2 | F | P | D | P |
|
| Project 3 | F | A | | | P
|
In Tikiwiki terms, this would be the mapping:
- Employee: user
- Project/Workspace: category
- Role: group (one set of groups must be created for each workspace)
The workspace acts a new root node for the category tree. When "switching perspective" to the workspace, position indicators in the category should be relative to the base project. Search should have defaults to that category and subcategories. Creating new items like wiki pages should also default to the category.
Users would also have more standard group structures to grant them general rights, but this is out of the "workspace" scope.
Note: Workspaces are not namespaces. Conflicts in page names will have to be resolved through conventions or creativity from the users.
To support workspaces correctly, Tikiwiki is missing the following features:
- Fine grained permission system on categories that works reliably
- Perspective change allowing the category-related view elements to have a different default
- Object creation with a default category
- Workspace creation/initialization (create a category, a set of groups, default objects, ...)
- Workspace-oriented permission/user management
Next step:
- Restructure the category permissions
- TikiFest in Spain, early 2009
