Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-14126

Transactional documents should be able to store extended attributes automatically

    Details

    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-1738Lookup Enhancement - Business objects should be able to define a single attribute in the DD as using separate <control> values for standard use and lookup use
      KULRICE-10775Automatic display docTitle in view header
      KULRICE-13842Create transactional document view bean
      KULRICE-12841Does KRAD/KRAD-DATA support extended attributes on documents?
      KULRICE-13841Create controller/form for transactional documents
      KULRICE-4004Partial mask not working in transactional documents
      KULRICE-4082Kim Permission document isn't able to edit permissions with KimType of 10 because it can't find the ParameterDetailType matching the namespace and componentName.
      KULRICE-10896KNS transactional documents are unable to mask their fields
      KULRICE-13676Add unit and html unit tests for the extended attributes feature right in the rice sample app
      KULRICE-13163Set template documentNumber in Transactional Document view
    • Epic Link:
    • Rice Module:
      KNS
    • Application Requirement:
      KFS
    • Sprint:
      Middleware 2.5.2 Sprint 4
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      8

      Description

      Business objects with extended attributes do not need to do pieces of book-keeping for saving the extended attributes BO - most significantly, the KNS framework sets the PK on the extended attribute BO automatically. However, if a transactional document has extended attributes, then the document needs to override methods (typically, prepareForSave) to set the PK on the extended attributes BO. KNS should handle the book-keeping on extended attribute BOs the same, whether the owning object is a regular business object or a transactional document.

        Activity

        Hide
        Jonathan Keller added a comment -

        This one is a little complicated.

        1) This changes behavior in the existing system. (I'm not saying it's not for the better - but it could be an impacting change to existing implementors.)

        2) We would likely need to make this a best-effort operation. For transactional documents, we would probably want to add this behavior into the document save operation. (Technically - the BO service save would be good - but that could have deeper ramifications and affect everything in the system, not just transactional documents.)

        We probably have enough information to do this:

        1) Upon a save of a document, traverse through the updatable objects in the model.
        2) On each one, check the extension property for non-nullity
        3) If non-null, and the PK fields are all blank, copy them from the parent. (The persistence and persistence structure service should be able to provide the needed information.)

        I will note that even maintenance BOs have this issue. We've had to set them manually in the maintainable, especially in cases where the extension object is part of a child object or collection on the main BO class.

        So - Ideally, we would implement this outside of either the BO or doc service. (PersistenceService? since that's OJB only and being retired with OJB) The method would take in a top-level BO and handle population of the keys of any extension objects in the tree. I worry about doing this on every BO save operation, since it could be expensive. But, if we have the method, we could call it from the document service save and from the maintainable saveBusinessObject() method.

        Show
        Jonathan Keller added a comment - This one is a little complicated. 1) This changes behavior in the existing system. (I'm not saying it's not for the better - but it could be an impacting change to existing implementors.) 2) We would likely need to make this a best-effort operation. For transactional documents, we would probably want to add this behavior into the document save operation. (Technically - the BO service save would be good - but that could have deeper ramifications and affect everything in the system, not just transactional documents.) We probably have enough information to do this: 1) Upon a save of a document, traverse through the updatable objects in the model. 2) On each one, check the extension property for non-nullity 3) If non-null, and the PK fields are all blank, copy them from the parent. (The persistence and persistence structure service should be able to provide the needed information.) I will note that even maintenance BOs have this issue. We've had to set them manually in the maintainable, especially in cases where the extension object is part of a child object or collection on the main BO class. So - Ideally, we would implement this outside of either the BO or doc service. (PersistenceService? since that's OJB only and being retired with OJB) The method would take in a top-level BO and handle population of the keys of any extension objects in the tree. I worry about doing this on every BO save operation, since it could be expensive. But, if we have the method, we could call it from the document service save and from the maintainable saveBusinessObject() method.
        Hide
        James Smith added a comment -

        Jonathan, we'd talked about impact before. I think that if fields on the extension BO were populated, then they'd not be populated again (and if this is already done at institutions for docs, then I'm guessing they would have done it in prepareForSave - ie, stuff will be filled in before it gets tot he PersistenceService). Now, someone might have done something crazy like overridden...I have no idea what. DocumentService? And saved everything separately? But I expect that in most cases, what impact there is would be beneficial.

        Show
        James Smith added a comment - Jonathan, we'd talked about impact before. I think that if fields on the extension BO were populated, then they'd not be populated again (and if this is already done at institutions for docs, then I'm guessing they would have done it in prepareForSave - ie, stuff will be filled in before it gets tot he PersistenceService). Now, someone might have done something crazy like overridden...I have no idea what. DocumentService? And saved everything separately? But I expect that in most cases, what impact there is would be beneficial.

          People

          • Assignee:
            Unassigned
            Reporter:
            James Smith
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Agile

                Structure Helper Panel