Type: Bug Fix
Affects Version/s: 1.0.2
Fix Version/s: 126.96.36.199
KULRICE-6478 KEN- principalId/principalName discrepancy KULRICE-645 Add notification level security to the system out of the box KULRICE-647 Load test Notification system KULRICE-4248 KimGroupDao assumes Principals in local database KULRICE-7566 Should consider if a principal should be allowed to have a null principal name KULRICE-3448 Fix principal Ids in KREN tables KULRICE-8737 Send Simple Notification and Send Event Notification throwing stack trace KULRICE-2738 Refactor the Document Search API to use the default system user in cases where no principal ID is defined KULRICE-4249 RoleMemberLookupableHelperServiceImpl assumes Principals and groups in local database KULRICE-5314 KEN Notification's FYI / ACK buttons in detail view throw RuntimeException on click
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.
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.