Forum OpenACS Development: OpenACS communicating with parties instead of users

This discussion is triggered by the fact that contacts drops the foreign key constraint for the user_preferences table and changes it from "users" to "parties". The rationale behind it is that the user_preferences table contains parameter values for communication with users which should be made available to parties with applications beginning to use the fact that the e-mail is stored with the party and not the user and therefore communication can happen with any party, not only users. This raises a fundamental question:

Shall we change the toolkit to accommodate the fact that we are communicating with parties and users instead of only users? Or should we try to double existing functionality to make sure we are not breaking the core assumption that communication happens only with users.

Depending on the outcome of above question a couple of others arise:

If I understand correctly then the change will not be able to be made due to the fact that packages might require user_preferences to reference the user_id. Before I made the change in contacts I made sure that no other package in HEAD relies on this constraint, otherwise I would not have done it. I'm not suicidal. But what about others I don't know about?

I asked the OCT what should be done about it and got the usual answer of "The datamodel should be changed in oracle and PG and upgrade scripts written, and existing packages should be examined to see if they depend on this column referencing users.".

As this is nothing new I realized I should have specified my question a little bit.

- Shall we drop the constraint ?
- Shall we create a new table "party_preferences" ?
- Shall we rename the table and columns ?

I am strongly against renaming as this will most likely break custom applications who e.g. are using dont_spam_me_p parameter. If they can't reference user_preferences anymore they have to rewrite to party_preferences.

Creating a new table party_preferences and storing the locale and the dont_spam_me parameter there would work, but again the problem with the custom applications. It would leave them the original table, but at least two columns will not be there anymore. But at least their custom changes to user_preferences are not gone.

Therefore for me exchanging the constraint seems the simplest solution (without too much harm done), albeit it might confuse developers (why is it called user_preferences and user_id when it should be called party_preferences and party_id).

Once a general consensus has been reached on what actually to do for 5.4 I will write a TIP or, if the consensus is, keep it the way it is, write a page in the admin section of contacts allowing an administrator to run the change of the foreign key constraint manually on his/her own risk.