Subversion Repositories computer_asset_manager_v2

Rev

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.