Add field partyName on entity Party

[Malin Nicolas]

Hello,

Actually, I work on Party component to import Neogia functionality on
OFBiz trunk. I create  some addons use by the Neogia that apply on OFBiz
trunk with addon-manager and I submit to you the functionality.

My first addons add a partyName field to Party entity. Why ?
In Ofbiz, you have two partyType : Person and PartyGroup, when you want
have the  name, it's necessary to call Person or PartyGroup company, and
on many form we have (as lookupPartyName):
 < field  name="firstName">..</
 < field  name="lastName">..</
 < field  name="groupName">..</

With unique partyName field we have :
 
 < field  name="partyName">..</

This field is populate by secas when Person or PartyGroup is create/update

An other advantage, when we add a new PartyType, we just create populate
service for this new type and not operate modification on many form.
It's easier to manage customer specific.

Are you interested by this feature ? I can create a Jira and prepare a
patch to apply on OFBiz trunk.

Nicolas

[Jacques Le Roux]

Hi Nicolas,

From: "Nicolas" <[hidden email]>

> Hello,
>
> Actually, I work on Party component to import Neogia functionality on OFBiz trunk. I create  some addons use by the Neogia that
> apply on OFBiz trunk with addon-manager and I submit to you the functionality.
>
> My first addons add a partyName field to Party entity. Why ?
> In Ofbiz, you have two partyType : Person and PartyGroup, when you want have the  name, it's necessary to call Person or
> PartyGroup company, and on many form we have (as lookupPartyName):
> < field  name="firstName">..</
> < field  name="lastName">..</
> < field  name="groupName">..</
>
> With unique partyName field we have :
>
> < field  name="partyName">..</
>
> This field is populate by secas when Person or PartyGroup is create/update

Sounds like interesting, but I'm not sure to understand. How is actually partyName populated ? (beware actually is not actuellement
in French : faux ami ;o)

Thanks

Jacques

> An other advantage, when we add a new PartyType, we just create populate service for this new type and not operate modification on
> many form. It's easier to manage customer specific.
>
> Are you interested by this feature ? I can create a Jira and prepare a patch to apply on OFBiz trunk.
>
> Nicolas
>
>
>

[Malin Nicolas]

Jacques Le Roux wrote:

> Hi Nicolas,
>
> From: "Nicolas" <[hidden email]>
>> Hello,
>>
>> Actually, I work on Party component to import Neogia functionality on
>> OFBiz trunk. I create  some addons use by the Neogia that apply on
>> OFBiz trunk with addon-manager and I submit to you the functionality.
>>
>> My first addons add a partyName field to Party entity. Why ?
>> In Ofbiz, you have two partyType : Person and PartyGroup, when you
>> want have the  name, it's necessary to call Person or PartyGroup
>> company, and on many form we have (as lookupPartyName):
>> < field  name="firstName">..</
>> < field  name="lastName">..</
>> < field  name="groupName">..</
>>
>> With unique partyName field we have :
>>
>> < field  name="partyName">..</
>>
>> This field is populate by secas when Person or PartyGroup is
>> create/update
>
> Sounds like interesting, but I'm not sure to understand. How is
> actually partyName populated ? (beware actually is not actuellement in
> French : faux ami ;o)

Arg, exactly is not actualy but currently :) sorry. So currently I
create an seca on Person and PartyGroup created/updated that call
service to update partyName.

For a Person, service do partyName = lastName + firstName
For PartyGroup, service do partyName = partyGroup + [partyGroupLocal]

I hope it's more understandable :)

>
> Thanks
>
> Jacques
>
>> An other advantage, when we add a new PartyType, we just create
>> populate service for this new type and not operate modification on
>> many form. It's easier to manage customer specific.
>>
>> Are you interested by this feature ? I can create a Jira and prepare
>> a patch to apply on OFBiz trunk.
>>
>> Nicolas
>>
>>
>>
>
>
>

[hans_bakker]

Did you have a look at the PartyNameView entity? there you can list the
name and it does not matter if come from partyGroup or person:

${firstName} ${lastName} ${groupname}

Then the name will always show.....

so it is really required to add a field which duplicates information?

Regards,
Hans

On Fri, 2009-08-14 at 15:16 +0200, Nicolas wrote:
> Hello,
>
> Actually, I work on Party component to import Neogia functionality on
> OFBiz trunk. I create  some addons use by the Neogia that apply on OFBiz
> trunk with addon-manager and I submit to you the functionality.
>

--
Antwebsystems.com: Quality OFBiz services for competitive rates

[David E. Jones-2]

I agree with where you're going here Hans. The main reason for  
redundant/derived fields in the database is to make things perform  
adequately at run time. I'm not sure saving a little bit of code here  
and there is a good enough reason to have to deal with the inevitable  
inconsistency that comes from redundancy.

-David


On Aug 14, 2009, at 5:02 PM, Hans Bakker wrote:

> Did you have a look at the PartyNameView entity? there you can list  
> the
> name and it does not matter if come from partyGroup or person:
>
> ${firstName} ${lastName} ${groupname}
>
> Then the name will always show.....
>
> so it is really required to add a field which duplicates information?
>
> Regards,
> Hans
>
> On Fri, 2009-08-14 at 15:16 +0200, Nicolas wrote:
>> Hello,
>>
>> Actually, I work on Party component to import Neogia functionality on
>> OFBiz trunk. I create  some addons use by the Neogia that apply on  
>> OFBiz
>> trunk with addon-manager and I submit to you the functionality.
>>
>
> --
> Antwebsystems.com: Quality OFBiz services for competitive rates
>

[Malin Nicolas]

Hi Hans, Hi David,

I understand that there is a potential redundant problem that this
solution generate. In Neogia project, we have created a new field called
partyType when we have a new party with functional particularity (as a
Company). In OFBiz I looked that you added PartyType with the parentType
INFORMAL_TYPE but I don't understand how you manage specific fields. The
point is that when you are using a partyType, the specific fields to
this type are not managed. For example, if I am adding a party, with its
partyType to FARMER, how will I put the specific fields related to it
(tractor number, sheep type, ..., it's an example ;) ) ?
 The partyName field is created to make easier the screen creation
otherwise for all forms if we used PartyNameView, all forms that use
this must be changed and the field is too long : ${firstName}
${lastName} ${groupName} ${corporateName} ${farmerGreateName}
${anOtherPartyTypeName} ...

If we have a different PartyType managment, the partyName field have not
consistence on OFBiz project. I have create the addons for interested
person, it's available on http://addons.neogia.org/addons/party-name/.
If you need more explanations on how using it, don't hesitate to ask on
the mailing list.

Thx

Nicolas

David E Jones wrote:

>
> I agree with where you're going here Hans. The main reason for
> redundant/derived fields in the database is to make things perform
> adequately at run time. I'm not sure saving a little bit of code here
> and there is a good enough reason to have to deal with the inevitable
> inconsistency that comes from redundancy.
>
> -David
>
>
> On Aug 14, 2009, at 5:02 PM, Hans Bakker wrote:
>
>> Did you have a look at the PartyNameView entity? there you can list the
>> name and it does not matter if come from partyGroup or person:
>>
>> ${firstName} ${lastName} ${groupname}
>>
>> Then the name will always show.....
>>
>> so it is really required to add a field which duplicates information?
>>
>> Regards,
>> Hans
>>
>> On Fri, 2009-08-14 at 15:16 +0200, Nicolas wrote:
>>> Hello,
>>>
>>> Actually, I work on Party component to import Neogia functionality on
>>> OFBiz trunk. I create  some addons use by the Neogia that apply on
>>> OFBiz
>>> trunk with addon-manager and I submit to you the functionality.
>>>
>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>
>

[Bob Morley]

We had a similar problem with getting a consistent name across the party inheritence model.  The approach we are in the process of taking is to enhance the PartyNameView (or provide a new one) to support a complex-alias that can be a coalesce of the various components in combination with using a static method to consistently format the name.

The first part is important because (at least in our appliation) it is a requirement to sort parties in a list properly by name (as well as filtering on those values).  As a result, it is nearly manditory to produce a field for these operations at the database level.  Typically you do not want to have your database dictate formatting, so we leave that for the method that can be configured.

The rub here is that for sorting / filtering we have to be fairly close to the resulting format.  If you format "Last, First" (for a person) then the database field needs to combine in that order but not necessarily with equivalent seperators.

.B

Malin Nicolas wrote

Hi Hans, Hi David,

I understand that there is a potential redundant problem that this
solution generate. In Neogia project, we have created a new field called
partyType when we have a new party with functional particularity (as a
Company). In OFBiz I looked that you added PartyType with the parentType
INFORMAL_TYPE but I don't understand how you manage specific fields. The
point is that when you are using a partyType, the specific fields to
this type are not managed. For example, if I am adding a party, with its
partyType to FARMER, how will I put the specific fields related to it
(tractor number, sheep type, ..., it's an example ;) ) ?
 The partyName field is created to make easier the screen creation
otherwise for all forms if we used PartyNameView, all forms that use
this must be changed and the field is too long : ${firstName}
${lastName} ${groupName} ${corporateName} ${farmerGreateName}
${anOtherPartyTypeName} ...

If we have a different PartyType managment, the partyName field have not
consistence on OFBiz project. I have create the addons for interested
person, it's available on http://addons.neogia.org/addons/party-name/.
If you need more explanations on how using it, don't hesitate to ask on
the mailing list.

Thx

Nicolas

David E Jones wrote:
>
> I agree with where you're going here Hans. The main reason for
> redundant/derived fields in the database is to make things perform
> adequately at run time. I'm not sure saving a little bit of code here
> and there is a good enough reason to have to deal with the inevitable
> inconsistency that comes from redundancy.
>
> -David
>
>
> On Aug 14, 2009, at 5:02 PM, Hans Bakker wrote:
>
>> Did you have a look at the PartyNameView entity? there you can list the
>> name and it does not matter if come from partyGroup or person:
>>
>> ${firstName} ${lastName} ${groupname}
>>
>> Then the name will always show.....
>>
>> so it is really required to add a field which duplicates information?
>>
>> Regards,
>> Hans
>>
>> On Fri, 2009-08-14 at 15:16 +0200, Nicolas wrote:
>>> Hello,
>>>
>>> Actually, I work on Party component to import Neogia functionality on
>>> OFBiz trunk. I create  some addons use by the Neogia that apply on
>>> OFBiz
>>> trunk with addon-manager and I submit to you the functionality.
>>>
>>
>> --
>> Antwebsystems.com: Quality OFBiz services for competitive rates
>>
>
>