1. Management structure
Smallsite Design uses a very simple data model, and protecting that defines which users have access to which resources.
Data model△
Most data is stored in XML files, though some incidental information is stored in the names of file entries.
| # | File | Description |
|---|---|---|
| a | Master | Small file containing information about locales, users and some settings |
| b | Site | Above-the-line text and metadata for subsites, categories, articles and files |
| c | Article | Below-the-line content of an article for each work-in-progress, draft or release, and includes text for all locales. This enables life-cycle management of the article's content |
| d | User | Per-user file for spike content and other status information |
| e | Search | Contents of all articles broken down by locale and text blocks |
Only the files needed for a request from the internet are loaded. For files, only the master is required, as it contains information about whether the request is valid and if the file can be embedded. For other pages, site is required, and the latest release file for showing articles to the public. All the files required for a request are assembled into one XML structure which is transformed into the HTML of the page to display. Any extra information that may be required for particular pages is added to the XML structure prior to rendering.
Some data, such as which pages have been read for tabulating statistics, are stored as content-less file names, as that bypasses any need for access management. Such files are not stored in archives as they are not critical for site operation.
Access model△
The access model is very simple, with the master manager having almost universal access.
Only the master manager can perform any operations that can change the content of any of the XML files, except those for articles and users. This ensures only one person at a time can have write access to them. Even though a user can change their own details, they are not updated until the next master manager action.
Other managers can view almost anything, but cannot make changes. A guest user has similar access, but they are allowed on guest-mode sites only, which are meant for demonstration or learning purposes, and so should not have production site data.
A writer only has access to the pages they need to be able to edit the articles they are assigned to work on, or from which to source content. Managers assigned to do such work are treated as writers as to what they can do with information on those pages. Whomever is assigned to an article is the only one who can modify its content, though a master manager can take back control if required.
In normal operation, the master manager will maintain the site, assign tasks, and decide when to release articles. Other managers are only required for backup purposes or for maintaining the site in shifts. Everyone else should be a writer who is assigned tasks and is only given access to what they need for that task.
Managers have perpetual access, while writers are given finite access. Withing a month of that access expiring, the user file and details will be deleted, minimising the storage of personal information that is no longer required.