Bitweaver - Protector

Main documentation on bitweaver.org   Bugs List

In the early days of the fork from TikiWiki there was a debate on managing content the basis of which goes back to early decisions companies such as Microsoft enforced on us. Wrapping content in a users identity in many cases is simply wrong, so that early websites such as TikiWiki stored all material based on just who posted it, while valid in one work case, was a problem for my own business activities. Staff come and go and material that one manager needs to survive those changes. Also new managers need to be able to edit old managers work? Hence protector replaces the storage of uploads by userId and restores a simpler flat storage model. Replacing userId with roleId was another possible path, but material being developed at the Manager level is likely to be moved down to the User level at some point, or even made available Publicly to Anonymous users, so simply storing material under the ContentId(MOD 1000)/ContentId is tidier. My original notes on this go back to 2006.

An additional level of role is Administrator which is the only level that can actually delete content. Data security was always a major part of my clients requirements and even the Administrator actions are logged on the core activity logs. These can only be deleted in the database directly.

That this system is somewhat at odds with the Groups approach to grouping material should be fairly obvious hence the two parallel user types in the users package!