Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Incomplete
    • Affects Version/s: Jackrabbit
    • Fix Version/s: Jackrabbit
    • Component/s: ALL APPLICATIONS
    • Labels:
      None

      Description

      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.

        Activity

          People

          • Assignee:
            Sascha Rodekamp
            Reporter:
            Anne Jessel
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development