Hi David,
Oh, yes! The PartyClassification is the best place for it.
PartyClassification already has comprehensive suite of CRUD services/functions
done. In PartyMgr.
There are even some examples of its use. Like in Promos -> Rules. Also in the
Marketing module.
Thanks!
> If they aren't an OFBiz user then the language preference for application
> interaction wouldn't matter
Still, it'll be useful and "standard practice" (in conformance with OFBiz data structures) to use
PartyClassification.
For the "language preference for user interaction with OFBiz app", I think that can still use
PartyClassification, unless a single Party uses multiple languages based on which UserLogin is
used for "interaction with OFBiz application".
PartyClassication will also allow us to attach multiple citizenships to a single Party. Also
possible are multiple language preferences, language abilities, and such, for a variety of
functions (eg marketing).
Jonathon
David E Jones wrote:
Adrian Crum wrote:
David E Jones wrote:
Nationality/race/minority/whatever would be in the
PartyClassification and related entities.
Language we'd need more info about to model. If you want to model all
languages spoken I think we would need a new entity def, though
actually PartyClassification could be used for that too. If you are
looking for a language preference for application interaction, the
UserLogin entity is the way to go.
Except when the party is not an OFBiz user.
Hence the question about intended use. If they aren't an OFBiz user then
the language preference for application interaction wouldn't matter, so
the other or something like it would be what they want.
Either way, until the original person specifies more of what they're
looking for... who knows!
-David
