content references
Locked
 
|
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.... |
|
|
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.... > |
|
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 |
|
|
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 > |
|
|
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 |
|
|
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 > |
|
|
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 |
|
|
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 > |
|
|
In reply to this post by Hans Bakker
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 <[hidden email]>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.... > > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |