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

Clear out all locking keys on Maintenance copy, not just the main object

    Details

    • Type: New Feature New Feature
    • 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-4766Allow configuration of fields that should be cleared on maintenance copy action
      KULRICE-10662Maintenance locking keys should default to primary keys if not defined
      KULRICE-3569DocumentBase toCopy method should clear out object id
      KULRICE-10317Finish Implementation on KRAD Maintenance clearUnauthorizedNewFields on copy
      KULRICE-3072Allow maintenance documents to copy PK fields
      KULRICE-13943When editing or copying objects supported by the data object service, primary key type conversion is not performed
      KULRICE-8055Allow for specifications of behavior on copy of maintenance document
      KULRICE-11474KRAD Sampleapp Maintenance Copy Id blank on save
      KULRICE-13632Create Smoke Tests for KRAD Maintenance Document Copy Features
      KULRICE-4306Can't clear an optional user field
    • Epic Link:
    • Rice Module:
      KRAD
    • Application Requirement:
      KFS, KC
    • Sprint:
      Middleware 2.5.2 Sprint 3, Middleware 2.5.2 Sprint 4, Middleware 2.5.2 Sprint 5
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Code Review Status:
      Not Required
    • Include in Release Notes?:
      Yes
    • Story Points:
      5

      Description

      Reported via James Smith:

      About a month ago, I discovered an issue in TEM where a business object with children was being maintained on a maint doc. The business object itself and more importantly, the collection of children objects, all used synthetic keys based on a sequence as their PK’s, and on copy, I found we had to clear the PK’s manually in the processAfterCopy on the maintainable so that the PK’s were reassigned with the document saved them again; if we didn’t do the key clearing, then the children business objects were “stolen” by the object created by the copy and removed from the original. I talked to Doug Pace to see what KC did about this, and he saw two examples of this: one where they cleared the keys and one where they had forgotten (causing the “stealing” issue). Again: I’m not sure what help KRAD could provide to avoid this situation but it’s so easy to forget and cause problems that if there was a way to fix it, I think it would be very helpful for all of the client applications.

      At this time, it looks like we are clearing the basic primary keys but do not have the code to clear all keys associated with the maintenance document, like those on collections or those on child objects. We should be doing this if preserveLockingKeysOnCopy is not set. Verify whether this is still a problem in KRAD and fix it if it is.

        Issue Links

          Activity

          Hide
          James Smith added a comment -

          And added Douglas Pace, too, since he saw the KC versions of these, to see if he agrees with my assessment above. Thank you Jonathan and Doug!

          Show
          James Smith added a comment - And added Douglas Pace, too, since he saw the KC versions of these, to see if he agrees with my assessment above. Thank you Jonathan and Doug!
          Hide
          Jeff Ruch added a comment -

          I agree that auto-retrieve="true" is irrelevant. If I just check for auto-update, I'm assuming it will cover auto-delete. Is there ever a case where you configure auto-delete, without auto-update? Curious on what others have to say.

          Show
          Jeff Ruch added a comment - I agree that auto-retrieve="true" is irrelevant. If I just check for auto-update, I'm assuming it will cover auto-delete. Is there ever a case where you configure auto-delete, without auto-update? Curious on what others have to say.
          Hide
          James Smith added a comment -

          An auto-delete without an auto-update seems like...something would be wrong in the modelling. I can't think of an example off hand.

          Show
          James Smith added a comment - An auto-delete without an auto-update seems like...something would be wrong in the modelling. I can't think of an example off hand.
          Hide
          Douglas Pace added a comment -

          I'm not sure if we've seen this in maint docs as we don't have many with child records, but we have frequently seen this in our trans docs when we allow copies or versioning. The new dataObjectService.copyInstance seems to handle this for us thus far.

          Show
          Douglas Pace added a comment - I'm not sure if we've seen this in maint docs as we don't have many with child records, but we have frequently seen this in our trans docs when we allow copies or versioning. The new dataObjectService.copyInstance seems to handle this for us thus far.
          Hide
          Jonathan Keller added a comment -

          Yes - just checking for auto-update would be correct on this one.

          Delete without update - yes, that would be odd. Only situation I can think of that being used (auto-delete=yes,auto-update=no) is if you really needed to control when the child objects were updated. (But that had no purpose without their parent.)

          Show
          Jonathan Keller added a comment - Yes - just checking for auto-update would be correct on this one. Delete without update - yes, that would be odd. Only situation I can think of that being used (auto-delete=yes,auto-update=no) is if you really needed to control when the child objects were updated. (But that had no purpose without their parent.)

            People

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

              Dates

              • Created:
                Updated:

                Time Tracking

                Estimated:
                Original Estimate - 2 days
                2d
                Remaining:
                Time Spent - 2 hours Remaining Estimate - 1 day, 6 hours
                1d 6h
                Logged:
                Time Spent - 2 hours Remaining Estimate - 1 day, 6 hours
                2h

                  Agile

                    Structure Helper Panel