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

Principal Id/Name discrepancy on System notifications

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.2
    • Fix Version/s: 1.0.2.1
    • Component/s: Development
    • Labels:
      None
    • Similar issues:
      KULRICE-6478KEN- principalId/principalName discrepancy
      KULRICE-645Add notification level security to the system out of the box
      KULRICE-647Load test Notification system
      KULRICE-4248KimGroupDao assumes Principals in local database
      KULRICE-7566Should consider if a principal should be allowed to have a null principal name
      KULRICE-3448Fix principal Ids in KREN tables
      KULRICE-8737Send Simple Notification and Send Event Notification throwing stack trace
      KULRICE-2738Refactor the Document Search API to use the default system user in cases where no principal ID is defined
      KULRICE-4249RoleMemberLookupableHelperServiceImpl assumes Principals and groups in local database
      KULRICE-5314KEN Notification's FYI / ACK buttons in detail view throw RuntimeException on click
    • Rice Module:
      KEN

      Description

      Chitra's email:
      -----------
      Hi All,

      I was working on generating a System Notification for KC and I found that there is a potential discrepancy in how NotificationRecipient fields are mapped within the related services.

      The NotificationRecipient has a recipientId, which is expected to be the principalName within NotificationService (while verifying the validity of recipients) but the same field is expected to be the principalId within NotificationWorkflowDocumentService.

      I just wanted to bring it up and possibly get it fixed.

      Regards,
      Chitra
      ------------------

      We should keep these consistent with our member tables where there is a memberId and memberType as opposed to recipientId and recipientType.

      If the recipientType = 'P', recipientId should store and validate against principal ID. If recipientType = 'G', recipientId should store and validate against Group Id.

      We need to make sure that is what we are storing in the table, if it is the principal name, we will need to include an sql script in the upgrade directory to update these. I just tested this and it is storing principal Name, so we will need to fix this.

      NotificationService (actually validated in NotificationRecipientServiceKimImpl) needs to be changed to validate against the principal Id.

        Activity

        Hide
        Jeremy Hanson added a comment -

        Looking at the rest of the KEN code, it seems like the recipientIds are stored as principal names all over, so just switching to validating against the principal name in NotificationWorkflowDocumentService would be orders of magnitude easier than converting everything to principal id....

        Show
        Jeremy Hanson added a comment - Looking at the rest of the KEN code, it seems like the recipientIds are stored as principal names all over, so just switching to validating against the principal name in NotificationWorkflowDocumentService would be orders of magnitude easier than converting everything to principal id....
        Hide
        Jeremy Hanson added a comment -

        Changed the NotificationWorkflowDocumentService to validate against principal name.

        Show
        Jeremy Hanson added a comment - Changed the NotificationWorkflowDocumentService to validate against principal name.

          People

          • Assignee:
            Jeremy Hanson
            Reporter:
            Jeremy Hanson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel