Contacts - Admin
The bitweaver framework provides a suite of generic tools to implement both the user and administrator interfaces to specialist extensions to a web based system. Functions like editing content use the same tool across all packages simplifying training, and a single set of user data controls access to all parts of a site.
Managing contact data as an address book style function is provided by many applications, but none of them are flexible enough to provide some of the extensions needed to mange cross linking of contacts records that a relational database can provide. The RDM contact system goes well beyond a simple address book and allows a complex range of data to be added to a contact record. Using the term 'contact' is perhaps the wrong since in many cases there may not actually be a contact name, but the starting point of any of the data is a persons contact information. The additional contact records can then provided information such as address and access information for a property, configuration information for a system, or data for a domain or service. An example is where we provide a management service for web hosting. A client may have more than one website, each with it's own domain record and containing links to other contact records such as hosting service, email service or e-commerce provider. Where kit is hosted on third party premises, information such as access codes, alarm passwords and equipment location within the site need to be maintained along with contact records for the site operator and perhaps the alarm monitoring service.
The framework provides a number of data tables from which a tree of data can be created. Each element of a contact record is stored as an 'XREF' element which stores four components. Each has a unique XREF_ID allowing it to be cross referenced from any other element, and the first element is set if it refers to another record. The rest of the data is free format text, with a 32 character text field, 250 character text field and an unlimited memo field. How these fields are displayed and managed can be controlled by the type of record with a generic set of profiles such as address, phone, email and location. These can be extended as required and a more complex profile has been created to handling the key seal actions required for key holding and similar actions are being developed for other processes.
The records are grouped into a series of TYPES, with three base groupings. The basic record type starts the tree, with 'client' records probably being the base for the Client Relations Management processes, but personal/business are another option for a personal address book. Domain or site is an alternate type of record where site could equally apply to website or client premises. Along with the basic list of types, the standard set of contact details to go with them form the second group. These obviously include address, phone number, email and other contact methods. For some elements it is quite probable that there will be more than item, such as telephone number. This is where the second text field comes in. Rather than the practice on many contact systems to provide a fixed number of fields such as Mobile Phone, Land Line and so on, in many cases one needs the flexibility to provide 'Business Mobile' and 'Personal Mobile' or the like, so providing the ability to manage a list of phone numbers is essential. email addresses need a similar flexibility.
A key element of the management of these records is to be able to record the changes to them. While not important in many situations, a number of areas where the system is designed to be used need to be able to record the history of changes of perhaps address or phone number. The key seal process is a good example where the history of access needs to be maintained. So the normal process of making changes to or deleting a record does not actually remove the data from the table, but simply tags an end date and switches it to the historic grouping. In fact records can be configured with both a start and end date, so information such as 'holiday address' can be managed with it's valid duration.
Additional groups of record types tend to be more application specific. On the enquirysolve council systems there will be a group of records containing the various account numbers on other council services, and links have been created to allow the system to access those systems where web based access is available. The NLPG property database is now an essential part of the council process and we have a comprehensive NLPG package which interfaces the councils LLPG data with the rest of the framework. For business users the NLPG is data is not as available as we would like, and so the simpler postcode data is used as an alternative. This is still used as part of the council system as most people can quote a postcode but not a property reference. It is worth adding that the post office only lists 'postal' addresses, so when dealing with locations that do not receive post the postcode is only a guestimate. The NLPG has property references for these locations which should include the actual GPS location. This is the distinction between address and location.
A fundamental element of the user access system is the user role, and in addition to grouping records by type, they are also grouped by role. The main use for this is to allow the hiding of material such as accounts details from other users, but other levels of control can be actioned. One of the target applications is to allow clients access to review their own subset of data such as domian information and traffic while hiding other clients materiel and the administration information. For council systems, the data protection act requires that some material is hidden depending on which department is viewing it, so each department becomes a role restricting access.
The key element of the xref process is the use of contact records in other records. An example of that is using entries from a list of domain records in a client record. So a group of domains may have the same contact details, not to be confused with the whois contact details which would be another element of the domain record. However in addition to the list of domains, there is also a list of 'servers', be that physical hardware or a hosting service, and each domain on a server would have a record for that cross link. Any element of the contact data that can be shared between other records should essentally have it's own contact entry.
Table-CONTACT (List of contact records)
Table-CONTACT_XREF_TYPE (List of xref type groups)
Table-CONTACT_XREF_SOURCE (List of xref record types)
Table-CONTACT_XREF (xref records)