As it has become increasingly clear in recent years that the management of groups is just as important as the management of personal data, we have decided to split the “ Persons & Groups” module into two parts.

We want to publish a new groups module and thus simplify the future organization in groups, enable more precise filtering and a more user-friendly operation. In preparation for this, we have started to make some changes to the structure of your ChurchTools installation.

1. Persons in groups – introduction of a new status #

• Going forward all people in a group will be called “group members” (previously “group participants”) to avoid confusion with the role “participant”.
• Group members, such as leaders, participants or collaborators, will in future be given a status in addition to a role, which describes a person’s relationship to a group. The status of a person can be “active”, “requested”, “on waiting list” or “to delete”. In the future, other statuses such as “invited” or “left group” are also conceivable.
• Group permissions will only take effect if the group member has the status “active”.

1.1 What does this mean for your group roles? #

• Currently, you can mark a role as “To delete”, “Request”, “Leader”, “Default” or “Hidden” in the master data of the “Persons & Groups” module under “Group type role”. In the future, the “Request” and “To delete” options will be removed because of the role status “requested” and “to delete”. Moreover, there can only be exactly one default role per group type.
• So group members with “Request” roles receive the status “requested” and with “To delete” roles receive the status “to delete” and they are transferred to those roles that have been marked as “Default” of the group type. Two examples follow to illustrate the point; in both examples, the “Participant” role has been marked as the “Default” role:
  • Group members with the previous role “participation requested” are given the role “participant” and additionally the status “requested”.
  • Group members with the previous role “to delete” get the role “participant” and additionally the status “to delete”.

1.2 What to consider as an admin? #

Did you create additional “Request” or “To delete” roles in your master data under “Group type role”? Or were the role names “Participation requested” or “To delete” changed?

• If no, then you don’t have to do anything:
  • then group members with “Request” or “To delete” roles are automatically assigned to the respective “Default” role and
  • these group members get the status “requested” or “to delete” respectively.
• If yes, then we cannot automatically merge your roles. In this case:
  • group members keep their previous role with the prefix “(Deprecated)”.
  • group members receive the respective status corresponding to the current flag (“Requested” or “To delete”).
  • Example 1: A role called “Access requested” was created and marked as “Request”. After the change, group members will have the role “(Deprecated) Access requested” and receive the status “requested”.
  • Example 2: A role called “Please delete immediately” was created and marked as “To delete”. After the change group members will have the role “(Deprecated) Please delete immediately” and additionally receive the status “to delete”.
  • Action required: If you want us to automatically merge your “Request” and “To delete” roles, then please make sure by end of day Tuesday 21/02 at the latest, that for each group type there is only exactly one role …
    • with the name “participation requested” and only this role is marked as “Request” and
    • with the description “to delete” and only this role is marked as “To delete”.
  • Of course, these adjustments can also be made manually at any later date and time.

1.3 Request roles with permissions #

If the participation in a group requires manual approval by a leader, and the “participation requested” role has been assigned group-internal permissions, we will leave the role title unchanged and set the status to”active”, so that given permissions still apply.
In this case we uncheck the box that “it is necessary to have a manual release” to enter the group, so that new group participants still receive immediately permissions as before.

1.4 Synchronizing group members #

Do you use the Sync module to keep your data up to date?
If yes, it is important for you to know that in the future only group members whose status is set to “active” will be synchronized.

2. Group status #

The group status “Pending” will soon be called “Draft”, “Active” will remain the same and “Inactive” will become “Archived”.

Furthermore, we introduce a new group status called “Finished”, which is a precursor to archiving a group. If you set up a “Date of completion” and this date is reached, this group will be automatically set to the status “Finished” in the future. This will close the sign-up to this group and change its visibility level to “Restricted”: this means that the group is no longer “Public” and will also no longer be featured in the app under group suggestions.

Until a year ago, it was possible to create other group statuses (e.g. “Paused”), but these were treated functionally like active groups. Therefore, groups with custom statuses will be set to “active”.

Have you created new group status (visible under Groups > Group Filter > Group status)?

• If no, then there is no need for action.
• If yes, then please check if you want to keep this group information. In this case we recommend to do so by creating a new DB field from the category “Group”.

3. Visibility levels #

There will be an addition to the group visibility levels “Restricted”, “Public” and “Hidden”: The new level “Internal”. People who have a ChurchTools user account can see groups with the visibility level “Internal” without any further permissions.

4. DB fields and group internal permissions #

• To simplify DB fields and permission to set the groups, we remove all DB fields in the master data of the “Persons & Groups” module, which are only needed to configure group functionalities.

Important!
DB fields that are needed to view and edit group info (e.g. group type, location, category) as well as custom DB fields remain unchanged. This means that the security levels for these fields are still valid.

• Instead, there will be new group-internal permissions that allow you to edit basic settings, group infos, group meeting settings, and follow-up settings. Any group member who has the “Edit group properties” permission will automatically receive the new, above-mentioned, group-internal permissions after the transition.