Hi Wen,

There are a few things about your post above that I don't quite understand, I wonder if you could clarify?

I believe there are three separate issues here:

1. The original post which you have +1ed.

I have replied to that post here with more questions as I'm not sure I understand why it is a problem. Any extra comments you have there would be very helpful.

Based on your post here, and your comment above it sounds like you are finding that users who are already assigned to a program via one method who subsequently end up assigned via a second method are triggering exceptions and that the new exception is leading to them losing access to the program. Can you confirm if that's the problem?

If so that is definitely a bug, but I'm afraid I haven't been able to reproduce it in my testing. If you are able to open a support ticket and give us an example with step-by-step instructions on how to reproduce that problem we will look into it immediately.

2. Site administrators not receiving emails when new exceptions occur.

In most cases new exceptions occur when the administrator is making changes to the "Assignments" tab. Therefore as soon as the page reloads after making changes they will see a message indicating there are exceptions, and they will also see the exceptions tab with the count of the number of unresolved exceptions.

However I do acknowledge that there are some situations where the exceptions can occur when the administrator is not making changes (like when audience membership changes lead to exceptions). So I think you are right that it would be good to be able to choose to receive notifications about exceptions.

We will need to give some thought as to who should receive them, as well as consider combining individual messages to avoid overwhelming the receiver with thousands of almost identical messages.

I have created a separate enhancement request to track this specific issue which has the reference number 13509.

3. Ability to control the default behaviour when new exceptions do occur. 

Removing the user from the program when they have an exception is the initial default behaviour because exceptions usually represent some kind of configuration issue that needs human input to resolve. 

If the problem from 1 with existing users being removed is resolved (so that only newly assigned users end up with exceptions) and if we make it easier for admins to track exceptions by implementing point 2, is this feature still needed?

Simon