You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Hans Bakker <h....@antwebsystems.com> on 2009/01/22 04:34:41 UTC
content references
Hi David,
now i am on the content subject, i expect that a contentId will be
connected to many more possible main entities so any incoming paper
document can be scanned and connected to the related entity.
At the moment it is WorkEffort, party, order, partyResume, product,
communication event, customer request,
but it could also be connected to invoice, payment, agreement, budget,
fixedAsset, productCatalog, productFacility, return, shipment, supplier,
supplierProduct, tax entities, timesheet and more.
Is it perhaps more flexible to have a more generalized entity such as:
contentId, entityName, entityKey so we can connect any content to any
entity?
what are your thoughts on that?
--
http://www.antwebsystems.com :
Quality OFBiz support for competitive rates....
Re: content references
Posted by Al Byers <by...@automationgroups.com>.
Hans,
One possible advantage to doing things in the manner that you described is
the ability to design a single permission system that could be used in
different situations. Many times the entity to which content is associated
is part of a hierarchical tree - organizations(parties), workeffort (project
levels), etc. Permissions can be governed by assigning PartyRoles to these
entities (Admin, Supervisor, Foreman, etc.) Permission roles could also be
attached to the content, as wll (ie. Owner, Reviewer, etc.)
A permission system could first check the content to see if the "user" has
any role associated with it and then applying that role to a permission
checking table (ex. ContentPurposeOperation). If there is no grant there,
then a bridge would need to be made to the governing tree (that is where
your generic structure could possibly be used) and then that structure could
be followed up to see if the user has a role at any level that would permit
them to manage the content. The current CMS permission scheme is
hierarchical, but it is not tied to another entity structure. I recently
implemented such a scheme in which permission to manage content and tests
was granted at different levels in a school organization.
I realize that that is vague, but I think sometimes it is worth throwing out
imperfect ideas in the hopes that the community may be able to do something
with it. There have been those that say that such a permission scheme is too
complicated, and that may be true (or they just may need more brain food :0)
I just think that there are lots of situations in which permissions are
architected hierarchically and maybe it is not just content that we manage
that way.
-Al
On Wed, Jan 21, 2009 at 8:34 PM, Hans Bakker <h....@antwebsystems.com>wrote:
> Hi David,
>
> now i am on the content subject, i expect that a contentId will be
> connected to many more possible main entities so any incoming paper
> document can be scanned and connected to the related entity.
>
> At the moment it is WorkEffort, party, order, partyResume, product,
> communication event, customer request,
>
> but it could also be connected to invoice, payment, agreement, budget,
> fixedAsset, productCatalog, productFacility, return, shipment, supplier,
> supplierProduct, tax entities, timesheet and more.
>
> Is it perhaps more flexible to have a more generalized entity such as:
> contentId, entityName, entityKey so we can connect any content to any
> entity?
>
> what are your thoughts on that?
>
> --
> http://www.antwebsystems.com :
> Quality OFBiz support for competitive rates....
>
>
Re: content references
Posted by David E Jones <da...@hotwaxmedia.com>.
Okay, I'll repeat myself:
>>>>> Is there any precedent for doing this sort of thing in the data
>>>>> model?
>>>>>
>>>>> Can you think of any reasons why we don't already do this?
>>>>>
>>>>> Sorry for answering a question with more questions, but this sort
>>>>> of
>>>>> question has come up quite a few times and I'm guessing you'll
>>>>> believe
>>>>> the reasons more if you say them than if I do.
-David
On Jan 21, 2009, at 11:45 PM, Hans Bakker wrote:
> the disadvantages i expected to hear from you .....
>
> On Wed, 2009-01-21 at 23:10 -0700, David E Jones wrote:
>> I think you're still talking about the benefits of having a generic
>> entity for these relationships.
>>
>> The question I have for you is what are the problems with having a
>> generic entity like this?
>>
>> -David
>>
>>
>> On Jan 21, 2009, at 10:15 PM, Hans Bakker wrote:
>>
>>> That we have many very similar entities/services/screens to
>>> maintain....
>>>
>>> On Wed, 2009-01-21 at 21:28 -0700, David E Jones wrote:
>>>> That's the benefit, but what are the problems?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jan 21, 2009, at 9:08 PM, Hans Bakker wrote:
>>>>
>>>>> instead of created many more entities we could create a single
>>>>> entity
>>>>> with the actual entityname in one of its fields.
>>>>>
>>>>> On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
>>>>>> Is there any precedent for doing this sort of thing in the data
>>>>>> model?
>>>>>>
>>>>>> Can you think of any reasons why we don't already do this?
>>>>>>
>>>>>> Sorry for answering a question with more questions, but this sort
>>>>>> of
>>>>>> question has come up quite a few times and I'm guessing you'll
>>>>>> believe
>>>>>> the reasons more if you say them than if I do.
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> now i am on the content subject, i expect that a contentId
>>>>>>> will be
>>>>>>> connected to many more possible main entities so any incoming
>>>>>>> paper
>>>>>>> document can be scanned and connected to the related entity.
>>>>>>>
>>>>>>> At the moment it is WorkEffort, party, order, partyResume,
>>>>>>> product,
>>>>>>> communication event, customer request,
>>>>>>>
>>>>>>> but it could also be connected to invoice, payment, agreement,
>>>>>>> budget,
>>>>>>> fixedAsset, productCatalog, productFacility, return, shipment,
>>>>>>> supplier,
>>>>>>> supplierProduct, tax entities, timesheet and more.
>>>>>>>
>>>>>>> Is it perhaps more flexible to have a more generalized entity
>>>>>>> such
>>>>>>> as:
>>>>>>> contentId, entityName, entityKey so we can connect any content
>>>>>>> to
>>>>>>> any
>>>>>>> entity?
>>>>>>>
>>>>>>> what are your thoughts on that?
>>>>>>>
>>>>>>> --
>>>>>>> http://www.antwebsystems.com :
>>>>>>> Quality OFBiz support for competitive rates....
>>>>>>>
>>>>>>
>>>>> --
>>>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>>>
>>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>
Re: content references
Posted by Hans Bakker <ma...@antwebsystems.com>.
the disadvantages i expected to hear from you .....
On Wed, 2009-01-21 at 23:10 -0700, David E Jones wrote:
> I think you're still talking about the benefits of having a generic
> entity for these relationships.
>
> The question I have for you is what are the problems with having a
> generic entity like this?
>
> -David
>
>
> On Jan 21, 2009, at 10:15 PM, Hans Bakker wrote:
>
> > That we have many very similar entities/services/screens to
> > maintain....
> >
> > On Wed, 2009-01-21 at 21:28 -0700, David E Jones wrote:
> >> That's the benefit, but what are the problems?
> >>
> >> -David
> >>
> >>
> >> On Jan 21, 2009, at 9:08 PM, Hans Bakker wrote:
> >>
> >>> instead of created many more entities we could create a single
> >>> entity
> >>> with the actual entityname in one of its fields.
> >>>
> >>> On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
> >>>> Is there any precedent for doing this sort of thing in the data
> >>>> model?
> >>>>
> >>>> Can you think of any reasons why we don't already do this?
> >>>>
> >>>> Sorry for answering a question with more questions, but this sort
> >>>> of
> >>>> question has come up quite a few times and I'm guessing you'll
> >>>> believe
> >>>> the reasons more if you say them than if I do.
> >>>>
> >>>> -David
> >>>>
> >>>>
> >>>> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
> >>>>
> >>>>> Hi David,
> >>>>>
> >>>>> now i am on the content subject, i expect that a contentId will be
> >>>>> connected to many more possible main entities so any incoming
> >>>>> paper
> >>>>> document can be scanned and connected to the related entity.
> >>>>>
> >>>>> At the moment it is WorkEffort, party, order, partyResume,
> >>>>> product,
> >>>>> communication event, customer request,
> >>>>>
> >>>>> but it could also be connected to invoice, payment, agreement,
> >>>>> budget,
> >>>>> fixedAsset, productCatalog, productFacility, return, shipment,
> >>>>> supplier,
> >>>>> supplierProduct, tax entities, timesheet and more.
> >>>>>
> >>>>> Is it perhaps more flexible to have a more generalized entity such
> >>>>> as:
> >>>>> contentId, entityName, entityKey so we can connect any content to
> >>>>> any
> >>>>> entity?
> >>>>>
> >>>>> what are your thoughts on that?
> >>>>>
> >>>>> --
> >>>>> http://www.antwebsystems.com :
> >>>>> Quality OFBiz support for competitive rates....
> >>>>>
> >>>>
> >>> --
> >>> Antwebsystems.com: Quality OFBiz services for competitive prices
> >>>
> >>
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive prices
> >
>
--
Antwebsystems.com: Quality OFBiz services for competitive prices
Re: content references
Posted by David E Jones <da...@hotwaxmedia.com>.
I think you're still talking about the benefits of having a generic
entity for these relationships.
The question I have for you is what are the problems with having a
generic entity like this?
-David
On Jan 21, 2009, at 10:15 PM, Hans Bakker wrote:
> That we have many very similar entities/services/screens to
> maintain....
>
> On Wed, 2009-01-21 at 21:28 -0700, David E Jones wrote:
>> That's the benefit, but what are the problems?
>>
>> -David
>>
>>
>> On Jan 21, 2009, at 9:08 PM, Hans Bakker wrote:
>>
>>> instead of created many more entities we could create a single
>>> entity
>>> with the actual entityname in one of its fields.
>>>
>>> On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
>>>> Is there any precedent for doing this sort of thing in the data
>>>> model?
>>>>
>>>> Can you think of any reasons why we don't already do this?
>>>>
>>>> Sorry for answering a question with more questions, but this sort
>>>> of
>>>> question has come up quite a few times and I'm guessing you'll
>>>> believe
>>>> the reasons more if you say them than if I do.
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> now i am on the content subject, i expect that a contentId will be
>>>>> connected to many more possible main entities so any incoming
>>>>> paper
>>>>> document can be scanned and connected to the related entity.
>>>>>
>>>>> At the moment it is WorkEffort, party, order, partyResume,
>>>>> product,
>>>>> communication event, customer request,
>>>>>
>>>>> but it could also be connected to invoice, payment, agreement,
>>>>> budget,
>>>>> fixedAsset, productCatalog, productFacility, return, shipment,
>>>>> supplier,
>>>>> supplierProduct, tax entities, timesheet and more.
>>>>>
>>>>> Is it perhaps more flexible to have a more generalized entity such
>>>>> as:
>>>>> contentId, entityName, entityKey so we can connect any content to
>>>>> any
>>>>> entity?
>>>>>
>>>>> what are your thoughts on that?
>>>>>
>>>>> --
>>>>> http://www.antwebsystems.com :
>>>>> Quality OFBiz support for competitive rates....
>>>>>
>>>>
>>> --
>>> Antwebsystems.com: Quality OFBiz services for competitive prices
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>
Re: content references
Posted by Hans Bakker <ma...@antwebsystems.com>.
That we have many very similar entities/services/screens to maintain....
On Wed, 2009-01-21 at 21:28 -0700, David E Jones wrote:
> That's the benefit, but what are the problems?
>
> -David
>
>
> On Jan 21, 2009, at 9:08 PM, Hans Bakker wrote:
>
> > instead of created many more entities we could create a single entity
> > with the actual entityname in one of its fields.
> >
> > On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
> >> Is there any precedent for doing this sort of thing in the data
> >> model?
> >>
> >> Can you think of any reasons why we don't already do this?
> >>
> >> Sorry for answering a question with more questions, but this sort of
> >> question has come up quite a few times and I'm guessing you'll
> >> believe
> >> the reasons more if you say them than if I do.
> >>
> >> -David
> >>
> >>
> >> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
> >>
> >>> Hi David,
> >>>
> >>> now i am on the content subject, i expect that a contentId will be
> >>> connected to many more possible main entities so any incoming paper
> >>> document can be scanned and connected to the related entity.
> >>>
> >>> At the moment it is WorkEffort, party, order, partyResume, product,
> >>> communication event, customer request,
> >>>
> >>> but it could also be connected to invoice, payment, agreement,
> >>> budget,
> >>> fixedAsset, productCatalog, productFacility, return, shipment,
> >>> supplier,
> >>> supplierProduct, tax entities, timesheet and more.
> >>>
> >>> Is it perhaps more flexible to have a more generalized entity such
> >>> as:
> >>> contentId, entityName, entityKey so we can connect any content to
> >>> any
> >>> entity?
> >>>
> >>> what are your thoughts on that?
> >>>
> >>> --
> >>> http://www.antwebsystems.com :
> >>> Quality OFBiz support for competitive rates....
> >>>
> >>
> > --
> > Antwebsystems.com: Quality OFBiz services for competitive prices
> >
>
--
Antwebsystems.com: Quality OFBiz services for competitive prices
Re: content references
Posted by David E Jones <da...@hotwaxmedia.com>.
That's the benefit, but what are the problems?
-David
On Jan 21, 2009, at 9:08 PM, Hans Bakker wrote:
> instead of created many more entities we could create a single entity
> with the actual entityname in one of its fields.
>
> On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
>> Is there any precedent for doing this sort of thing in the data
>> model?
>>
>> Can you think of any reasons why we don't already do this?
>>
>> Sorry for answering a question with more questions, but this sort of
>> question has come up quite a few times and I'm guessing you'll
>> believe
>> the reasons more if you say them than if I do.
>>
>> -David
>>
>>
>> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
>>
>>> Hi David,
>>>
>>> now i am on the content subject, i expect that a contentId will be
>>> connected to many more possible main entities so any incoming paper
>>> document can be scanned and connected to the related entity.
>>>
>>> At the moment it is WorkEffort, party, order, partyResume, product,
>>> communication event, customer request,
>>>
>>> but it could also be connected to invoice, payment, agreement,
>>> budget,
>>> fixedAsset, productCatalog, productFacility, return, shipment,
>>> supplier,
>>> supplierProduct, tax entities, timesheet and more.
>>>
>>> Is it perhaps more flexible to have a more generalized entity such
>>> as:
>>> contentId, entityName, entityKey so we can connect any content to
>>> any
>>> entity?
>>>
>>> what are your thoughts on that?
>>>
>>> --
>>> http://www.antwebsystems.com :
>>> Quality OFBiz support for competitive rates....
>>>
>>
> --
> Antwebsystems.com: Quality OFBiz services for competitive prices
>
Re: content references
Posted by Hans Bakker <ma...@antwebsystems.com>.
instead of created many more entities we could create a single entity
with the actual entityname in one of its fields.
On Wed, 2009-01-21 at 20:49 -0700, David E Jones wrote:
> Is there any precedent for doing this sort of thing in the data model?
>
> Can you think of any reasons why we don't already do this?
>
> Sorry for answering a question with more questions, but this sort of
> question has come up quite a few times and I'm guessing you'll believe
> the reasons more if you say them than if I do.
>
> -David
>
>
> On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
>
> > Hi David,
> >
> > now i am on the content subject, i expect that a contentId will be
> > connected to many more possible main entities so any incoming paper
> > document can be scanned and connected to the related entity.
> >
> > At the moment it is WorkEffort, party, order, partyResume, product,
> > communication event, customer request,
> >
> > but it could also be connected to invoice, payment, agreement, budget,
> > fixedAsset, productCatalog, productFacility, return, shipment,
> > supplier,
> > supplierProduct, tax entities, timesheet and more.
> >
> > Is it perhaps more flexible to have a more generalized entity such as:
> > contentId, entityName, entityKey so we can connect any content to any
> > entity?
> >
> > what are your thoughts on that?
> >
> > --
> > http://www.antwebsystems.com :
> > Quality OFBiz support for competitive rates....
> >
>
--
Antwebsystems.com: Quality OFBiz services for competitive prices
Re: content references
Posted by David E Jones <da...@hotwaxmedia.com>.
Is there any precedent for doing this sort of thing in the data model?
Can you think of any reasons why we don't already do this?
Sorry for answering a question with more questions, but this sort of
question has come up quite a few times and I'm guessing you'll believe
the reasons more if you say them than if I do.
-David
On Jan 21, 2009, at 8:34 PM, Hans Bakker wrote:
> Hi David,
>
> now i am on the content subject, i expect that a contentId will be
> connected to many more possible main entities so any incoming paper
> document can be scanned and connected to the related entity.
>
> At the moment it is WorkEffort, party, order, partyResume, product,
> communication event, customer request,
>
> but it could also be connected to invoice, payment, agreement, budget,
> fixedAsset, productCatalog, productFacility, return, shipment,
> supplier,
> supplierProduct, tax entities, timesheet and more.
>
> Is it perhaps more flexible to have a more generalized entity such as:
> contentId, entityName, entityKey so we can connect any content to any
> entity?
>
> what are your thoughts on that?
>
> --
> http://www.antwebsystems.com :
> Quality OFBiz support for competitive rates....
>