Uploaded image for project: 'KFS Archive'
  1. KFS Archive
  2. KFSOLD-17182

create very basic maintenance documents for responsibilities and permissions and hook them into "rule quick links"

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: <= 3.x
    • Labels:
      None
    • Sub-Committee:
      SYS
    • Impacted Modules:
      System

      Description

      1 field to collect a semi colon delimited set of the details in the proper order or attrName=attrVal,...

        Attachments

          Issue Links

            Activity

            Hide
            jkeller Jonathan Keller added a comment -

            OK...that's odd. But, I see how it could happen based on what I had to do for the documents.

            Yes, let's open a new JIRA for issues with these documents. We can keep it open while you're testing. Thanks.

            Show
            jkeller Jonathan Keller added a comment - OK...that's odd. But, I see how it could happen based on what I had to do for the documents. Yes, let's open a new JIRA for issues with these documents. We can keep it open while you're testing. Thanks.
            Hide
            ddorsey Damon Dorsey added a comment -

            sounds good, that one is KFSMI-4865.

            Show
            ddorsey Damon Dorsey added a comment - sounds good, that one is KFSMI-4865 .
            Hide
            ddorsey Damon Dorsey added a comment -

            Johnathan,
            Just a question about the implications of changing the location of Responsibility action details on the responsibility document. It seems like this would be a sketchy thing to change mid-stream but I wanted to see what would happen if someone went from having action details at the role level to have them at the row member level. In CNV I changed the responsibility tied to the DV and the Campus route node to look for action details at the member level. It seems reasonable that the Role doc wouldn't just pick up this change, so I inactivated the current members of that role then added them back and completed the action details for each role member. But since I made the change the DV just seems to skip right over the campus route node without generating any requests. So I'm wondering if there's something else that would need to be done to really make a change like this stick.
            Thanks,
            Damon

            Show
            ddorsey Damon Dorsey added a comment - Johnathan, Just a question about the implications of changing the location of Responsibility action details on the responsibility document. It seems like this would be a sketchy thing to change mid-stream but I wanted to see what would happen if someone went from having action details at the role level to have them at the row member level. In CNV I changed the responsibility tied to the DV and the Campus route node to look for action details at the member level. It seems reasonable that the Role doc wouldn't just pick up this change, so I inactivated the current members of that role then added them back and completed the action details for each role member. But since I made the change the DV just seems to skip right over the campus route node without generating any requests. So I'm wondering if there's something else that would need to be done to really make a change like this stick. Thanks, Damon
            Hide
            jkeller Jonathan Keller added a comment -

            You're right that it is a problem. Now, I don't know how much of what you saw was related to caching. But, it would certainly be necessary to re-add all the role members to get the right data stored in the role-responsibility-action table. From what I remember, that flag is only used by the UI - to enforce how the data is established. Once in that table, the data continues to act per the flag's original setting (since the role member ID would be missing from the existing records.)

            Would you say it's reasonable that we should make that field read-only on existing responsibilities, only allowing it to be set on new ones? If not, we could enhance the responsibility save to re-do the current action records upon a save. That has its own complications, though. Going from non-role-member to role-member assignment is easy, we simply apply the current setting to all members. However, going the other way could be tricky.

            Given our current time-frame, I recommend going with the read-only option. If the other behavior is desirable (but not mandatory in your opinion), please add it as a JIRA for a future release.

            Thanks.

            Show
            jkeller Jonathan Keller added a comment - You're right that it is a problem. Now, I don't know how much of what you saw was related to caching. But, it would certainly be necessary to re-add all the role members to get the right data stored in the role-responsibility-action table. From what I remember, that flag is only used by the UI - to enforce how the data is established. Once in that table, the data continues to act per the flag's original setting (since the role member ID would be missing from the existing records.) Would you say it's reasonable that we should make that field read-only on existing responsibilities, only allowing it to be set on new ones? If not, we could enhance the responsibility save to re-do the current action records upon a save. That has its own complications, though. Going from non-role-member to role-member assignment is easy, we simply apply the current setting to all members. However, going the other way could be tricky. Given our current time-frame, I recommend going with the read-only option. If the other behavior is desirable (but not mandatory in your opinion), please add it as a JIRA for a future release. Thanks.
            Hide
            ddorsey Damon Dorsey added a comment -

            I agree that read-only sounds like a reasonable solution now. I did go ahead and create a release ? jira for possibly implementing something to automate the update like you suggest (KFSMI-4900). But that's way more fancy than what we bargained for here. I put the read-only thing on KFSMI-4865.
            Thanks,
            Damon

            Show
            ddorsey Damon Dorsey added a comment - I agree that read-only sounds like a reasonable solution now. I did go ahead and create a release ? jira for possibly implementing something to automate the update like you suggest ( KFSMI-4900 ). But that's way more fancy than what we bargained for here. I put the read-only thing on KFSMI-4865 . Thanks, Damon

              People

              • Assignee:
                Unassigned
                Reporter:
                abyrne Ailish Byrne
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: