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.bak...@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.... > >
