Forum OpenACS Improvement Proposals (TIPs): TIP #92 (Rejected: Change locale dependency from users to persons

Currently the locale of a person has a foreign key constraint to the users table. Sadly this does not make much sense, as you could create persons who are not users of the system (e.g. with the contacts system), but who should have a locale variable stored, so you know which language to use when communicating with them (especially when you are using I18N for this).

What is being proposed ?

Change the foreign key constraint from users to persons for the users_preferences table

Why is it good?

It will allow other applications to store the person preferences in one central location and if the person becomes a user afterwards, the upgrade is easy.

Why is it bad?

user_preferences table would reference persons, not users, therefore the name could be misleading. Changing all calls in the toolkit from user_preferences to person_preferences might be a hell of an upgrade script (especially if you have foreign key constraints).

Alternative:

Change acs-lang to not use user_preferences for storing the locale of the user but create a new table too hold the locale and the party_id. This would allow us to assign a locale to a group, e.g. in .LRN where the group locale for the community could override the user locale to have a french class' interface appear in French. It is just considerably more work which might not be necessary.

Would using parties_preferences cover everything (and integrate well with contacts AMS)?
Can you clarify what the users_preferences table is for? Is it used for anything other than this purpose? (Sorry, I'm not able to dig into it right now)
The user preferences table contains information which at least should be stored for an person, if not any party.

It stores prefer_text_only_p which is useful if you send a mail to a party, language_preference and locale (reason given above), dont_spam_me_p (also useful for anyone with an email, read: parties), email_type (well, it says email), timezone (usually somthing you want for parties as well).

Therefore I ammend my TIP and ask for a change where "user_id" references "parties" and I write a big warning in the SQL file that this it is called user_id and not party_id as we are too lazy to fix it everywhere :).

This TIP didn't get seconded either, so apparently it is rejected as well. Will put this into our growing repository of patches.
Well, I'd probably be fairly easy to convince if it weren't for this:

'Therefore I ammend my TIP and ask for a change where "user_id" references "parties" and I write a big warning in the SQL file that this it is called user_id and not party_id as we are too lazy to fix it everywhere :).'

This would represent a degredation in the quality of the code base. While we already have far too much code that's of low quality in our code base, it seems wrong to decide to be lazy to this extent.

Once "user_id" is known to not necessarily mean a reference to a user in one context, how is one to know that it's really a reference to a user in ANY context?