Forum OpenACS Development: Announcement - contacts-heavy application being developed - accepting feature requests

Features

• "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

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.

I took a look at telecom and decided we didn't need it, though it would be easy to add. ultimately i decided that a simple text box would be more user freidly for us instead of having multiple boxes just for a phone number.

i built the data model with specific to datatype based storage in mind. what i mean by this is that it is easy to add a new storage type for the storage on things like phone numbers, which can be done via the telecom package or whatever. i mean it trivially easy - so i guess i could say it makes use of both, but i'm currently only using those widgets built into ad_form, and we don't have a telecom widget in ad_form yet so i'm not using it - i though having a number of fields for area code, country code and the phone number would be too confusing for our users (who admittedly are primarily north americans - that is why i made it simple to add a new storage type).

If you are interested in helping to work on it let me know...

I was going to hook into the existing underlying stuff that Jon Griffin wrote for the reasons others have stated above.

Is there any possibility that you would accept some help in getting a generic version of your package ready to be put on CVS. I would be delighted to put time towards this objective - and to migrating the data model to Jon's underlying tables.

I have some time next week that I can devote to this.

Regards
Richard

Thanks for this bug-report. Could you actually post this in the bug-tracker?

I personally don't use the lors package, so I'm not very motiviated to fix this. But it should be on bug-tracker. I wonder if Ernie would be willing to fix it on his end?

It should be a fairly easy fix.

If nobody else fixes it, I'll probably get to it eventually. But let's first get it in bug-tracker.

https://openacs.org/forums/message-view?message_id=197490

PS Sorry for the profusion of postings on this. I just want to make sure that people who search for contacts find the right spot :)

Matthew: I failed to thank you for making this important code contribution.  Thank you!