Details

    • Type: Bug Fix Bug Fix
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-4749GlobalVariables.getMessageMap().containsKeyMatchingPattern is not intuitive and would be more useful if more flexible
      KULRICE-9287KualiLookupableTest fails in CI with Lookup not defined for business object class org.kuali.rice.krad.test.document.bo.Account
      KULRICE-1551Build KOM business objects
      KULRICE-4736Support for dynamic business objects
      KULRICE-11304Cannot use Business Object Service on objects that are scanned by JPA
      KULRICE-1482Add new Principal business object
      KULRICE-4731Support for service mapped business objects (DTOs)
      KULRICE-11182Clear out all locking keys on Maintenance copy, not just the main object
      KULRICE-4576Looks like there is a bug in the KNS framework with nested collections and externalizable business objects.
      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
    • Rice Module:
      KRAD
    • Application Requirement:
      KFS

      Description

      The standard method for copying business object instances is to perform a serialization and materialization of the object to and from a byte stream. While the business object itself will have its primary key reset, dependent objects in the serialized stream are copied as-is. While this is fine in most cases (chart code, account number, etc) we need to allow the business object to decide which dependents need to be copied as if they were also new objects. I propose that KNS respect the java Cloneable interface, and use that if implemented, rather than performing the serialization-based copy.

        Activity

        Hide
        Thomas Bradford (Inactive) added a comment -

        The workaround to this is to create a Maintainable subclass that does one-off processAfterCopy handling for each business object class being maintained. Obviously, this is an awkward approach to copying, and something business object class-specific would be ideal from an implementation standpoint.

        Show
        Thomas Bradford (Inactive) added a comment - The workaround to this is to create a Maintainable subclass that does one-off processAfterCopy handling for each business object class being maintained. Obviously, this is an awkward approach to copying, and something business object class-specific would be ideal from an implementation standpoint.

          People

          • Assignee:
            Unassigned
            Reporter:
            Thomas Bradford (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel