Rock
Rock copied to clipboard
Group Requirement about the expire is not working
Prerequisites
- [x] Put an X between the brackets on this line if you have done all of the following:
- Did you perform a search at https://github.com/issues?q=is%3Aissue+user%3ASparkDevNetwork+-repo%3ARock to see if your bug or enhancement is already reported?
- Can you reproduce the problem on a fresh install or the demo site?
- Did you include your Rock version number and client culture setting?
A Picture Is worth a Thousand Words
Did you know you you can simply copy and paste an image below? Please do that. It really helps us quickly understand the problem.
Description
Group Requirements are not working when someone should be moving from a Warning state to a Meets state. Even though the person is returned by the Meets Dataview, and is not returned by the Warning Dataview, they still appear with a warning icon for the requirement in the Group Viewer. The Calculate Group Requirements job is running daily and is not picking up the change. However, manually recalculating the requirements for a single group member yields the expected result. This particular use case is for background checks.
Testing in both Sandbox and Production indicates that this is still an issue and should therefore be reported as a bug.
After the v13.2 upgrade, group members still exist where they have the Warning icon showing even though they Meet the requirement. As noted in the subtask, the issue appears to only be related to the Calculate Group Requirements job because manually re-checking requirements for individual group members has the expected result.
Steps to Reproduce
- Find/create a Group Requirement that uses both Meets and Warning data views.
- Find a person who is currently returned by the Warning data view and who is in a group using the requirement.
- Go to Group Viewer (People > Group Viewer) and confirm the yellow warning icon appears for this person.
- Update the person's data such that the person is no longer in the Warning data view, but is returned by the Meets data view.
- Run the Calculate Group Requirements job.
- Return to the Group Viewer to see the person is still in a Warning state.
Expected behavior:
The person remains in a Warning state, even though they are no longer returned by the Warning Dataview in the Group Requirement.
Versions
- Rock Version: 1.12.6.1
- Client Culture Setting: en-US Group Requirements Bug - Screenshots.docx
@Angelaholt I tried following your steps on the demo site (which is running v13.4) to reproduce the issue, and I was unable to. Here's what I did to attempt to reproduce it, using the background check group requirement type:
Ted Decker is in the Ushers group, so I set Ted's background check date to 8/1/2019. I ensured that Background Check Required is a requirement set on the Serving Team Group Type.
With that all being set, here's how I tried to reproduce it:
- Checked to make sure that Ted Decker was in the warning dataview (Group Requirements > Background check about to expire)
- Ran the Calculate Group Requirements job
- Checked the Ushers group to make sure that Ted Decker's group requirement was in a warning state
- Changed Ted Decker's background check date to today (7/19/22)
- Ran the Calculate Group Requirements job again
- Checked the Ushers group to make sure that Ted Decker's group requirement was now "cleared" and not showing any warning or error
Would you be willing to attempt to reproduce this on the demo site?
Would also be interested in seeing screenshots of how the group requirement is configured on the group/group type, and how the group requirement itself is configured (General Settings > Group Requirement Types), if you'd be willing to share screenshots of those configurations?
@leahjennings - Cullen is one of our contractors on the Triumph team and also had issues reproducing it on the demo site. He states: "This issue could not be replicated on the demo site. In demo, the person is switched from a Warning state to a Meets state as expected when the Calculate Group Requirements job runs. I tested with a brand new Group Type and the same behavior was found. The issue doesn't seem to be specific to a particular Group Type. I ran a few other tests, including turning on 'Can Expire' on the Requirement Type just in case, but still couldn't find a cause/resolution. After the v13.2 upgrade, group members still exist where they have the Warning icon showing even though they Meet the requirement. As noted in the subtask, the issue appears to only be related to the Calculate Group Requirements job because manually re-checking requirements for individual group members has the expected result."
@Angelaholt hmm, if you're testing in a dev environment, are you able to upgrade that environment to v13.4 and see if it still occurs? Could you also attempt to reproduce this with a group requirement type other than the background check expiring type? Would be curious to see if you experience this behavior on all requirement types or just the background check expiring type.
Hi @leahjennings, I will have to see if we can update our dev environment to test. We only have one other group requirment on this group type and it seems to have the same behavior.
We are having a similar issue with a particular role in our serving teams. Our teens in a role have fewer requirements and none that expire, yet many of our teens have the warning icon on them in the group viewer even though it shows they have met all of the requirements even after manually re-checking them. i will post a few images of a specific example. We are on version 13.6
I can't find a reason why some show the warning and others do not when their requirements are met.
It looks like we found this issue internally and fixed it for the v14.1 release a89bdab7.
We seem to be still having these issues in 14.1. We have a person in a group who has a "meets requirement" date of today and a warning date from two weeks ago. This is causing the warning flag to show still in his groups. The requirements are the same for all of the groups


@adamhann , we're going to reexamine this issue -- so I'm re-opening it now.