Subversion Repositories computer_asset_manager_v2

Rev

Go to most recent revision | Details | Last modification | View Log | RSS feed

Rev Author Line No. Line
1 rodolico 1
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
2
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.
3
 
4
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
5
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.
6
 
7
Upon startup, application will scan modules directory for list of modules currently installed.
8
 
9
The root directory will contain the following:
10
   includes/   -- common library code
11
   modules/    -- modules installed in the application
12
   header.php  -- common file placed at the beginning of all generated web content
13
   footer.php  -- common file placed at the end of all generated web content
14
   content.css -- CSS definition for all generated web content
15
   print.css   -- CSS definition for all generated content targeting a physical printer
16
 
17
Each module must contain the following (possibly empty) files:
18
   library.php  -- module specific library
19
   database.php -- module specific database definition load
20
 
21
 
22
Modules
23
 
24
The modules currently defined in CAMP are as follows:
25
 
26
Base
27
Sysinfo
28
Backups
29
Maintenance
30
 
31
Base Module
32
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)
33
 
34
Sysinf Modules
35
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
36
 
37
Backups
38
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.
39
 
40
Maintenance
41
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.
42
 
43
 
44
 
45
Details
46
 
47
Base Module
48
 
49
Data Storage
50
   Client
51
   Location
52
   Component (note, this can be a machine, or something that makes up a machine)
53
   Component Type
54
   Attribute Values
55
   Attributes
56
   Aliases (alternate names for Components, Locations and Clients)
57
 
58
There should be a one to one relationship between these structures and a class associated with them.
59
Relationships between the tables are as follows:
60
   A Client must have one or more Locations.
61
   A Location may have one or more Components
62
   A Component may contain other components (thing a computer may have a NIC)
63
   A Component must have one Component Type (think printer, server, Interface Card)
64
   A compoment may have one or more attribute values
65
   An attribute value will have one attribute
66
 
67
All tables will have the following columns:
68
   Notes
69
   Added Date (the date the row was added)
70
   Removed Date (the date the row was removed, defaults to null)
71
   Last Edit (the last time the row was edited, defaults to Added Date)
72
   Last Edit by (the login ID that edited the row last)
73
 
74
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.
75
 
76
Not sure how to handle moving a component from one component to another.
77
 
78
Notes will be editable, relying on the user to not delete important information.
79
 
80
Client
81
   client_id
82
   name
83
   contact
84
   email
85
   notes
86
   added
87
   removed
88
   lastedit
89
   editby
90
 
91
Location
92
   id
93
   name
94
   notes
95
   added
96
   removed
97
   lastedit
98
   editby
99
 
100
Component
101
   id
102
   name
103
   component_type
104
   part_of
105
   notes
106
   added
107
   removed
108
   lastedit
109
   editby
110
 
111
Component_Type
112
   id
113
   name
114
   system
115
   notes
116
   added
117
   removed
118
   lastedit
119
   editby
120
 
121
Attributes
122
   id
123
   name
124
   data_type
125
   notes
126
   added
127
   removed
128
   lastedit
129
   editby
130
 
131
component_attribute
132
   component
133
   attribute
134
   value
135
   notes
136
   added
137
   removed
138
   lastedit
139
   editby
140
 
141
Alias
142
   component
143
   alias
144
   notes
145
   added
146
   removed
147
   lastedit
148
   editby
149
 
150
 
151
 
152
 
153
 
154
*In work ticket/tracking form, add field for computer name, user names, workgroup.
155
 
156
*Add CSS tag to each item so it can be visually distingushed later in CSS in some way.