[KULRICE-4803] Add unique constraint on KIM permission namespace:name Created: 02/Nov/10  Updated: 23/Feb/12  Resolved: 29/Jun/11

Status: Closed
Project: Kuali Rice Development
Component/s: Database
Affects Version/s: 2.0
Fix Version/s: 2.0

Type: Improvement Priority: Critical
Reporter: Scott Gibson (Inactive) Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
is related to KULRICE-5320 create a migration script to make per... Closed
Rice Module:
KAI Review Status: Not Required
KTI Review Status: Review Completed


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.

Comment by Jonathan Keller [ 17/Jun/11 ]


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.

Comment by Eric Westfall [ 29/Jun/11 ]

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
- 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"
Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Generated at Fri Aug 14 00:18:38 CDT 2020 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.