Uploaded image for project: 'Kuali Rice Roadmap'
  1. Kuali Rice Roadmap
  2. KRRM-24

Add support for "versionable" documents

    Details

    • Rice Theme:
      Kuali Application Business Drivers
    • Priority Score:
      5
    • Functional Justification :
      We have had several requests to be able to see what a document looked like before it was changed. So the initiator starts it, the Fiscal Officer changes it, but there is no way of knowing what it was before the changes were made.
    • Impact if not Implemented:
      This could become an audit issue.
    • Priority - KFS:
      Low
    • Priority - KC:
      Medium
    • Priority - KS:
      Low
    • Priority - Rice:
      Low
    • Theme:
      Kuali Application Business Drivers
    • Application Impact:
      Low
    • Effort Estimate:
      Medium ~ 500 hrs

      Description

      This was originally brought up in the KAI. Kuali Coeus currently supports this but there have been discussions about adding support for this into Rice. But we need a better functional description of how this works.

      Summary of Work Involved: Applications would like to have the ability within rice to store, retrieve, and display historical information about documents (all documents). The general consensus seems to be that recording and storing the information would be a fairly straightforward task, however the functional specifications of what needs stored and how it is displayed or used is the driver behind the higher effort estimate on this item.

        Attachments

          Issue Links

            Activity

            Hide
            jkeller Jonathan Keller added a comment -

            Just some thoughts:

            This would be fairly easy for maintenance documents, as they are stored as a large clob. (More complex would probably be giving users access to see the changes and defining the metadata to track with each revision.)

            Transactional documents usually use their own tables for their pending state, and would have to be re-designed to support versioning. It's possible that the system could serialize these to XML as well for the purposes of this versioning and store in an alternate location. However, the UI issues become even more complex as each of these documents UI is developed independently. Additionally, since so little structure is imposed on transactional documents, it is possible that portions of the displayed data might not be read from the deserialzed object (i.e., the data could be refreshed from the tables via code during the display of the document.)

            Another model would be to go fairly low-level, tracking the properties which have been changed while the document was open and storing their old and new values in more of a key=value format. Then, there could be a section listing the changed properties, rather than attempting to render a prior version of the document.

            Show
            jkeller Jonathan Keller added a comment - Just some thoughts: This would be fairly easy for maintenance documents, as they are stored as a large clob. (More complex would probably be giving users access to see the changes and defining the metadata to track with each revision.) Transactional documents usually use their own tables for their pending state, and would have to be re-designed to support versioning. It's possible that the system could serialize these to XML as well for the purposes of this versioning and store in an alternate location. However, the UI issues become even more complex as each of these documents UI is developed independently. Additionally, since so little structure is imposed on transactional documents, it is possible that portions of the displayed data might not be read from the deserialzed object (i.e., the data could be refreshed from the tables via code during the display of the document.) Another model would be to go fairly low-level, tracking the properties which have been changed while the document was open and storing their old and new values in more of a key=value format. Then, there could be a section listing the changed properties, rather than attempting to render a prior version of the document.
            Hide
            ewestfal Eric Westfall added a comment -

            Just to make sure I understand the scope here, the main requirement is effectively to provide a framework to help with storing historical information about documents. Additionally, there needs to be some way to load to older version of the document (to display the information). Is this correct?

            Show
            ewestfal Eric Westfall added a comment - Just to make sure I understand the scope here, the main requirement is effectively to provide a framework to help with storing historical information about documents. Additionally, there needs to be some way to load to older version of the document (to display the information). Is this correct?
            Hide
            kymber Kymber Horn added a comment -

            Linking to KFSMI-4971 which has some history re: Purchase Orders.

            Show
            kymber Kymber Horn added a comment - Linking to KFSMI-4971 which has some history re: Purchase Orders.
            Hide
            sagee Sandra Agee (Inactive) added a comment - - edited

            The link KFSMI-4971 represents a scenario and need.

            The high level scope also includes
            ability to see historical information
            ability to identify which fields have been changed on a document
            ability to assign fields to track based on a document
            ability to assign hierarchy to doc
            ability to assign field hierarchy per doc, reasoning aren't relevant i.e. phone number may be irrelevant but the catalog number is relevant

            Show
            sagee Sandra Agee (Inactive) added a comment - - edited The link KFSMI-4971 represents a scenario and need. The high level scope also includes ability to see historical information ability to identify which fields have been changed on a document ability to assign fields to track based on a document ability to assign hierarchy to doc ability to assign field hierarchy per doc, reasoning aren't relevant i.e. phone number may be irrelevant but the catalog number is relevant
            Hide
            ewestfal Eric Westfall added a comment -

            I've gone back and forth on the estimate for this one a bit because I'm still trying to digest the scope and requirements. Considering this fact and that the scope appears to be somewhat significant (including detailed tracking and the ability to obtain a view on all historical data) I'm going to play it safe and up the estimate to "Medium ~ 500 hrs"

            Show
            ewestfal Eric Westfall added a comment - I've gone back and forth on the estimate for this one a bit because I'm still trying to digest the scope and requirements. Considering this fact and that the scope appears to be somewhat significant (including detailed tracking and the ability to obtain a view on all historical data) I'm going to play it safe and up the estimate to "Medium ~ 500 hrs"
            Hide
            jkeller Jonathan Keller added a comment -

            After I looked at it a little, I have to agree that 200 hours might have been too tight, especially when the non-maintenance documents are included. With those being so free-form (from a programming POV), this implies that we need to add low-level system hooks (at the BO level) to ensure that the information is captured when needed.

            What really needs to be spec'd out here is how the information would be retrievable by the users. Capturing and storing the information is, ultimately, a minor technical detail. Getting it back out in a structure which is usable/understandable is the harder part. And, the nature of how the users want to see the data will determine how/what we will need to store. (E.g., lists of property=value pairs, clones of tables, or version number-keyed tables)

            So - given all that - 500 hours seems like it could be enough, but it depends on how complex the functional need is.

            Show
            jkeller Jonathan Keller added a comment - After I looked at it a little, I have to agree that 200 hours might have been too tight, especially when the non-maintenance documents are included. With those being so free-form (from a programming POV), this implies that we need to add low-level system hooks (at the BO level) to ensure that the information is captured when needed. What really needs to be spec'd out here is how the information would be retrievable by the users. Capturing and storing the information is, ultimately, a minor technical detail. Getting it back out in a structure which is usable/understandable is the harder part. And, the nature of how the users want to see the data will determine how/what we will need to store. (E.g., lists of property=value pairs, clones of tables, or version number-keyed tables) So - given all that - 500 hours seems like it could be enough, but it depends on how complex the functional need is.

              People

              • Assignee:
                kymber Kymber Horn
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: