The Alternative Bitweaver

Created by: Lester Caine, Last modification: 29 Sep 2012 (12:13 UTC)


Having started originally porting tikiwiki to support Firebird, my preferred database, it very quickly became obvious that the structure was not going to support the types of change I needed to be able to implement. tkipro had appeared with like minded developers, so I shuffled sideways and have been using this as the base for all my site developments since.
The problem I have is that all of the sites I am supporting are what I will call 'centralised content'. My users, rather than living in their own little pockets are providing and updating material that is 'the property' of the site, so filing things away based on 'user_id' is simply wrong. Many of the users have now moved on and others taken their place, but the information, still correctly tagged, lives on with new users maintaining it.


Initially the problem was that content needed to be bundled into different groups with users being limited to what they could see based on their role. Staff, Supervisors and Managers were the original base with 'Auditor' and 'Fraud' arriving later. While the base code allowed for 'groups' of users, there was also 'groups' package as an alternative grouping method, and at the time things were getting confusing. And will discussing implementation of a change on one of the larger customer sites, the comment was made, "my role is manager in benefits department", and it became obvious that this was indeed the distinction that was going to make things easier. While it would have been possible to simple rework all of the templates to use the correct words, then having 'user groups' under the hood in parallel with 'groups' was confusing, so a fork of the base code resulted in the 'role model' version, which is what I have been using on sites for some years.
Integrating the two models together should have been easy, except that the use of 'group' in the user functions was not as well isolated as many other features. Simply replacing one package with another - which would have been nice - was not going to work. However, starting with BW3, there is now an option that can be selected in config_defaults_inc.php to switch to the alternate model and built the alternate table set.
On top of that, protector provides a role based filter identifying who can access particular content. This service also filters lists to restrict visibility of content in addition to restricting access.


While managing 'department' could be handled by adding a block of roles for each department, this makes the role management page virtually unusable, and managing role independently of 'group' now makes even more sense. Currently multisites is used to provide a sub-domain for each department, but adding a 'department' version of protector is on the cards to keep things tidy as people can log onto the wrong domain.

Flat storage model

Dating back to 2008, StorageModels provided the base for an alternate storage model. Since user_id's come and go, using them in the storage tree always seemed wrong, and the modular nature of bitweaver already allowed for a alternatives, so rather than filing in user folders, a central 'attachments' folder is used. Although not essential for operation, the use of different id's for 'content', 'image' and 'file' is also flattened to use the content_id for all three. This just makes finding document easier as the reference number takes you straight to it.
Another problem that arises where there is a turnover of staff is the management of pictures and documents. Directly loading them to content pages may be convenient at the time, but later management is a lot more difficult, so the practice is to disable direct uploads, and require that attachments are uploaded to the correct gallery prior to their use. In this way one can easily find say '2009's council agendas' and also display them as a page independent of the entry in the event that they relate to.

Outstanding work

While the bulk of the parallel role facilities are working, there may still be a few edge cases we have missed, and there are still a few problem edge cases with the flat storage model where some core functionality was been moved from the relevant plugin. Our own port is using a slightly different version of the code here at present to maintain the correct operation of customer sites.