[
https://issues.apache.org/jira/browse/OFBIZ-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13213488#comment-13213488
]
Sascha Rodekamp edited comment on OFBIZ-4709 at 2/22/12 9:38 AM:
-----------------------------------------------------------------
Hi Anne
* store uploaded documents (pdf and scans), mainly for legal compliance reasons
_Should already work_
* old document versions should be accessible
_Should also already work_
* 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.
_There have to be somehow a connection between entities and jcr content._
* 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
_Should this be stored in a content jcr node or do you think this have to be an
entity field?_
* 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)
_Same question is it better to create a DB field or store the expire date along
with the jcr nodes_
* 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.
_I think here we really need a DB connection, because the relation between a
product and a certain version of a document could not be encoded in the jcr
node_
* a single document might be associated with more than one entity type: see the
example in the previous point
Beside the node path it is possible to store information directly in the jcr
node. Nodes with certain information could be selected by using SQL2 Querys
which is already implemented in Jackrabbit.
Another point which comes in my mind is rights management. Not sure if this is
an issue in your case but we have to consider it.
was (Author: sascha):
Hi Anne
* store uploaded documents (pdf and scans), mainly for legal compliance reasons
_Should already work_
*old document versions should be accessible
_Should also already work_
*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.
_There have to be somehow a connection between entities and jcr content._
*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
_Should this be stored in a content jcr node or do you think this have to be an
entity field?_
*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)
_Same question is it better to create a DB field or store the expire date along
with the jcr nodes_
*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.
_I think here we really need a DB connection, because the relation between a
product and a certain version of a document could not be encoded in the jcr
node_
*a single document might be associated with more than one entity type: see the
example in the previous point
Beside the node path it is possible to store information directly in the jcr
node. Nodes with certain information could be selected by using SQL2 Querys
which is already implemented in Jackrabbit.
Another point which comes in my mind is rights management. Not sure if this is
an issue in your case but we have to consider it.
> 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
