Rev 26 | Blame | Compare with Previous | Last modification | View Log | Download | RSS feed
Application will be module based, with only limited functionality in its base system. For the purpose of this document, a "module" will refer to this base module and/or all other modules. The term "Base Module" will refer to the base application
All modules will have an installation script. This script may modify the database structure by adding fields, tables or views. It will not modify any existing fields, tables or views.
A table set by the Base Module will list all modules. When the Base Module is invoked, access to all other modules will be via this list
Each module will be in its own directory, under the directory /modules.. The directory name will be the same as the module name. Only limited glue files will be placed in the root directory of the application.
Upon startup, application will scan modules directory for list of modules currently installed.
The root directory will contain the following:
includes/ -- common library code
modules/ -- modules installed in the application
header.php -- common file placed at the beginning of all generated web content
footer.php -- common file placed at the end of all generated web content
content.css -- CSS definition for all generated web content
print.css -- CSS definition for all generated content targeting a physical printer
Each module must contain the following (possibly empty) files:
library.php -- module specific library
database.php -- module specific database definition load
Modules
The modules currently defined in CAMP are as follows:
Base
Sysinfo
Backups
Maintenance
Base Module
The base module allows users to add/edit/report on machines in the system. Information on ownership, location, operating system(s), installed applications, IP addresses, components are all stored in the Base module. It also understands that a device may be known by different names (aliases)
Sysinf Modules
The Sysinfo module allows automated updates of the information stored in the Base Module about a given piece of software. Sysinfo module will also temporarily store unknown reports in a temporary table, allowing a user to simply "import" the machine
Backups
The Backups module reports backup statistics on devices which use our backup service. As with the Sysinfo module, upon receiving a report for an unknown system, will create a temporary entry. Information stored will be size paid for, start time. Dynamic information stored will be transfer size, size on disk.
Maintenance
The maintenance module allows machines to be added/removed from maintenance tasks. Additionally, maintenance will allow the technician to track maintenance performed, both scheduled and unscheduled.
Details
Base Module
Data Storage
Client
Location
Component (note, this can be a machine, or something that makes up a machine)
Component Type
Attribute Values
Attributes
Aliases (alternate names for Components, Locations and Clients)
There should be a one to one relationship between these structures and a class associated with them.
Relationships between the tables are as follows:
A Client must have one or more Locations.
A Location may have one or more Components
A Component may contain other components (thing a computer may have a NIC)
A Component must have one Component Type (think printer, server, Interface Card)
A compoment may have one or more attribute values
An attribute value will have one attribute
All tables will have the following columns:
Notes
Added Date (the date the row was added)
Removed Date (the date the row was removed, defaults to null)
Last Edit (the last time the row was edited, defaults to Added Date)
Last Edit by (the login ID that edited the row last)
Instead of deleting/editing a row, most edits will actually be an insert of a new row, and the Removed Date set to a non-null value meaning the row is no longer valid. For Clients and Locations, it is no problem to edit a users name. However, for components, we will need the name to match up with older reports so the Alias table will be used to change names.
Not sure how to handle moving a component from one component to another.
Notes will be editable, relying on the user to not delete important information.
Client
client_id
name
contact
email
notes
added
removed
lastedit
editby
Location
id
name
notes
added
removed
lastedit
editby
Component
id
name
component_type
part_of
notes
added
removed
lastedit
editby
Component_Type
id
name
system
notes
added
removed
lastedit
editby
Attributes
id
name
data_type
notes
added
removed
lastedit
editby
component_attribute
component
attribute
value
notes
added
removed
lastedit
editby
Alias
component
alias
notes
added
removed
lastedit
editby
*In work ticket/tracking form, add field for computer name, user names, workgroup.
*Add CSS tag to each item so it can be visually distingushed later in CSS in some way.