Users - Roles and Groups and Products Bought

[Nguyen Minh Triet]

Hi,

I am looking closer at Parties. I am trying to see if a Parent-Child
party logic can be implemented with what is currently present. For
example, Party A buys a subscription to product X. Party B and Party C
are said to both be 'children' of Party A. Party B and C both have
access to what Party has bought but what child has bought is only
available to itself.

>From the Wiki, I see there are different notions applied to parties such
as Roles and Groups.
http://ofbizwiki.go-integral.com/Wiki.jsp?page=GroupsVsRoles

Questions:

1. Is it possible to create a Parent-Child structure for Parties or we
will have to fiddle with groups and parties code to achieve this?
2. If such a structure can be laid out, can the products bought be
propagated?

I think the essential of this requirement of ours is that point 1 be
present or implementable. Point 2 we can implement, I think, with some
purchase history checks using the Parent-Child tree.

Any suggestions or comments appreciated,

Thanks,
Minh
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Adrian Crum]

Use PartyRelationship to tie the children to their parents. Your program logic
can check for the existance of the relationship.

Nguyen Minh Triet wrote:

> Hi,
>
> I am looking closer at Parties. I am trying to see if a Parent-Child
> party logic can be implemented with what is currently present. For
> example, Party A buys a subscription to product X. Party B and Party C
> are said to both be 'children' of Party A. Party B and C both have
> access to what Party has bought but what child has bought is only
> available to itself.
>
>>From the Wiki, I see there are different notions applied to parties such
> as Roles and Groups.
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=GroupsVsRoles
>
> Questions:
>
> 1. Is it possible to create a Parent-Child structure for Parties or we
> will have to fiddle with groups and parties code to achieve this?
> 2. If such a structure can be laid out, can the products bought be
> propagated?
>
> I think the essential of this requirement of ours is that point 1 be
> present or implementable. Point 2 we can implement, I think, with some
> purchase history checks using the Parent-Child tree.
>
> Any suggestions or comments appreciated,
>
> Thanks,
> Minh
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Nguyen Minh Triet]

Hi,

Thanks Adrian for the info. From the looks of things, the solution you
proposed should allow us to meet our requirements.

Can you suggest any link, example or literature that would allow me to
fully understand each parameter involved and there interactions in the
creation of a 'Relationship'.

For example:

1. 'Parent Type' (of a relationship)
2. 'Valid From RoleType' and 'Valid to RoleType'
3. How does the RELATIONSHIP apply to the ROLES of parties for example,
as seen in the RELATIONSHIPS view of the PARTY tab:
'The party with ID... in the role of ... is a ... of the current party
in the role of ...'

Thanks,
Minh

Minh
---------------

Message: 4
Date: Wed, 01 Feb 2006 11:28:04 -0800
From: Adrian Crum <[hidden email]>
Subject: Re: [OFBiz] Users - Roles and Groups and Products Bought
To: OFBiz Users / Usage Discussion <[hidden email]>
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=us-ascii; format=flowed

Use PartyRelationship to tie the children to their parents. Your program
logic
can check for the existance of the relationship.

Nguyen Minh Triet wrote:

> Hi,
>
> I am looking closer at Parties. I am trying to see if a Parent-Child
> party logic can be implemented with what is currently present. For
> example, Party A buys a subscription to product X. Party B and Party C
> are said to both be 'children' of Party A. Party B and C both have
> access to what Party has bought but what child has bought is only
> available to itself.
>
>>From the Wiki, I see there are different notions applied to parties

such

> as Roles and Groups.
> http://ofbizwiki.go-integral.com/Wiki.jsp?page=GroupsVsRoles
>
> Questions:
>
> 1. Is it possible to create a Parent-Child structure for Parties or we
> will have to fiddle with groups and parties code to achieve this?
> 2. If such a structure can be laid out, can the products bought be
> propagated?
>
> I think the essential of this requirement of ours is that point 1 be
> present or implementable. Point 2 we can implement, I think, with some
> purchase history checks using the Parent-Child tree.
>
> Any suggestions or comments appreciated,
>
> Thanks,
> Minh
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Adrian Crum]

I don't have enough information to be very specific, but I will try to suggest a
general strategy that you can 'flesh-out' yourself. If anyone else has a better
idea, then please comment.

1. Create a role for the parent subscriber, like PARENT_SUBSCRIBER.
2. Create a role for the child subscriber, like CHILD_SUBSCRIBER.
3. Modify the program logic so that the PARENT_SUBSCRIBER role is assigned to
the person purchasing the subscription.
4. Give the parent subscriber a way to share the subscription with others. Write
program logic to assign the CHILD_SUBSCRIBER role to those other users. Also...
4b. Create a PartyRelationship connecting the two parties.
5. When it comes time for someone to use the subscription, first check to see if
they purchased the subscription. If not, then check to see if they have a
CHILD_SUBSCRIBER relationship to someone who purchased the subscription.

I may be suggesting something that is already implemented in eCommerce - I don't
use eCommerce, so I'm not sure. This is how I would handle it if the capability
is not already there.


Nguyen Minh Triet wrote:

> Hi,
>
> Thanks Adrian for the info. From the looks of things, the solution you
> proposed should allow us to meet our requirements.
>
> Can you suggest any link, example or literature that would allow me to
> fully understand each parameter involved and there interactions in the
> creation of a 'Relationship'.
>
> For example:
>
> 1. 'Parent Type' (of a relationship)
> 2. 'Valid From RoleType' and 'Valid to RoleType'
> 3. How does the RELATIONSHIP apply to the ROLES of parties for example,
> as seen in the RELATIONSHIPS view of the PARTY tab:
> 'The party with ID... in the role of ... is a ... of the current party
> in the role of ...'
>
> Thanks,
> Minh
>
> Minh
> ---------------
>
> Message: 4
> Date: Wed, 01 Feb 2006 11:28:04 -0800
> From: Adrian Crum <[hidden email]>
> Subject: Re: [OFBiz] Users - Roles and Groups and Products Bought
> To: OFBiz Users / Usage Discussion <[hidden email]>
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii; format=flowed
>
> Use PartyRelationship to tie the children to their parents. Your program
> logic
> can check for the existance of the relationship.
>
> Nguyen Minh Triet wrote:
>
>>Hi,
>>
>>I am looking closer at Parties. I am trying to see if a Parent-Child
>>party logic can be implemented with what is currently present. For
>>example, Party A buys a subscription to product X. Party B and Party C
>>are said to both be 'children' of Party A. Party B and C both have
>>access to what Party has bought but what child has bought is only
>>available to itself.
>>
>>>From the Wiki, I see there are different notions applied to parties
>
> such
>
>>as Roles and Groups.
>>http://ofbizwiki.go-integral.com/Wiki.jsp?page=GroupsVsRoles
>>
>>Questions:
>>
>>1. Is it possible to create a Parent-Child structure for Parties or we
>>will have to fiddle with groups and parties code to achieve this?
>>2. If such a structure can be laid out, can the products bought be
>>propagated?
>>
>>I think the essential of this requirement of ours is that point 1 be
>>present or implementable. Point 2 we can implement, I think, with some
>>purchase history checks using the Parent-Child tree.
>>
>>Any suggestions or comments appreciated,
>>
>>Thanks,
>>Minh
>>
>>_______________________________________________
>>Users mailing list
>>[hidden email]
>>http://lists.ofbiz.org/mailman/listinfo/users
>>
>
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users