[ https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214373#comment-13214373 ]
Anne Jessel commented on OFBIZ-4709: ------------------------------------ Hi Sascha I agree with you. There will need to be entities to track the connections, so the key thing is what goes in an entity and what in a node. I'm thinking we will need several new entities such as PartyContentJcr and ProductContentJcr (suggestions for names welcome). Should these link directly to jcr nodes, or should there be a ContentJcr entity which represents the jcr node? I think a ContentJcr, so we can store (at least) from/thruDate there. But the reason I think that is because I am familiar with OOTB support for from/thruDate queries. I do not know jcr well enough: would these queries be just as efficient with the Jackrabbit SQL2 queries? Rights management is not an issue for me. But I am sure it will need to be added sometime. > Support jcr-stored file content within Applications > --------------------------------------------------- > > Key: OFBIZ-4709 > URL: https://issues.apache.org/jira/browse/OFBIZ-4709 > Project: OFBiz > Issue Type: Sub-task > Components: ALL APPLICATIONS > Affects Versions: SVN trunk > Reporter: Anne Jessel > Assignee: Sascha Rodekamp > > My current requirements: > * store uploaded documents (pdf and scans), mainly for legal compliance > reasons > * old document versions should be accessible > * documents should be associated with existing entities. So far I've > identified a need to associate with Product, Party, OrderHeader, > ShipmentItem, probably InventoryItemDetail and maybe WorkEffort. I would not > be surprised if we discover more as this project proceeds. > * documents may have a type and a purpose, though sometimes I'm not sure of > the difference. For example, type: drivers_licence might be purpose: > identification, and/or purpose: permission_to_drive, while type: > shipping_label would be purpose: shipping_label > * many documents have an expiry date (e.g. drivers licence) > * a document may become invalid before its expiry date (e.g. because the law > changed) > * a specific version of a document may need to be associated with an entity. > For example, a licence agreement document accessed via a Product should > always be the latest version. However the version of that document actually > shipped with the product should be associated with the ShipmentItem. > * a single document might be associated with more than one entity type: see > the example in the previous point > Not all documents require all of the above. For example, there are some > documents where we don't need to track which version was used when, and some > without expiry dates. > I'm thinking of using the from/thruDate pattern to handle expiry related > needs. I'd like to put as much information into the jcr path as possible, so > less needs to go into entities, as per Sascha's suggestion on the dev ML. > However (at least) from/thruDate and which version of a document was actually > used where will presumably need to be stored in an entity. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira