Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-4803

Add unique constraint on KIM permission namespace:name

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Database
    • Labels:
      None
    • Rice Module:
      KIM
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Review Completed

      Description

      In order to support upgrade scripts/xml injestion of KIM data we need a unique constraint on Permission namespace:name to identify permissions when we won't possibly know their pk sequence value. This will have some impact on client projects as currently the permission name is not a required field, so those would have to be populated if not already.

        Attachments

          Issue Links

            Activity

            Hide
            jkeller Jonathan Keller added a comment -

            Yike!

            That will be impacting to KFS for certain. We have a large number of permissions (and responsibilities) which all share the same name.

            That feature is used in places in KFS, where we have multiple instances of the same permission and need to be able to check all of them by once. This would force any use like this to be removed and replaced with permission template-based checks, which would mean that additional templates would need to be created.

            Show
            jkeller Jonathan Keller added a comment - Yike! That will be impacting to KFS for certain. We have a large number of permissions (and responsibilities) which all share the same name. That feature is used in places in KFS, where we have multiple instances of the same permission and need to be able to check all of them by once. This would force any use like this to be removed and replaced with permission template-based checks, which would mean that additional templates would need to be created.
            Hide
            ewestfal Eric Westfall added a comment -

            We discussed this at the KTI, decided it made sense to implement this. Rough notes below:

            h2. Requiring Name/Namespace Code on Permission/Responsibility
                    a way of uniquely identify object
                    good for xml import/export
                    consistent with other kim objects like group/role, will make services more consistent as well
                    troublesome for functional users since they would have to come up with unique name/namespace code combinations
                    KULRICE-4803
                    
            - in most cases in KIM, the namespaceCode+name is required and has a unique constraint
            - KFS had some concerns in KULRICE-4803 about making them required and making them unique
            - if we did this would make it easy for import/export
            - would make it consistent with group/role
            - KFS pointed out that the way they are using permissions would be problematic because they don't make those fields required or unique
            -- they don't want to force functional users to come up with unique names each time they create one, may have to rely on templates
            -- they have duplicates as well, not sure what the use is for that
            - Scott - one that you missed is that it's potentially dangerous because you can check permissions by permission name as opposed to template name
            - Chad - i know that with permissions and responsibilities that they can be identified by name, namespace, and details
            - Jonathan's not here in order to speak for KFS
            - Eric - @Chad how did you deal with permissions and details
            -- currently treats the template, name, namespace, and details as what makes a permission "unique"
            -- Scott - that effectively means you can't really update via an XML import
            - Eric - a few ways to proceed
            -- say that id is the unique identifer
            --- problems with migration between environments and id overlap
            --- say they must be unique, can implement scripting to construct unique name based on details
            - Travis - we don't have to directly support what KFS is doing with a custom API, because we are going to have lookup apis on our services
            - KS - no concerns
            - Chitra - KC - we would like it to be unique
            - The Rice database does have this problem in the Rice permission table
            -- Travis - i think i checked that already and didn't find any duplicates
            --- Chitra - "Use Screen" is an example
            --- Travis - maybe i was looking at the templates, I will check again
            -- David - don't all the responsibilities in the responsibility table have the same name?
            - Scott - we need to fix this data error, we should create a script to run through and make the name unique based on details
            -- Chad - be careful with ones that use the DEFAULT template
            - Chad - do we need to modify role members, their uniqueness is based on a different set of attributes
            - KFS - it's impacting because we would have data to update, but not fundamentally opposed to it
            -- KFS - main offender is the responsibility because they are namespace + "review"
            
            Show
            ewestfal Eric Westfall added a comment - We discussed this at the KTI, decided it made sense to implement this. Rough notes below: h2. Requiring Name/Namespace Code on Permission/Responsibility a way of uniquely identify object good for xml import /export consistent with other kim objects like group/role, will make services more consistent as well troublesome for functional users since they would have to come up with unique name/namespace code combinations KULRICE-4803 - in most cases in KIM, the namespaceCode+name is required and has a unique constraint - KFS had some concerns in KULRICE-4803 about making them required and making them unique - if we did this would make it easy for import /export - would make it consistent with group/role - KFS pointed out that the way they are using permissions would be problematic because they don't make those fields required or unique -- they don't want to force functional users to come up with unique names each time they create one, may have to rely on templates -- they have duplicates as well, not sure what the use is for that - Scott - one that you missed is that it's potentially dangerous because you can check permissions by permission name as opposed to template name - Chad - i know that with permissions and responsibilities that they can be identified by name, namespace, and details - Jonathan's not here in order to speak for KFS - Eric - @Chad how did you deal with permissions and details -- currently treats the template, name, namespace, and details as what makes a permission "unique" -- Scott - that effectively means you can't really update via an XML import - Eric - a few ways to proceed -- say that id is the unique identifer --- problems with migration between environments and id overlap --- say they must be unique, can implement scripting to construct unique name based on details - Travis - we don't have to directly support what KFS is doing with a custom API, because we are going to have lookup apis on our services - KS - no concerns - Chitra - KC - we would like it to be unique - The Rice database does have this problem in the Rice permission table -- Travis - i think i checked that already and didn't find any duplicates --- Chitra - "Use Screen" is an example --- Travis - maybe i was looking at the templates, I will check again -- David - don't all the responsibilities in the responsibility table have the same name? - Scott - we need to fix this data error, we should create a script to run through and make the name unique based on details -- Chad - be careful with ones that use the DEFAULT template - Chad - do we need to modify role members, their uniqueness is based on a different set of attributes - KFS - it's impacting because we would have data to update, but not fundamentally opposed to it -- KFS - main offender is the responsibility because they are namespace + "review"
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            Closing since these items are now in the release notes.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Closing since these items are now in the release notes.

              People

              • Assignee:
                Unassigned
                Reporter:
                sgibson Scott Gibson (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: