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

Existing notification message delivery preferences for removed message deliverers don't process properly

    Details

    • Type: Bug Fix
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development, Roadmap
    • Labels:
    • Rice Module:
      KEN
    • Application Requirement:
      Rice

      Description

      If a user signs up for a message deliverer (i.e. Email Deliverer, SMS, etc) and then the message deliverer is removed from the system, the preferences still sit around, and still get processed.

      KEN will create message delivery records for them still, but when it goes to deliver, it won't actually deliver b/c the registry doesn't show that old deliverer as being accurate any more, which is appropriate behavior.

      The problem though is b/c that message delivery record sits around in an UNDELIVERED state, KEN will keep trying. We need to fix this by:
      1.) Has a try count so that it stops trying to deliver after a certain number of attempts
      2.) The message delivery record never gets created b/c the deliverer is no long registered in the system
      3.) All message delivery records to be delivered to by a non-existent deliverer fail and get marked as DO NOT DELIVER or something like that after the first attempt

      This was discovered by Cornell: https://jira.cornell.edu/jira/browse/CYNERGY-189

        Attachments

          Issue Links

            Activity

            Hide
            ewestfal Eric Westfall added a comment -

            Aaron, I can't view the content of CYNERGY-189. Is this a huge issue from your perspective? (i.e. how crucial is it to fix this for 1.0)

            Show
            ewestfal Eric Westfall added a comment - Aaron, I can't view the content of CYNERGY-189. Is this a huge issue from your perspective? (i.e. how crucial is it to fix this for 1.0)
            Hide
            agodert Aaron Godert (Inactive) added a comment -

            No, I would say bump to 1.1. After we upgrade to 1.0, we may just fix this bug locally and contribute it back to Rice.

            Show
            agodert Aaron Godert (Inactive) added a comment - No, I would say bump to 1.1. After we upgrade to 1.0, we may just fix this bug locally and contribute it back to Rice.
            Hide
            ewestfal Eric Westfall added a comment -

            Great, thanks for the response Aaron.

            Show
            ewestfal Eric Westfall added a comment - Great, thanks for the response Aaron.

              People

              • Assignee:
                Unassigned
                Reporter:
                agodert Aaron Godert (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated: