Alexey Parshin wrote:
> IMO, any preferences that are not one-to-many (ie not a list), like
> preferred_language, may go into person_list.
I tend to agree with that.
> As for the others - we would need to discuss it separately, since it
> probably requires support on the database level.
> The notifications, for instance, belong to an object.
Hmm... At first I wanted to say "to object relationship", but then
realized that relationships themselves
are versioned. At the same time each object-object relationship may have
its own notification preference.
I guess this either means separate object<->object table for
notification statuses, or copying that
preference when creating new object version, and using last version when
sending out actual
> 2006/10/31, email@example.com
> <mailto:firstname.lastname@example.org> < email@example.com
> <mailto: firstname.lastname@example.org>>:
> > email@example.com <mailto:firstname.lastname@example.org >
> >> I think we may need something like person_preferences table to
> >> user
> >> preferences for
> >> 1. Prefered UI language.
> > Good point. Although this might be just a field in person_list
> IMO a new table may be better, since user may have many additional
> preferncies(email notifications for ordering, currency, the way UI
> displays certain UMOs/features, any kind of
> restrictions/limitations/preferencies for UMO he is an author of,
> >> 2. Object change notifications/preferencies.
> > No, these are per-object-relation. Although you are right in that
> > the info is missing.
> >> Also we need to handle user types somehow, probably using
> >> table.
> > There are no user-types as such. There are access kinds users
> > have to different objects. ACL tables handle that.
> > --
> > Ilya A. Volynets-Evenbakh
> > Total Knowledge. CTO
> > http://www.total-knowledge.com
> Alexey Parshin,
> http://www.sptk.net <http://www.sptk.net>
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
Authoright © Total Knowledge: 2001-2008