Thanks David, I have checked that and its set correctly. Just for the heck of it I also tried unchecking the box, saving, checking the box and saving again but still nothing.

If you uncheck all of the Group Types in the Block Properties (which has the effect of showing all Group Types), does it show up then?

Nope. Still the same as before.

Do you have the "Limit to Security Role Groups" option checked in the Block Properties?

No. But if I did the other groups that are showing up would have gone away also.

Added note: I tried searching for small groups and they show up but I get an exemption if I choose any.

Yeah, it was a long shot but I thought the Security Roles thing might have been relevant only if everything had disappeared from your custom page. Anyway, the Exception is interesting - can you give the exact details of the error message?

I updated the original question with the additional information.

Ok, the Exception message is not very informative is it? :-) At a guess, the timeout could mean that some kind of recursion has been introduced into your tree structure in the Small Group branch. Do you remember changing anything to do with the groups in this branch of the tree just before they stopped appearing? Changing the Parent Group to move any Groups in to or out of this branch of the tree? If you have any knowledge of SQL, my recommendation would be to check the "Group" table in the database and trace the ParentGroupId values for each of the groups in the Small Groups branch to see if there are any inconsistencies.

That is kind of what I was thinking. I was just talking to the person overseeing our small groups (they just took it over last week) and asked if they might have accidentally deleted or changed the top group and I got a "I wouldn't have intentionally done that...but very well could have gotten click happy..." I did some testing though and it doesn't look life you can delete a parent group without previously deleting/changing the child groups.

He said he would almost rather re-enter all the data himself so he knows how it's done and to structure it in a slightly different way. I might pull in some help from a volunteer in the church who writes SQL for a living, but am not sure it's worth the time if our small group coordinator just wants to start over anyway.

Now my biggest concern is figuring out how to keep from seeing this happen again....

Yes, whatever happened there is definitely a bug here - so the only way to be sure it doesn't happen again is to identify and fix it. Unless you made low-level changes to the database, the system shouldn't get itself into this state. If you are going to start over, I suggest taking a backup of your database as it is now and having someone with SQL experience look over it with this information in mind - maybe that will shed some light on what has happened and how it could be reproduced.

If you are intending to start over, I would recommend taking a backup of your database and having someone with SQL experience look over it with the information in this thread in mind.
However this happened, the only way to be sure this doesn't happen again is to find the bug and squash it!

DJ,
Has this problem been resolved now?

Not yet. It's still on my to do list. I have a guy who does a lot with SQL who is going to look at it at some point (I have no clue when that will be). I really don't want to just ignore it forever because they do all show up when you search for a group but then you get an exemption if you choose any.

OK, this is definitely a circular reference issue. I managed to reproduce it on the Demo Site running 3.2 with the following steps:

1. Create a Group branch in the form "Test 1/Test 1.1/Test 1.1.1"


2. Edit "Test 1.1" and change its Parent to "Test 1.1.1".


3. Save changes.

Rock saves the change to the record, but then a Timeout error occurs when attempting to reload the Group Tree and the "Test 1" branch containing the circular reference is no longer displayed.

I have logged a bug report for this issue here:
https://github.com/SparkDevNetwork/Rock/issues/1055

You Rock....Pun intended!

Also is there a way for me to fix this on my side? Would you guess the bug fix correct it for me?

Yes, I'm fairly certain the bug fix will correct your problem - although the Group won't show in the Group Viewer, you can search for it and edit the record to correct the circular dependency by changing the Group parent.

Unfortunately, you can't edit the Group through the UI until the bug is fixed.
The only way to correct this right now is to try what I mentioned previously, tracing the records through the Group table to find a ParentGroupId that refers to a Group that is actually referring (incorrectly) to one of its children.

To get you started, you can try this SQL to get a list of likely candidate records:
SELECT *
FROM [Group] g
WHERE g.ParentGroupId > g.Id

The idea here is that the Group causing the problem most likely references a parent Group that was created after it (in time).
Your structure would have initially been created top-down, so this will produce a list of likely records where a group is parented by a group that was created after it - note that if you have moved the structure around a lot, you will get quite a few false matches here - but it's a starting point.
Once you identify the record, the simplest thing to do is to set the ParentGroupId to NULL for that record so it will load as a top-level node.