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

Add unique constraint on KIM permission namespace:name

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Database
    • Labels:
      None
    • Similar issues:
      KULRICE-6544PermissionService.isAuthorized, hasPermission, getPermissionAssignees, and getAuthorizedPermissions no longer needs to take permission details since permission namespace + name are now unique
      KULRICE-12100KIM Attributes are referenced by a non-unique identifier
      KULRICE-1490Add NAMESPACE_ID to KIM_PERMISSIONS_T and KIM_PERSON_ATTRIBUTES_T
      KULRICE-6784Add index and constraint on KREW_RULE_ATTR_T.NM
      KULRICE-54Add referential integrity support to the OJB-to-DDL generator so that constraints can be added
      KULRICE-13211Investigate attachmentTypeCode and KIM Permissions.
      KULRICE-5320create a migration script to make permission names/resp names unique
      KULRICE-2067Copying without changing the name (or other Unique Constraint fields) seems to allow for submission but actually throws a unique constraint
      KULRICE-13170KIM - Unable to add permission to existing role
      KULRICE-8854Permission doc creating a duplicate permission can be submitted but routes to exception
    • 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.

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          Jessica Coltrin (Inactive) added a comment -

          Closing since these items are now in the release notes.

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

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Structure Helper Panel