Forum OpenACS Development: Contacts 1.0d and AMS 1.0d Todo List

I will also work on

• Enabled functionality in Mail Merge that is demoed already in code - including saving canned letters and signatures
• Enable bulk updating of attributes by admins as a bulk action on the index page - i.e. select all people in a query ( people in the states CA, OR, NV and WA) and map a relationship with a certain sales person, etc.)

• Add a relationship Employee / Employer with additional attributes like
  • Work Phone
  • Work Fax
  • Work E-Mail
  • Position
• Finish I18N of contacts (it is flaky at best)

If the purpose of creating a CRM package is better marketing I'm all for changing the name of contacts to CRM.

What you can do though is create a dummy procedure "callback" that takes arguments as callback does, but has not code. This could be stored in contacts-init.tcl and wrapped around an if statement that checks if there is already a callback function and only initialize this particular callback function if there is none installed.

Regarding the setups, I will add seperate procedures to contacts in contacts-populate (?) like contact::populate::customers that will create prepopulated lists. We could then write a page in the admin interface that checks all procedures in the contact::populate namespace and have them available as an option to execute.

Furthermore tighter integration with existing packages is under way (e.g. the files section will show the FS Folder Portlet instead of the existing (nice working) file code if a content_folder is linked to the contact).

Furthermore the mail capabilities are on my todo list for today/tomorrow, which should enable you to send the mails along with attachements or a whole folder zipped into one file.

Last but not least I hope to get incoming email working.

I have uploaded the new search api. This will allow people to create contact::search::condition_type::${type} procs that can be used via contacts advanced search functions. Potentially any package could create procs that interface with contacts. If a better way to do this is vai service contracts or callbacks we can - please take a look and see what i've done.

Some of the changes I have made to contacts lately require AMS updates, so please make sure you get that when updating.

Lastly, I am noticing that our site needs a number of customizations to the contacts-ui that would not be necessary for a generic install. Until now I have been checking if the package "tasks" is enabled, which is a site specific package. I think it might be time for us to create a "ContactsMasterTemplate" (not the "S") and "ContactMasterTemplate" parameters so that they can be rest on a site basis. Does this sound like the correct solution to this problem?

I have also added parameters for setting the template for a contacts instance. Callbacks might be better, but it doesn't work with openacs 5.1.5 (which I need it to do) so for now the parameters will have to do. Once I don't need to use 5.1.5 and I have the time I can possibly convert it to callbacks.

CSS formatted letter templates and saved form letters are coming in the next day or so... Once I add form letters cr_items I will add sql code, create an uppgrade script and bump up the version numbers a step (which will auto load the new parameters - which have placeholder defaults so they aren't needed right now)

I have grave reservations about this assumption that all contacts are registered users. In fact I would go as far as to say that if we continue to develop down the road of ERP this will block progress.

Also, Claudio's existing work on ERP may prove to be incompatible with this assumption.

Can I please pursuade you to look for another convenient means of handling 'delete'.

If I can't pursuade you, and we use the 'groups' functionality for this, instead of using the existing registered users group would it not make sense to do one of the following instead:

Option1)
Have a group called 'deleted' and assign contacts to these. (Seems like a bit of a cludge though since the contact's state is an attribute of the contact).

Option2)
Set up a group per contacts instance and assign contacts to the group associated with the package_id.

Or why not go a different route and simply always add by default a deleted_p attribute to every contact. I don't know whether you can conveniently do this using any 'typed' attributes or whether it is easier to auto-adding deleted_p in the user defined ams 'record' definition for contacts.

It seems to me that the debate really needs to be expanded to cover how we should store object metadata in applications that use ams.

Regards
Richard

Thanks for the explanation. I can see why this is not a trivial decision. I think my discomfort stems from something that is neatly summed up by a statement from the previous posting:

"all parties are part of the group registered users (-2), this can be a person who is not a user"

The idea that a party that is not a registered user can be part of the group 'registered users' seems undesirable to me.

In fact if you consider the case where a party is a group of groups, there may not be any registered users amongst them. I think that if contacts treats the party objects in this way then there is a real chance that in the future a single set of relationships may produce different behaviour in different packages.

Regards
Richard

I have updated contacts to version 1.0d3 please upgrade via apm (I have included the sql upgrade scripts). You can now save messages (letters and emails) and view/use other users saved messages and perform printed letter mail merges. Printed letter mail merging is done with CSS and only tested on Firefox on Windows. If you select letterhead it will indent the left side (since our schools letterhead has information on the left margin - if you need to change this you can edit www/resources/contacts-print.css). In the long run to print consistently no matter what browser is used we will likely need to convert html/xml/xhtml or whatever to pdf... any volunteers? 😊

What I'll be working on now:

• General usability bug fixes, page flow, etc.
• Allowing any attribute to be used in a mail merge (right now only first_names, last_name, and name work right).
• Allowing person objects to be "upgraded" to user objects
• Figuring out how to not make sure every contacts needs to be in the group -2 (registered users) and implementing that solution

Our users wanted and I have a created a custom history tab for a contact. This page has all the comments, attribute changes, messages sent, tasks completed, etc in chronological order with a consistent time and users stamp. It looks much like the comments page but includes much more info and intersperses comments with other information - its one place to look to see how a contact has related to our organization. I will attempt to generalize this page and include it with the cvs.openacs.org install of contacts in the next few days. this page has the view of contact message log info.

I don't mind mail-tracking being called mail-tracking. The reason I added the table seperately is threefold:

1. That table mimics the saved contact messages in cr_items which allows me to save the title, description (i.e. subject in an email) and content (i.e. body in the email). This lets me use a institutional name such as "Admissions: introductory letter for international students" that our staff uses in the history page and have a link to the actual message sent. A staff member knows that the contents of that form letter is and doesn't have to read the specfics unless they want to. So, if we were to use mail-tracking only I would want a title attribute that can be used for this purpose
2. Mail-tracking logs all login messages for users, forum notifications, etc. i.e. way too much info for us where many of our contacts will also be users (and dotLRN users at that) all those messages being logged will significantly decrease the usefulness of mail tracking for us since there will be a lot of noise. All our staff cares about is the official notices sent to contacts and those will all be sent via the messages interface in contacts. I can see why some people would want everything logged, we just don't
3. I was in a big hurry and didn't look into customizing mail-tracking to fit our needs since creating one table and one proc to add info to that table was much faster than negotiating how to make mail-tracking fit our needs when i was preparing to show my progress to some other collegues

I think there is a place for mail-tracking and a place for the contacts mail log, but not both simultaniously. So maybe we should have a parameter that sets how much logging of messages should be done and selecting the appropriate place? Or is there a way in which mail tracking could be used for our needs?

As far as default groups go... I agree that an application group for the contacts instance is the way to go for now. In the long run we will want to be able to allow users or groups to have their own contact lists that aren't shared part of an instances default list. But having an application group for now should do it. I guess well just need a sweeper proc that runs every 60 seconds or so and finds any new users/organizations and adds them to the ocntacts instance.

Lastly, the "any attribute mail merge" would work easily the way you suggest but not quickly when doing a 500 letter mailing (which our school needs to be able to do). My issue is in figuring out a way to do it quickly with large mailings... without requiring a trip to the database per attribute per party_id. Although I agree that it shouldn't be too hard... i should have that working within the next day or so.

I also:

- modified lib/history to make use of callbacks so other packages can provide history information
- modified lib/contacts.tcl bulk actions to make use of callbacks (I for example use a callback to allow users to bulk add tasks to contacts, etc.)
- did some bug fixes