Uploaded image for project: 'Grouper'
  1. Grouper
  2. GRP-2555

rules dont fire for add member in ui when go from disable to enable

    XMLWordPrintable

Details

    • Bug
    • Resolution: Unresolved
    • Minor
    • None
    • None
    • None
    • None

    Description

      Greg Haverkamp Today at 10:57 AM
      What are the potential pathways for an unaudited membership? I gather from past conversations that future enabled dates are one. Are there others? My "ghost" user problem persists. I thought it had gone away, as after rolling out a more recent version and cleaning up a condition in my rule, they seemed to have gone away for a couple of weeks. And then this morning, I have a new, unaudited membership addition in the group. These group additions are typically accompanied by a changelog entry, they show up at the new time in PIT, but no audit. I'm trying to figure out what in the world to debug. (I know I can't turn on Grouper-wide debugging, because I'll fill my disks.)

       

       

      Greg Haverkamp 2 hours ago
      There's an old thread, but I'll recap, should it help.
      User was added to the group by our Help Desk on 12/18/2019 at 16:01.
      Rule appears to have fired, to set an end date 1 day later.
      "Loader job" deleted the user from the group 25 hours later, at 17:01 ("PM", as noted in the user's membership audit log) as expected.
      PIT shows user with a membership from 2019/12/18 16:01 through 2019/12/19 17:01
      PIT also shows user with a membership starting 2020/01/14 14:45, but there is no audit log entry.
      While preparing this and doing some sleuthing and inquisitions, I now know that the Help Desk added the user manually to the group at 14:45.
      The common thread here has me wondering if I just don't understand how the rules work in combination with enabled and disabled dates. It appears that sometimes the rule does not fire to add the disable date, and on those occasions, the audit log also does not record that the user was added to the group.
      The only users this has been a problem with are users who have previously been members of the group. However, it doesn't happen every time a user has previously been a member of the group.
      At least I can crank up logging on UI without killing things, so I think I'm going to give that a try. Any other ideas?

      Chris Hyzer 4 minutes ago
      if someone adds a user who is already a user, the rule wont fire... right?

      Greg Haverkamp 2 minutes ago
      Is that true even if the user has been disabled/"deleted" (according to the audit)?

      Greg Haverkamp 2 minutes ago
      That is, however, my operating theory. I was just trying to confirm the flow of all of that in the source.

      Greg Haverkamp 1 minute ago
      I don't have a condition on the rule. But, preliminarily, it appears that users who were disabled due to a disabled date – but are not deleted by a user in the UI – are simply re-enabled if added in the UI.

      Greg Haverkamp 1 minute ago
      So, no audit log. No rule adding disabled date.

      Chris Hyzer < 1 minute ago
      so if a user is disabled, and you add that user, then the rule doesnt fire, right?

      Greg Haverkamp < 1 minute ago
      But... if they're disabled via disable date and re-added by WS, the rule does fire and they do get the disable date.

      Chris Hyzer < 1 minute ago
      so in UI, no rule, but WS, yes rule?

      Greg Haverkamp < 1 minute ago
      Yes.

      Chris Hyzer < 1 minute ago
      we could fix that

      Attachments

        Activity

          People

            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            chris.hyzer@at.internet2.edu Chris Hyzer (upenn.edu)
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated: