Data View Filters

Family Attendance in Group Types

[!NOTE]

Entity Types: Person

FamilyAttendanceinGroupTypes.png

This filter provides a way for you to filter people based on their family attendance. So it behaves very similarly to the core Attendance in Group Types filter with the following exceptions.

  1. It operates on all members of the family to count attendance.
  2. You can select multiple group types instead of a single one.
  3. Ability to require unique dates for each attendance record.

A note of clarification on the unique dates. This does not mean truly unique dates, but rather service times. See examples below.

  • A family of four attends church at the 9am service. Both children check into difference classes and the parents fill out a welcome form that later results in each getting an attendance record as well. With unique dates turned on this would be counted as a single attendance record.
  • A family of four attends church. The parents and a elementary child attend the 9am service. The last child is in highschool, which only has services at 11am, and thus attends the 11am service. In this case, with unique dates turned on this would be counted as two attendance records.

Giving Frequency

[!NOTE]

Entity Types: Person

[!IMPORTANT]

This filter has restrictive security applied to it by default.

GivingFrequency.png

This filter provides similar functionality to the core Giving Amount filter, except it allows to you filter by people based on their giving frequency instead of total amounts.

By default, this filter is secured so that only Rock Administrators, Finance Administrators or Finance Users can use it. This means only a person in one of those security roles can build a Data View using this filter. Others can still use (that is see) the Data View results if they have access to the Data View itself, but they will not be able to make changes to the filter criteria.

Recent Logins

[!NOTE]

Entity Types: Person

RecentLogins.png

This straight-forward filter allows you to find people who have logged in n number of times in a given date range. A common example, as illustrated above, would be to find everybody who has logged in at least once in the past 4 weeks.

SQL Query

[!NOTE]

Entity Types: All

[!IMPORTANT]

This filter has restrictive security applied to it by default.

SQLQuery.png

This one is pretty straight forward, if you know SQL. Basically, you need to return a single column of Id numbers that will be included in the result set. Let's take a simple example.

SELECT [Id] FROM [Person] WHERE [NickName] LIKE 'Dan%'

This will include all Persons whose nick name begins with Dan. Granted this can easily be done with existing filters. But there are two use cases for this filter.

  1. Building a Data View that does not have a filter you need.
  2. Building a Data View whose filter is too complex, thus causing a timeout when running.

On the topic of performance. There are some things that happen under the hood you may want to know about. The way this filter functions is to store the Id numbers in the database in a new table and uses a type of SQL Join statement to perform the actual filtering. Storing these rows in the database is quite fast. A SQL Query that returns 100,000 Id numbers takes only about 2.5 seconds to store those numbers. However, it also takes up about 32MB of database space.

This is where the cache time option comes in. By default these filter results will be cached for 10 minutes. This is to help reduce the number of rows added to the database needlessly and also to improve response time when vieiwng a Data View and clicking through the pages of results (each time you click, the entire filter runs again so it would cause a new set of rows to be inserted otherwise). Normally this will probably not be a problem, but you can reduce this cache time to 0 seconds if you need always live results. I just don't recommend it if your filter is returning 100's of thousands of results.

So we are caching things in the database. Well, that Cache Time is also used by a new Job installed for you to clean up these cache records. Whenever those rows "expire" they get cleaned up by the job, which runs every 15 minutes by default. It is important that this job be able to completely clear the table once in a while, so it is suggested you do not set a cache time of over 1 hour if you can help it. Longer cache periods can better be achieved in Rock v8 is released as it will include support for caching the entire DataView result set.

By default, this filter is secured so that only Rock Administrators can use it. This means only a Rock Administrator can build a Data View using this filter. Others can still use (that is see) the Data View results if they have access to the Data View itself, but they will not be able to make changes to the filter criteria.