Contact Management

Created by: Lester Caine, Last modification: 29 Sep 2012 (13:11 UTC)
There have been several attempts at adding a contact management package to bitwaever and a fe still exist in in the code archive. LDAPContactsPackage dates back to 2005, and is the only one with any documentation in the wiki, but we have been working with a few variations on something with started as the import of a 'citizen' database from one of our local council customers.
For council customers it integrates into a package for managing NLPG data (National Land and Property Gazetteer), Since it is the local authorities who generate their local data it is freely available to them and provides a complete record of all the properties in their area. Even more accurate than the postal database since it covers locations that the post office do not deliver to.
For sites where NLPG data is not available, then we just drop back to postcodes, and an address package allows even manually building that data as clients are added.
One of the limitations of the many contact packages is working with fixed fields, so the base for this package is a table of cross-references, with a list of types and sources. Displaying the information is done on a series of tabs, the xref types, and user role determines which ones they have access to. The range of types relates to the particular application, so there may be a 'contact', 'accounts', 'kit on site', 'alarm codes'. Obviously only the accounts department might have access to the accounts records, but finer control would allow say the receptionist to see an account number on that tab but nothing else. Similarly the access alarm codes can be tightly managed. The list is unlimited, although keeping down to a manageable number of basic tabs helps usage.
There may be more than one entry of a particular type, so multiple entries can be allowed, or blocked. But even in the case of a 'one only' entry, all the history is maintained, as they are not deleted, simply archived to the 'history' tab. This is particularly useful in the like of council offices where one needs to be able to follow the changes of address of a client, or a sequence of claim numbers for benefits. The reason that the cross-reference objects have a 'source' is that they can then be linked to other systems automatically. Planning applications can be logged and cross-reference the plans register for instance. In the case of key handling, numbered anti-tamper seals are used to restrict access, and these numbers can be logged as keys are accessed and returned.

Related Items

Features

  •    •    •    •    •    •    •    •    •    •    •    •  Anonymous  •  Anonymous