- "backwards compatible" with openacs 4.6.2 contacts-lite requires 4.7
- unlimited custom attributes/fields. Forms are generated using acs-templating and the standard subsite adp form template so it looks right entering and updating both work with the use of templates
- restricted access to certain fields based on permissions - e.g. somebody in the recruitment department can't see the social security number of a student (only the financial aid and immigration (i.e. student visas) offices can see this), but they are allowed to see things like home address, or work phone. half way there
- import/export from standard apps - I'm only going to make it work with Outlook CSV files, but it shouldn't be too hard to add other apps.
- archiving of all changes to this data - i.e. you can change the home address, but it will keep the old one in the database - and this old one will only be accessible to high level administrators. Hopefully this would allow people that "disappear" to be contacted regarding things like defaulting loan payments etc, since we could say "hey, they lived with their parents 4 years ago so lets check and see if their parents know how to get to them" done and working
- Extensive categorization. Again, since it needs to be compatible with the 4.6.x branch I won't be able to use the current categories package. Note that the categories "module" I am writing is hopefully being written in such a way that in the future people can drop contact-categories and go to a generic contacts package - though contact-categories is substantially different from the generic one so we might not want to do this.
- Conflict resolution - i.e. with a database of 1200+ users and many different staff using it people will inevitably enter the same person twice - this will provide a way for people to find these conflicts and merge the contact data, based on last modified - or one department is more important than the other so its info takes precedence. remember that even after a merge all data is backed up - so if we got something wrong accidentally we can still find that address that staff member "X" entered 4 months ago.
- Integration with users - i.e. if we say, Jane Doe (openacs user_id 9999) is the person we are referring to in regards to contact_id 10277, we can let Jane Doe enter as much of her private info as we want to via the pvt/home.
- Fully integrated with bulk-mail Features we don't need, but I would be happy to work on with some help - one of our goals is to have this app be useable and adapted by the community we are willing to do stuff the community asks for
A little back story. I wrote many additions to survey that allowed you to "export" surveys so people can collect custom data in other applications. Anyways, my additions never took hold, in part because of an understandable lack of time on the part of certain people. Well, I've learned a lot since then and I think that this application would be very useful to a number of people for managing custom fields in other applications. Since I already have the ability to integrate with forms created by acs-templating I have also made it possible to enter custom fields inline in other pages. All you need to do is put these three commands inline with your secondary form (in an application such as events):
Where form elements are defined by another app. contacts::forms::get_custom_fields -form "entry" -object_id "1234" in "is_valid" contacts::forms::save_custom_fields -form "entry" -object_id "1234" and if you want after is_valid to enter the default values (i.e. those values that already belong to the user submitting the info) contacts::forms::get_user_info -form "entry" -object_id "1234" -user_id [ad_conn user_id]This already works and assumes that object_id "1234" is the object that has a "service contract" with contacts - where the admin defined the fields e.g. "home_phone, home_address, work_phone" as those he/she wanted to collect. If no attributes have been defined for that object it simply doesn't give the form new fields. I think this could very easily become a service contract type thing - since the calling package doesn't need to know anything and its automatically saved for that app in my contacts app. So, here are my questions:
- if I am to implement this as a service contract how should I have the contracting application choose which custom fields to use. Possible solutions:
- the contracting app is given a link - and they need to have admin privileges on contacts to add these custom fields to their object this link then gives them a list of all available custom fields and checking the boxes next to those they want to include. They select it this way. I can do this myself and think I know how to set it up.
- the contracting app has some form of "select custom fields" inline in their application - and contacts the service provider has to provide that application with the 100 or so possibilities and they are selected from within the contracting app. If you think this is a better solution I will need some pointers on how to implement this.
- is it okay to "force" contracting applications to enter three lines of code on their pages? Most other service contracts can sum up the entire service contract in one small section. If it should be condensed in one section please give me some pointers on how to set it up so that it can only be referenced from one section.
Also, please let me know if there are any features missing that you think are important. I have been given the go-ahead to make this as generically-useful as possible in order to support the community at large.