History: TikiFestMontrealNov2008 Technical Group

• Short term
  • history on trackers

- 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

• Easy tracker

- 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

• tracker module: ?????

lph? Kerrnel?

• Long term

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

Seems that there is a rela need of tikisheet - and not an improvment of TRACKERSTAT. The excel approach is crucial.
lph? Kerrnel?

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:

• lphuberdeau
• sylvieg

User cases will be listed and will match the group space / role with categories andtw groups
-> on sylvieg todo list - other volunteer welcome
Some missing functions have already been identified
- browse from a category
- create in a category
- perpective change
Some note:
- Seems it is better for name conflict to choose the first is better served. If a group has already created a page with name Introduction - the second group will have to create a page 'Introduction / my group'
- Sefurl with automatic extension of group space attributes seems to be difficult